залипает шина I2C в STM32, на МК режим slave Опции

[k155la3]

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

[Метценгерштейн]

Такое ощущение происходило, что именно со стороны Линукса проблема, т.е. мастера.
Т.к. не перегружая STM, перегрузив Линукс- все работало снова нормально.
А в отладчике в модуле I2C что можно посмотреть когда отвалится? На что обратить внимание? На какой регистр?

[Метценгерштейн]

Ну что. Ночь отстояло. 2 стенда сразу. Ничего нигде не отвалилось. С утра оба все работали.
Но еще понаблюдаю. Может проц был грязный. Помыл его перед тестами хорошенько.
Вопрос пока- если вдруг отвалился I2C, в кейле в отладке на какие регистры и биты смотреть?

[k155la3]

Такое ощущение происходило, что именно со стороны Линукса проблема, т.е. мастера.
Т.к. не перегружая STM, перегрузив Линукс- все работало снова нормально.
А в отладчике в модуле I2C что можно посмотреть когда отвалится? На что обратить внимание? На какой регистр?

Исходя из своего опыта долбежа с узлом I2C могу сделать вывод, что без лог. анализатора поиск ошибок
на 1-2 порядка сложнее, если вообще возможен.

При "влете" в ошибку зафиксируйте состояние шины, в смысле какие уровни на линиях SDA SCL.
Например, отключите с шины узел I2C и линии переведите в режим входов.
Если залипла какая-либо линия - это какая-то несостыковка по логике работы master-slave.
Залипнуть может (причем это не сбой а режимы ожидания) как SDA так и SCL.
Несостыковка может быть как устраняемая - когда возможная ошибка или недописка логики на Вашей стороне.
А если кривой мастер - тут ничего не сделаешь. Ситуацию можно только попытаться обойти.

Т.е. надо отловить (устойчиво-гарантированно) при каких обстоятельствах мастер отказывается работать.
Потом отсадить и мучить до победы

Возьмите простой лог. анализатор, клон Saleae (10-20 кваксов) на базе CY7C68013A и будет Вам счастье
(там еще куча протоколов анализа, USART etc)

Ну что. Ночь отстояло. 2 стенда сразу. Ничего нигде не отвалилось. С утра оба все работали.
Но еще понаблюдаю. Может проц был грязный. Помыл его перед тестами хорошенько.
Вопрос пока- если вдруг отвалился I2C, в кейле в отладке на какие регистры и биты смотреть?

Если уж дошло до мытия проц-ра - тогда уж посмотрите выводы на мелкоскопе.

"отвалится" - очень неконкретно.
Первое, на что надо обратить внимание - в каком состоянии линии шины.
Если получается в отладчике остановиться на "отвале"
- проверьте осцилографом или тестером состояние линий.
- переведите линии из I2C на вход и опять проверьте напредмет "залипа" SDA - SCL
Так Вы определите, если это "залип", то кто-есть-ху - мастер или слейв

ps - далее по обстоятельствам.
шина в норме (1-1)
залип со стороны мастера (SDA/SCL)
залип со стороны слейва (SDA/SCL)


Сообщение отредактировал k155la3 - Oct 7 2016, 07:10

[Метценгерштейн]

а еще такой момент- не указал нигде в коде, что прерывания по I2C имеют высший приоритет.

Код

NVIC_SetPriority(I2C1_IRQn, 0); // так не сделано

может надо указать все-таки? Может из-за этого лагать?

[k155la3]

а еще такой момент- не указал нигде в коде, что прерывания по I2C имеют высший приоритет.

Код

NVIC_SetPriority(I2C1_IRQn, 0); // так не сделано

может надо указать все-таки? Может из-за этого лагать?

Не исключено. Мастер он и есть мастер, считает если послан запрос, то обязательно должен быть ответ от слейва.
В противном случае он считает что слейва нет, он неисправен и прочие напасти. Зависит от фантазии писателя.
Например, может переинициализировать свою периферию, и проверить шину на залипание.
Если он видит залипшую шину, то может попытаться ее "разлепить" путем подачи пакета SCL (не помню 8 или 9 клоков до "отлипа").
(такая ситуация у меня была с 24LC16 на отладке).
Если слейв не может ответить, то (слейв) должен перевести шину в режим "ожидания готовности слейва",
кажется это притянуть SCL на 0. Но лучше сразу дать ему что-надо по протоколу - чтобы не заморачиваться с реализацией ожидания.

