STM32F103 зависает при обновлении страницы с включенным USART

В настоящее время я работаю над STM32F103 и хочу запрограммировать вспышку. Однако похоже, что программирование флэш-памяти с помощью устройства USART, получающего байты в то же время, приводит к зависанию:

FLASH_BASE->CR |= FLASH_CR_PER;
while (FLASH_BASE->SR & FLASH_SR_BSY);

FLASH_BASE->AR = pageAddr;
FLASH_BASE->CR |= FLASH_CR_STRT; // Hangs forever when receiving
                                 // data on USART2 in the same time
while (FLASH_BASE->SR & FLASH_SR_BSY);
FLASH_BASE->CR &= ~FLASH_CR_PER;

Отключение флага RE на USART2 до и его повторное включение после позволяет избежать проблемы, но не позволяет мне получать данные во время операции, что было бы возможно, поскольку прерывание приема находится в ОЗУ.

На самом деле, похоже, что это не связано с самим прерыванием, потому что он все еще висит без прерывания приема.

Есть идеи?


embedded stm32 cortex-m3
person Gregwar    schedule 11.03.2015    source источник
comment
Таблица векторов прерываний все еще находится во флэш-памяти?   -  person Turbo J    schedule 14.03.2015
comment
На самом деле моя проблема заключалась в ошибке обработки UART в libmaple См.: github.com /leaflabs/libmaple/issues/109 И: github.com/leaflabs/libmaple/ Issues/107 Неправильно проверялся флаг RXNE во время прерывания Более того, я переместил прерывания uart в раздел RAM   -  person Gregwar    schedule 15.03.2015

Ответы (1)


arrow_upward
2
arrow_downward

Интерфейс флэш-памяти STM32 блокирует свою всю шину данных во время операций стирания и записи, так что любая операция чтения останавливается во время доступа на STM32F2xx!). Поскольку код также выполняется из флэш-памяти, выборка инструкций и, следовательно, выполнение кода останавливаются в течение этого времени, задерживая обработку прерывания и вызывая ошибку переполнения USART.

Один несколько сложный способ обойти это — использовать DMA для приемника USART, но это не всегда возможно или просто и может не решить другие проблемы, вызванные остановкой процессора в системах реального времени.

Этот небольшой сюрприз скрыт в Руководстве по программированию Flash, отдельно от Справочного руководства:

Во время операции записи во флэш-память любая попытка чтения флэш-памяти приведет к остановке шины. Операция чтения будет выполняться правильно после завершения операции записи. Это означает, что выборка кода или данных не может выполняться во время выполнения операции записи/стирания.

В то время как фактическая информация о времени находится в таблице данных: STM32F103 Flash Timing

Похоже, они разбросали информацию по отдельным документам, чтобы вызвать максимальное удивление по этому поводу!

person Clifford    schedule 11.03.2015
comment
Собственно, моя проблема не в том, что зависает на 40 мс, а просто зависает навсегда - person Gregwar; 11.03.2015
comment
Я никогда не выполняю какой-либо код после НАЧАЛА моей страницы, если данные UART получены во время стирания моей страницы - person Gregwar; 11.03.2015
comment
Более того, даже если я поставлю код стирающий страницу в ОЗУ И прерывание USART в ОЗУ все равно зависнет - person Gregwar; 11.03.2015
comment
Я не предполагал, что зависание, которое вы наблюдаете, длилось 40 мс; скорее, обработка последующей ошибки, которую может вызвать такая задержка, может привести к зависанию. Например, если переполнение USART произошло из-за остановки шины, а флаг переполнения не был очищен, ваш ISR будет постоянно повторно входить и никогда не возвращаться к основному потоку. Что говорит ваш отладчик? - person Clifford; 11.03.2015
comment
Даже если код USART ISR и код программирования находятся в ОЗУ, любой другой поток или ISR во флэш-памяти, которые могут вытеснить или заблокировать их (более высокий приоритет), могут остановиться и, таким образом, вызвать аналогичную задержку. Обратите внимание, что выполнение кода из ОЗУ обычно медленнее, чем из встроенной флэш-памяти на Cortex-M, потому что данные и команды загружаются на одну и ту же шину, поэтому они должны выполняться последовательно. - person Clifford; 11.03.2015
comment
ОК Это действительно было вызвано проблемой обработки USART в libmaple, которая была недавно исправлена. com/leaflabs/libmaple/issues/109 - person Gregwar; 12.03.2015