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

Проц STM32WLE5, самописная (естественно) процедура записи во флеш. Собственно запись компилится в инструкцию strd. Адрес всегда выровнен на 8 байт. Почти всегда работает, но иногда (очень редко) вместо записи получаю флаг PGAERR. В документации написано, что этот флаг возникает в том случае, когда либо адрес первого слова не выровнен на 8 байт, либо второе слово не принадлежит этому же двойному слову. Первое условие у меня не выполняется, потому что обращение идет по указателю на uint64_t и явных приведений типа с этим указателем в программе нет. Для отладки добавил в случае ошибки сохранение адреса, по которому была попытка записи. Этот адрес в конкретном подвисшем ночью устройстве 0x803FED0, т.е. адрес выровнен. Второе условие не выполняется потому, что strd всегда пишет два слова в соседние ячейки. Прерывания во время strd не запрещаю - не нашел в документации таких требований, с горя посмотрел код куба - там прерывания не запрещаются и вообще запись идет двумя отдельными записями по 32 бита, т.е. между этими записями идет обращение к флешу на чтение команды.

Что еще может приводить к PGAERR?

Еще один вопрос: после попадания в эту ситуацию пытаюсь сбросить FLASH->CR, для чего сбрасываю все флаги в SR записью единиц, но флаг CFGBSY остается взведенным и обнуление FLASH->CR приводит к исключению BusError. Какого черта? CFGBSY должен сброситься при окончании записи либо прекращении записи из-за ошибки!

[VladislavS 37]

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

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

С питанием порядок - 3.3 В от ЛБП. Для тактирования тут прибит гвоздями HSI и он включается автоматически контроллером флеша.

[Arlleex 158]

Мои предположения таковы.

Запись в ячейки Flash хоть и похожа на запись в ОЗУ, однако за процессом записи "следит" контроллер Flash. Соответственно, одному вендеру известно, что будет при невыполнении принципа "single-copy atomicity". Скорее всего в вашей STM-ке, наряду с другими "обычными" сериями, LDRD/STRD реализованы как interrupt-continuable, а воздействие таких инструкций на запись в память с побочными эффектами не предсказуема. Если баги происходят с завидной регулярностью, то можете проверить мое предположение (основанное на вполне официальных бумагах ARM) - либо запрещайте прерывания (разумеется, с расстановкой барьеров), либо разбивайте STRD на 2 отдельные STR.

P.S. Кстати, даже если LDRD/STRD реализованы как "fully restarted when interrupt", проблема, описанная мною - останется. В любом случае писать STRD здесь не есть правильно, ИМХО.

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

4 минуты назад, Arlleex сказал:

LDRD/STRD реализованы как interrupt-continuable, а воздействие таких инструкций на запись в память с побочными эффектами не предсказуема

Вполне возможно. Подозревал, но не знал магического слова interrupt-continuable.

4 минуты назад, Arlleex сказал:

либо разбивайте STRD на 2 отдельные STR

Да, сейчас попробую. Это самый простой способ, спасибо.

[jcxz 211]

Пишете кодом из ОЗУ? (перед "из" подразумевается "выполняющимся"; это "формулирую вопрос более однозначно" )

Если нет - можно попробовать сделать это из ОЗУ. Даже если в МК dual-flash. Кроме того, я бы и прерывания запретил (ISR и сама таблица у вас где - во флешь?) и писал бы не STRD и даже кеш флеша на всякий случай выключил (и инвалидировал) и DSB/ISB после добавил и MPU деактивировал.

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

В 26.10.2022 в 12:36, Arlleex сказал:

либо разбивайте STRD на 2 отдельные STR

Помогло. Спасибо.

В 26.10.2022 в 15:11, jcxz сказал:

Пишете кодом из ОЗУ?

Нет. В документации таких требований нет. У L0 для записи половины страницы такое требование в документации есть, значит если бы здесь это требовалось - было бы указано в документации.

В 26.10.2022 в 15:11, jcxz сказал:

Кроме того, я бы и прерывания запретил (ISR и сама таблица у вас где - во флешь?) и писал бы не STRD и даже кеш флеша на всякий случай выключил (и инвалидировал) и DSB/ISB после добавил и MPU деактивировал.

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

[Arlleex 158]

6 часов назад, Сергей Борщ сказал:

Помогло. Спасибо.

Ну Вы говорили, что баг довольно редкий... Так что дайте больше времени

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

1 час назад, Arlleex сказал:

Ну Вы говорили, что баг довольно редкий... Так что дайте больше времени

Ну как редкий - устройстово пишет во флеш 16 слов (8*64 бита) примерно раз в 4 часа. За сутки из 50 устройств на прогоне вешалось около 20 (в процессе отладки за сессию в 1-20 минут не получалось поймать ни разу, хотя первая запись делается в первую же секунду).  После замены strd на две str (одного обращения по uint64_t volatile * на два обращения по uint32_t volatile *) за двое суток из 50 устройств ни одного зависания. Результат налицо.

[Arlleex 158]

А, ну тогда да, похоже что оно.

[jcxz 211]

14 часов назад, Сергей Борщ сказал:

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

Причём тут какие-то "костыли"? Совет мой следовало понимать: Исключить по максимуму все предполагаемые причины сбоя. Если это поможет (в сумме), то потом можно методом исключения (отключая их по очереди) найти какая именно из них помогла. Если (как вы писали) проблема возникает "очень редко", то искать пробуя причины по одной можно очень долго. А задействовав сразу все возможные пути - можно существенно сократить время.

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