Приоритет прерывания, скорее всего значения не имеет.
Имеет значение "наполнение" вектора прерывания.

[gerber]

После RESET, насколько я помню, в STM32 все периферийные прерывания имеют одинаковый наивысший приоритет (нуль), поэтому приоритет можно только понизить. Например, SysTick обычно конфигурируется на самом низком приоритете (15), чтобы не мешать остальным.

Полу-OFF: был в моей практике неприятный трудноотлавливаемый глюк, связанный с неправильной расстановкой приоритетов. В низкоприоритетном коде контроллер выполнял примерно такую конструкцию:

Код

if(NeedSleep)
{
  Sleep();
  NeedSleep = 0;
}

В функции Sleep() контроллер гасил PLL, и уходил в "спячку" WFI(). Выход оттуда - по прерыванию.
Так вот, очень редко, 1-2 раза в день при круглосуточной работе, контроллер "отваливался" и приходилось передергивать питание.
Причина оказалась в том, что если после проверки

Код

if(NeedSleep)

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

Код

__disable_irq();
if(NeedSleep)
{
  Sleep();
  NeedSleep = 0;
}
__enable_irq();

[Метценгерштейн]

глюк вот какой замечен.
Связка- мастер Линукс, слейв на STM32.
Запускаю- работает. Был момент, что не трогая STM32, останавливаю программу на Линуксе, потом заново ее стартую. Программа эта шлет в I2C данные, которые мой STM32 принимает. Так вот- STM ничего не принимает больше. Перезагрузка STM тоже не помогает. Помогает только полная перезагрузка Линукса заново и с этим перезапуск программы.
Пока такие наблюдения. А хоть в теории- почему так?
А после каких- то манипуляций с кодом на STM, после перепрошивки его, можно много раз подряд стопить линукс и стартовать заново программу- работает.
В общем, я теряюсь уже.

лог. анализатор- это хорошо. С китайским клоном кто- то работал? Можно его брать?
Но проблема- купить его- долго время уйдет. Нужен сейчас.
Да и не понятно как в прошлом моем сообщении- что он покажет?

[k155la3]

глюк вот какой замечен.
Связка- мастер Линукс, слейв на STM32.
Запускаю- работает. Был момент, что не трогая STM32, останавливаю программу на Линуксе, потом заново ее стартую. Программа эта шлет в I2C данные, которые мой STM32 принимает. Так вот- STM ничего не принимает больше. Перезагрузка STM тоже не помогает. Помогает только полная перезагрузка Линукса заново и с этим перезапуск программы.
Пока такие наблюдения. А хоть в теории- почему так?

Чтобы в такой ситуации теоретически "вычислить" глюк, придется выкуривать досконально работу "автоматов" I2C как STM, таки и мастерского.
А также стандарт I2C - у филипса-NXP можно скачать мануал на эту тему.
Каким путем я гонял своих "чертей" описано выше.

Чистым "программным-безаппаратным" методом, без анализатора и осцилографа ловить чертей сложно.
А с их использованием - часто элементарно IMHO

. . . .
лог. анализатор- это хорошо. С китайским клоном кто- то работал? Можно его брать?
Но проблема- купить его- долго время уйдет. Нужен сейчас.
Да и не понятно как в прошлом моем сообщении- что он покажет?

Вот анализатор которым я пользуюсь Saleae_Clone_LAnalizer_8Channel

Как срочный вариант - используйте 2-лучевой осцилограф + вход синхро.
На синхро подаете строб методом ногодрыга "когданадо", SDA-SCL - на 2 канала.
Но главное - локализировать по месту в алгоритме и времени появление глюка. Я выше Вам это рекомендовал.

