STM32F103 SPI, RXNE периодически не выставляется, При отладке Опции

[566C6164]

В железе все исправно работает.

Если запускаю в отладке - через какое-то время программа виснет на:

Код

while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET);

То есть почему-то в отладке этот флаг не всегда выставляется.

Как такое может быть? Посылая байт я автоматически получаю байт (сдвиговый регистр). Флаг должен выставляться всегда.

[KnightIgor]

В железе все исправно работает.

Если запускаю в отладке - через какое-то время программа виснет на:

Код

while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET);

То есть почему-то в отладке этот флаг не всегда выставляется.

Как такое может быть? Посылая байт я автоматически получаю байт (сдвиговый регистр). Флаг должен выставляться всегда.

Я в свое время долго возился с печально известным I2C этого процессора. Процесс отладки нарушал работу машины состояний интерфейса. Возможно и для SPI отладка работает не совсем чисто (не полностью "non-intrusive") и сбрасывает RXNE, считывая содержимое DR для представления в отладчике. Я такое и вправду спорадически наблюдал для SPI, но ввиду простоты SPI потом положился на написаный код и перестал шагать внутри. Пока все работает.

<Ясновидение>
Может это и танцы с бубном, но попробуйте закрыть в отладчике окна, которые как-то отображают содержимое DR. Если же исключить глюки отладчика, возможно у Вас код вызывает сброс процессора или самой периферии, что приводит SPI в исходное состояние так сказать за кулисами.
</Ясновидение>

Сообщение отредактировал KnightIgor - Jul 28 2014, 15:23

[Golikov A.]

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

[566C6164]

Если открыто окно View - System Viewer - SPI - SPI1 - проблема сразу проявляется.

Если закрываю - вроде уходит. Но ещё понаблюдаю. Потом отпишусь.

[Сергей Борщ]

Если закрываю - вроде уходит. Но ещё понаблюдаю. Потом отпишусь.

И KnightIgor и Golikov A. уже написали - проблема в этом. В процессор вшита жесткая логика: регистр прочитали - флаг сбросить. Процессору абсолютно неважно кто читает его регистр - ядро по указке программы или отладочные схемы по просьбе отладчика, флаг будет сброшен в обоих случаях.

[KnightIgor]

И KnightIgor и Golikov A. уже написали - проблема в этом. В процессор вшита жесткая логика: регистр прочитали - флаг сбросить. Процессору абсолютно неважно кто читает его регистр - ядро по указке программы или отладочные схемы по просьбе отладчика, флаг будет сброшен в обоих случаях.

К сожалению, факты говорят об этом, что есть очевидный глюк: отладка по JTAG должна быть non intrusive. В этом вообще весь смысл. Я рыться по сайту ST сейчас не буду, но помнится мне, что во всяких рекламах ST именно это и утверждала. Интересно, что там в более высоких сериях (2xx/4xx) и более новых (M0/M0+) процессорах...

[Golikov A.]

А вот есть мнение что периферия не есть принадлежность ядра. Скорее всего она физически не сможет отличить доступ к ней от проца или через жетаг, потому так себя и ведет.

[KnightIgor]

А вот есть мнение что периферия не есть принадлежность ядра. Скорее всего она физически не сможет отличить доступ к ней от проца или через жетаг, потому так себя и ведет.

<лирика>
Мне так нравится это выражение - "есть мнение"! Так веет совком, КПСС и "там, наверху". Это не личный выпад, это "ностальгия" . Впрочем, не у меня одного, как видно по развитию. К сожалению.
</лирика>
<физика>
Если все делать правильно, периферия будет состоять из двух частей: собственно "видимая" и доступная программисту приложения часть и часть для boundary scan access - неразрушающего доступа к тем же ресурсам периферии для целей отладки. Своего рода двухпортовые регистры. Вывод - ST не доглядел в этой второй части. Как я уже упоминал в другом посте, определенная нерегулярность, видимое отсутствие единой концепции периферии в ST говорит о том, что VHDL|Verilog код для разной периферии писали разные подразделения без достаточной координации друг с другом. Потому есть регистры статуса, биты в которых сбрасываются записью нуля, а есть пары регистров - только чтения и только записи, - когда для сброса битов в одном регистре надо писать единицы в другой. Это явно свидетельствует о спешке в разработке, отсутствии единого толкового системного архитектора и прочем хаосе в большой конторе. В этом смысле EFM32 процессоры есть полная противоположность хаосу и пример единой концепции: достаточно въехать в регистры одной периферии как сразу становится понятным работа с другой периферией, т.к. все сделано идентично: есть регистр флагов, а есть регистры для сброса и установки этих флагов, и т.п.
</физика>

[566C6164]

Ясно. Спасибо.