[fmdost 0]

Попробуй перед

reset_tm (); /* r/w twi */

выдать

twi_stop();

 

В код не вникал.

 

Подавать команду стоп нельзя!!! Сбрасывают микросхемы висящие на i2c только многократной подачей команды старт.

 

ЗЫ. Очень хорошее описание работы с шиной i2c, в пдф.

br24l16.pdf

Изменено 3 декабря, 2007 пользователем Т.Достоевский

[SapegoAL 0]

Вообще хотелось бы увидеть здесь советы по воспроизведению проблемы, потому что причины могут быть разными, и вовсе не такими как предполагаются.

 

Простите, но Вы не совсем правы. Именно питание вызывает сложные, трудновоспроизводимые и уникальные глюки. И к советам bodja74 надо отнестись со всей ответственностью. Я бы это сделал немедленно, правда предлагаю вам другой подход.

 

1. Поставить (на время проверки) отличный и мощный блок питания. Это необходимо сделать чтобы однозначно определится в чём проблема. В программной части или аппаратной.

 

2. По результатам испытаний проводить дальнейшее исследование.

 

 

И ещё один момент из моей практики. WDT необходимо использовать тогда, когда к программной части нет претензий. Никаких сбоев и висов. Так как WDT предназначена для выхода из виса по аппаратным проблемам, но не по программным хомутам. По этому, в случае программного виса, вам сначало надо

1. Отключить WDT.

2. Локализовать место или выявить причину виса.

3. Продумать организацию WDT (а не бездумно воткнуть сброс в каждый цикл)

4. Включить WDT.

[sensor_ua 0]

Подавать команду стоп нельзя!!!

Нельзя сразу после START (в приведенной Вами доке почему-то STOP непосредственно после START позволителен - Fig. 16). Но соглашусь, что в данном случае нельзя, потому как неизвестно что же было перед этим. Сброс логики шины согласно спецификации действительно делается подачей S и/или Sr. Но в спецификации шины примеров как на Fig. 14(a) и Fig. 14(B) что-то не находится. Просветите, плз, а то чего-то не попадалось таких наворотов. Максимум чего приходилось испорльзовать - в описании сброса AT24.

1. Clock up to 9 cycles.

2. Look for SDA high in each cycle while SCL is high.

3. Create a start condition.

[fmdost 0]

...Просветите, плз, а то чего-то не попадалось таких наворотов. Максимум чего приходилось испорльзовать - в описании сброса AT24...

Не совсем понял вопроса, проясните.

ИМХО. Рис 14а наверное что-бы слейв гарантированно отпустил таки этот SDA, и что-бы не проверять линию SDA в мастере.

Некорректное начало/завершение обмена i2c системах ограничения доступа бывает очень часто. Сделал контроллер ключей с проверкой напряжения питания, оказалось что ВСЕ! кто ставил его на замки защёлки вернули с жалобами на сигнал просадки питания. (Просадка ниже 7 вольт дольше 250 милисекунд!!!!)

 

forever failure Попробуйте отключать модули по очереди, и смотреть. А ещё лучше, задейтвовать какой нибудь свободный светодиодик или порт. И включать его по очереди после каждого модуля. То-есть:

 

Включить светодиод

ини модуля 1

ВЫлючить светодиод

....

протестил, переставить на модуль 2 итд.

 

 

А ещё красивее WDT переставить на генерацию прерывания, и выводить к какой-нибудь порт, адрес возврата.

Наверняка есть цельный порт только на выход, и с него тестером можно считать.

Изменено 3 декабря, 2007 пользователем Т.Достоевский

[sensor_ua 0]

Не совсем понял вопроса, проясните.

В спецификации на шину (смотрю v2.1) не нашёл способов сброса шины соответствующих указанным на рис 14a и 14b (br24l16.pdf). Кроме того там указано, что нельзя давать "пустое" сообщение - оно illegal format, но не нашёл чего случится страшного при этом. Зато в доке от Rohm есть на рис 16 разрисовка такого случая и описано, мол чего-то таки будет работать. Непонятно это филипс недорасписал (или я криво читал) или у ребят из Rohm фантазия развитая или чего не договаривают. Откуда по 14 проклокиваний перед стартами?

[forever failure 0]

Ещё такая деталь: стартап тайм, определённое фьюзами равно 65 мсек. Если WDT включен и работает при каком-то вечном зависоне это можно видеть как периодическое притухание индикаторных светодиодов с периодом таймаута вочдога (65 мс каждые 2 сек). Совершенно точно помню, что в эксплуатации при зависании этого не было, т. е. выглядело так, как будто WDT не срабатывал.

[vesago 0]

А индуктивной нагрузочкой случаем не управляет ваш аппарат?

[forever failure 0]

нет, ничем он не управляет, но электромагнитная обстановка вокруг него может быть тяжёлой (всякие пускатели, выключатели ампер так на 200, силовае кабели и т. д.)

[vesago 0]

Ну тогда, когда отделите мух от котлет - убедитесь в безгрешности софта, внешний вачдог. Зря не поставили вроде fm3104. Еще - понизить подтяжку по и2ц и частоту.

[diehard 0]

IMHO зависон в twi. Отключите twi устройство и получите бесконечный цикл и, следовательно, зависон. Проверяйте подключение, подтягивающие резисторы и т.д. Короче, подтяжка SCL SDA и проводники идущие к ним.

Изменено 4 декабря, 2007 пользователем D H

[a_electronic 0]

Ещё такая деталь: стартап тайм, определённое фьюзами равно 65 мсек. Если WDT включен и работает при каком-то вечном зависоне это можно видеть как периодическое притухание индикаторных светодиодов с периодом таймаута вочдога (65 мс каждые 2 сек). Совершенно точно помню, что в эксплуатации при зависании этого не было, т. е. выглядело так, как будто WDT не срабатывал.

Все вроде честно. Прога на цикле ожидания флага от ТВАЯ, как и положено виснет, собака сбрасывает проц, после чего прога опять, как и положено виснет. Отлаживать софт с собакой - плохая практика. Отключите собаку и вычисляйте места зависонов конкретно. Хотя они ясны и так.

[forever failure 0]

Что бы что-то попробовать, нужно, чтоб ситуация хотябы иногда повторялась.

Рекомендаций уже было дано достаточно много, но чтоб их проверить, нужно как-то вызвать зависающую ситуацию. Сейчас, у меня никак не получается вызвать такое.

 

Это на текущий момент проблема более основная, чем исправление причины зависания.

 

К тем устройствам, которые сейчас остались на месте эксплуатаци тоже сейчас нет возможности как-то добраться, в общем они где-то там, до куда сейчас не дойти не доехать, не вызвонить через проводки.

 

Поэтому заменив что-то в коде или исправив в источнике питания или ещё что-то сделав, я сейчас так и не узнаю - устранена причина или нет - на рабочем столе оно и так работает во всех позах без каких либо исправлений.

[sensor_ua 0]

Нужно аж симитировать сброс проца во время работы по TWI

[forever failure 0]

Нужно аж симитировать сброс проца во время работы по TWI

Было и такое. зависает до первого срабатывания WDT, то есть на две сек, а дальше норамльно работает.

[diehard 0]

Не подсоединияй устройство по TWI, вот и получишь свой искомый зависон.

После этого сиди, правь исходники.

Изменено 4 декабря, 2007 пользователем D H