ps - что покажет анализатор.
-"байтовую" расшифровку тарфика обмена мастер-слейв.
- удобочитаемые отметки состояний START, STOP, RESTART, ACK NACK
- метки времени
- лог. анализатор (запись) можно стартануть в нужном месте алгоритма методом ногодрыга или с анализируемых линий
Вам потребуется локализовать момент "глюка" с маcтером, а далее промониторить обмен стартуя лог. анализатор
незадолго до появления глюка. Так вы можете проанализировать "предпроцесс" и найти причину глюка-завеса.

Так в каком (извиняюсь за назойливость) состоянии линии I2C после глюка ?
Это можно на отладчике или даже тестером посмотреть.

Сообщение отредактировал k155la3 - Oct 8 2016, 10:09

[Метценгерштейн]

в понедельник дам ответ. Заодно посмотрим- за выходные не слетела работа девайса.
Глюк не просто отловим, поэтому надо смотреть.
Осцилл, конечно, есть у меня.

[Метценгерштейн]

k155la3,

все выходные простояло нормально. С утра сегодня все кнопочки работали. Моя прога на МК обрабатывает кнопки и по I2C шлет их в проц на Линуксе.
Но после перезагрузки софта на Линуксе, связь по I2C пропала. Команды от Линукса я не получаю.

В отладчике какие смотреть регистры I2C?

[k155la3]

k155la3,
все выходные простояло нормально. С утра сегодня все кнопочки работали. Моя прога на МК обрабатывает кнопки и по I2C шлет их в проц на Линуксе.
Но после перезагрузки софта на Линуксе, связь по I2C пропала. Команды от Линукса я не получаю.

В отладчике какие смотреть регистры I2C?

0. подключиться осцилографом на SDA-SCL
1. запускаете свой проект на отладчике.
2. обеспечиваете "завес" мастером (не понял, что означает "перегрузки софта" - это холодный-горячий ресет или перезаливка флеш ?)
3. после фиксации завеса останавливаете свой слейв отладчиком (можно поставить breakpoint "тамгдеможно" чтоб не остановить в векторе перывания).
4. осцилографом смотрите состояние линий SDA-SCL. Подключиться на линии лучше заранее, чтобы помехой подключения не сбросить ситуацию.
Фиксируете значения уровней. Писал об этом выше.
5. в отладчике, в регистрах управления функцией порта, на который выведен I2C, отключаете узел I2C, а порт переводите в режим входа.
Снова фиксируете значения уровней.

Вместо (5) можно просто разорвать шину I2C и посмотреть ее состояние со стороны мастера.

Если есть "залип" - это диагностика с чьей стороны - мастера ли слейва.

Кстати, на шине I2C только один мастер и один слейв ?

[Метценгерштейн]

Пробую.
Перезагрузка софта-

есть Линукс. На нем программа, что работает с моим МК.
Запускаю Линукс (включил питание на плату), запускаю эту прогу.
Так вот- было так, что одна перезагрузка проги не дает результата. Только полный рестарт самого Линукса, потом снова запуск проги.

пока вижу одну картину- такое ощущение, что NAK в ответ идет.
Картинку сейчас сделаю.

Одни мастер и один слейв.

картинка
http://prntscr.com/crztu6

хотя картинка из пачки передачи, так что наки там- это нормально.

очень похоже, что именно сам модуль процессора Линукс дурил. Заменил на другой модуль- все ОК.

[k155la3]

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

Если это пакет от мастера. В этом случае должен быть ACK.
Первый байт мастера в сторону слейва есть <адрес слейва + RW + (N)ACK >.
Поэтому в ответ на этот байт слейв должен выдать подтверждение "я понял свой адрес и режим R/W" и на поле (N)ACK притянуть
шину на 0. А на осцилограмме ОНО в 1. Т.о. мастер "не увидел" ваш слейв. Дает Stop И пробует его увидеть во второй раз (на осцилограмме).
Адрес слейва 0x7E. Мастер хочет что-то прочитать. После этого должны идти или байты адреса в слейв (как в EEPROM I2C)
или то, что определено в Вашем протоколе обмена.

[Метценгерштейн]

там идет пачка пакетов. Я выхватил что-то посередине. Нужен анализатор. Уже заказал. месяц пути.
адрес слейва у меня 0х01.
Я тоже вижу 0х7Е.
Значит, не к моему обращается.
Нужен анализатор.