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

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

STM32 подключен слейвом к другому процу АРМ на Линуксе.
Все работает, но поведение странное. Периодически отваливается шина I2C и мой STM не получает никакие команды из вне. Написана на регистрах инициализация. Подтяжки шины к +3,3 по 7,5 К.
Куда можно смотреть? Может что не проинициализировал в МК?

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

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