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

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

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

Сообщение отредактировал Т.Достоевский - Dec 3 2007, 17:34

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

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

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


И ещё один момент из моей практики. WDT необходимо использовать тогда, когда к программной части нет претензий. Никаких сбоев и висов. Так как WDT предназначена для выхода из виса по аппаратным проблемам, но не по программным хомутам. По этому, в случае программного виса, вам сначало надо
1. Отключить WDT.
2. Локализовать место или выявить причину виса.
3. Продумать организацию WDT (а не бездумно воткнуть сброс в каждый цикл)
4. Включить WDT.

Нельзя сразу после START (в приведенной Вами доке почему-то STOP непосредственно после START позволителен - Fig. 16). Но соглашусь, что в данном случае нельзя, потому как неизвестно что же было перед этим. Сброс логики шины согласно спецификации действительно делается подачей S и/или Sr. Но в спецификации шины примеров как на Fig. 14(a) и Fig. 14( что-то не находится. Просветите, плз, а то чего-то не попадалось таких наворотов. Максимум чего приходилось испорльзовать - в описании сброса AT24.
1. Clock up to 9 cycles.
2. Look for SDA high in each cycle while SCL is high.
3. Create a start condition.

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

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

Включить светодиод
ини модуля 1
ВЫлючить светодиод
....
протестил, переставить на модуль 2 итд.


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

Сообщение отредактировал Т.Достоевский - Dec 3 2007, 22:56

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

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

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

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

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

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

Сообщение отредактировал D H - Dec 4 2007, 07:42

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

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

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

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

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

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

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

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

Сообщение отредактировал D H - Dec 4 2007, 15:27