Комментарии 10
Вы читали описание команды? Там так и написано.
For other values, where 0 ≤ N < maximum number of pages: N + 1 pages are erased
Странно конечно. Во многих проектах использовал EEPROM эмуляцию. Никогда не сталкивался с таким. Не только на 030, но и на других сериях. Да и на AT32, GD32 нет проблем.
Да что там эмуляцию EEPROM, как они с массовым стиранием вообще организовали связку бут+приложение? Ведь бут стираться не должен никогда, особенно, если RDP эскалировали до 2. А это значит, что постраничное стирание уже должно быть освоено. А ещё, не все страницы там одинакового размера. Но кто же читает букварь, да?
Полное стирание не мешает, так как, если я правильно понял, используется встроенный в МК бутлоадер. Поэтому проблем со стиранием бута быть не может.
Согласен про анализатор. Выручал всегда в самых жутких и непонятных ситуациях. Мастхэв.
Это единственный инструмент, позволяющий отлаживать код практически без влияния на скорость выполнения. Стоимость - дополнительная нога (или ноги) и одна-две команды изменения состояния ноги в ключевом моменте рантайма. Подключенный отладчик влияет на тайминги сильнее, чем рассыпает часто алгоритм, завязанный на чёткий тайминг. А printf вообще показан только для высших вычислительных функций, которые итак медленные по своей сути.
Четкие тайминги без запаса, которые задаются программно, а не аппаратно это очень редко бывают хорошим решением, кроме прерываний разве что. В большинстве случаев printf на стандартных 115200 или нестандартных 1..3Мбит наиболее простое и наглядное решение.
Если уж совсем нет запаса или прерывание то да, изменение ножки и логанализатор или осциллограф это решение, но и то часто можно заменить выводом символа в UART без ожидания окончания передачи.
какието странные танцы с бубном.
код бутлоадера проверить нельзя было?
Автор, вы используете Extended Erase Memory Command, а не Erase Memory Command... внимательнее надо быть
STM32 Universal Boot Loader и стирание секторов памяти