[k155la3 26]

 

Может помеха - наводка быть.

Импульсные блоки питания, настольные лампы флюорисцентные и светодиодные.

И еще куча всего в этомже стиле.

 

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

Такое ощущение происходило, что именно со стороны Линукса проблема, т.е. мастера.

Т.к. не перегружая STM, перегрузив Линукс- все работало снова нормально.

А в отладчике в модуле I2C что можно посмотреть когда отвалится? На что обратить внимание? На какой регистр?

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

Ну что. Ночь отстояло. 2 стенда сразу. Ничего нигде не отвалилось. С утра оба все работали.

Но еще понаблюдаю. Может проц был грязный. Помыл его перед тестами хорошенько.

Вопрос пока- если вдруг отвалился I2C, в кейле в отладке на какие регистры и биты смотреть?

[k155la3 26]

Такое ощущение происходило, что именно со стороны Линукса проблема, т.е. мастера.

Т.к. не перегружая 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)

 

Изменено 7 октября, 2016 пользователем k155la3

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

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

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

 

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

[k155la3 26]

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

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

 

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

 

Не исключено. Мастер он и есть мастер, считает если послан запрос, то обязательно должен быть ответ от слейва.

В противном случае он считает что слейва нет, он неисправен и прочие напасти. Зависит от фантазии писателя.

Например, может переинициализировать свою периферию, и проверить шину на залипание.

Если он видит залипшую шину, то может попытаться ее "разлепить" путем подачи пакета SCL (не помню 8 или 9 клоков до "отлипа").

(такая ситуация у меня была с 24LC16 на отладке).

Если слейв не может ответить, то (слейв) должен перевести шину в режим "ожидания готовности слейва",

кажется это притянуть SCL на 0. Но лучше сразу дать ему что-надо по протоколу - чтобы не заморачиваться с реализацией ожидания.

 

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

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

 

 

[gerber 8]

После 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();

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

глюк вот какой замечен.

Связка- мастер Линукс, слейв на STM32.

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

Пока такие наблюдения. А хоть в теории- почему так?

А после каких- то манипуляций с кодом на STM, после перепрошивки его, можно много раз подряд стопить линукс и стартовать заново программу- работает.

В общем, я теряюсь уже.

 

лог. анализатор- это хорошо. С китайским клоном кто- то работал? Можно его брать?

Но проблема- купить его- долго время уйдет. Нужен сейчас.

Да и не понятно как в прошлом моем сообщении- что он покажет?

[k155la3 26]

глюк вот какой замечен.

Связка- мастер Линукс, слейв на 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 после глюка ?

Это можно на отладчике или даже тестером посмотреть.

Изменено 8 октября, 2016 пользователем k155la3

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

в понедельник дам ответ. Заодно посмотрим- за выходные не слетела работа девайса.

Глюк не просто отловим, поэтому надо смотреть.

Осцилл, конечно, есть у меня.

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

k155la3,

 

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

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

 

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

[k155la3 26]

k155la3,

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

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

 

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

0. подключиться осцилографом на SDA-SCL

1. запускаете свой проект на отладчике.

2. обеспечиваете "завес" мастером (не понял, что означает "перегрузки софта" - это холодный-горячий ресет или перезаливка флеш ?)

3. после фиксации завеса останавливаете свой слейв отладчиком (можно поставить breakpoint "тамгдеможно" чтоб не остановить в векторе перывания).

4. осцилографом смотрите состояние линий SDA-SCL. Подключиться на линии лучше заранее, чтобы помехой подключения не сбросить ситуацию.

Фиксируете значения уровней. Писал об этом выше.

5. в отладчике, в регистрах управления функцией порта, на который выведен I2C, отключаете узел I2C, а порт переводите в режим входа.

Снова фиксируете значения уровней.

 

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

 

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

 

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

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

Пробую.

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

 

есть Линукс. На нем программа, что работает с моим МК.

Запускаю Линукс (включил питание на плату), запускаю эту прогу.

Так вот- было так, что одна перезагрузка проги не дает результата. Только полный рестарт самого Линукса, потом снова запуск проги.

 

пока вижу одну картину- такое ощущение, что NAK в ответ идет.

Картинку сейчас сделаю.

 

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

 

картинка

http://prntscr.com/crztu6

 

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

 

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

 

[k155la3 26]

. . . .

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

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

 

Если это пакет от мастера. В этом случае должен быть ACK.

Первый байт мастера в сторону слейва есть <адрес слейва + RW + (N)ACK >.

Поэтому в ответ на этот байт слейв должен выдать подтверждение "я понял свой адрес и режим R/W" и на поле (N)ACK притянуть

шину на 0. А на осцилограмме ОНО в 1. Т.о. мастер "не увидел" ваш слейв. Дает Stop И пробует его увидеть во второй раз (на осцилограмме).

Адрес слейва 0x7E. Мастер хочет что-то прочитать. После этого должны идти или байты адреса в слейв (как в EEPROM I2C)

или то, что определено в Вашем протоколе обмена.

 

 

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

там идет пачка пакетов. Я выхватил что-то посередине. Нужен анализатор. Уже заказал. месяц пути.

адрес слейва у меня 0х01.

Я тоже вижу 0х7Е.

Значит, не к моему обращается.

Нужен анализатор.