Stlink: Попытка выполнить прошивку на STM32L052K8 приводит к повреждению флеш-памяти.

Это странная проблема, я не мог сразу сказать, в чем проблема. Я думаю, что загрузчик L1 совместим с чипами L0, так как они почти одинаковые.

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

Попробуйте прошить плоский двоичный файл с помощью st-flash, а не elf.

Попробуйте прочитать флеш-память в файл и сравнить или изучить ее с помощью gdb или примера.
х / 32x 0x8000000

Вы должны увидеть начало своей векторной таблицы ...
Откуда взялся ваш двоичный файл и как узнать, что он хорош?

Также, учитывая, что ваш адрес, похоже, находится в ОЗУ, каково состояние вашего булавки BOOT?

Я посмотрю - я все равно хотел узнать, как прошивать .bin файлы вместо того, чтобы загружать .elf с помощью отладчика.

Код был одним из примеров ST, но я еще раз посмотрю, где расположена таблица векторов.

Вывод BOOT0 заземлен, поэтому я не думаю, что он должен загружаться в ОЗУ.

Я отвечу на эти вопросы через день или два - спасибо за совет!

Хорошо, я попытался прошить тестовую программу L0 (в частности, пример инициализации LSI ST) на плату L031K6 Nucleo-32, и она отлично работает.

Однако на L051K8 я все еще наблюдаю эту проблему. Основное отличие состоит в том, что я использую универсальный USB-ключ для программирования платы L051K8 и встроенный отладчик ST-Link / V2-1 для платы L031K6 Nucleo. Я пробовал обновить прошивку на USB-отладчике, но это не помогло.

Я проверил, что таблица векторов правильно размещена с arm-eabi-none-nm в обоих случаях: 08000000 R g_pfnVectors

Запись файла .bin на L051K8 с помощью st-flash write main.bin 0x08000000 вызывает ошибку, но все равно сообщает об успешном завершении. Однако подключение к микросхеме показывает, что программа застряла на 0xFFFFFFFE.

Вот результат st-flash :

st-flash 1.5.0
2018-04-23T23:26:42 INFO common.c: Loading device parameters....
2018-04-23T23:26:42 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-04-23T23:26:42 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-04-23T23:26:42 INFO common.c: Ignoring 4 bytes of 0x00 at end of file
2018-04-23T23:26:42 INFO common.c: Attempting to write 18404 (0x47e4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004780 erased
2018-04-23T23:26:43 INFO common.c: Finished erasing 144 pages of 128 (0x80) bytes
2018-04-23T23:26:43 INFO common.c: Starting Half page flash write for STM32L core id
2018-04-23T23:26:43 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-04-23T23:26:46 ERROR flash_loader.c: flash loader run error
2018-04-23T23:26:46 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-04-23T23:26:46 WARN common.c: 
write_half_pages failed == -1
142/143 pages written
2018-04-23T23:27:03 INFO common.c: Starting verification of write complete
2018-04-23T23:27:04 INFO common.c: Flash written and verified! jolly good!

Но глядя на флеш-память с помощью утилиты ST GUI, я действительно вижу шестнадцатеричный файл .bin, начинающийся с 0x08000000; это похоже на таблицу векторов в начале программы. И записанная память выглядит так, как будто заканчивается на 0x080047E0, что кажется подходящим для размера программы.

Я не знаю - если это не то, что кто-то может воспроизвести, я полагаю, что это могут быть микросхемы или платы, которые я использую.

Привет,

Та же проблема с платой blue-pill (STM32F103C8X)
После каждой программы с 'arm-none-eabi-gdb' я добивался успеха, программа хорошо работала на плате, но когда я пытаюсь запрограммировать ее снова, у меня возникают следующие проблемы:

st-util

[ abdullatif @ Host-001 ~] $ st-util
st-util 1.5.0
2018-05-04T23: 47: 27 ИНФОРМАЦИЯ common.c: Загрузка параметров устройства ....
2018-05-04T23: 47: 27 WARN common.c: Недопустимый тип флэш-памяти, проверьте декларацию устройства
2018-05-04T23: 47: 27 INFO gdb-server.c: ID чипа - 00000000, ID ядра - 00000000.
2018-05-04T23: 47: 27 INFO gdb-server.c: Прослушивание *: 4242 ...
2018-05-04T23: 47: 40 INFO gdb-server.c: найдено 0 регистров точки останова hw
2018-05-04T23: 47: 40 ИНФОРМАЦИЯ gdb-server.c: GDB подключен.

GDB

[ abdullatif @ Host-001 build] $ arm-none-eabi-gdb Stm32blink.elf
GNU gdb (GDB) 8.1
Авторское право (C) 2018 Free Software Foundation, Inc.
Лицензия GPLv3 +: GNU GPL версии 3 или более поздней http://gnu.org/licenses/gpl.html
Это бесплатное программное обеспечение: вы можете изменять и распространять его.
НИКАКИХ ГАРАНТИЙ в той степени, в которой это разрешено законом. Типа "показать копирование"
и "показать гарантию" для подробностей.
Этот GDB был настроен как "--host = x86_64-pc-linux-gnu --target = arm-none-eabi".
Введите "показать конфигурацию" для получения подробной информации
Инструкции по сообщению об ошибках см.
http://www.gnu.org/software/gdb/bugs/ .
Найдите руководство GDB и другие ресурсы документации в Интернете по адресу:
http://www.gnu.org/software/gdb/documentation/ .
Для получения справки введите «help».
Введите "apropos word" для поиска команд, связанных со словом "word" ...
Чтение символов из Stm32blink.elf ... готово.
(gdb) целевой расширенный-удаленный: 4242
Удаленная отладка с использованием: 4242
0x00000000 в ?? ()
(gdb) загрузка
Раздел загрузки .isr_vector, размер 0x10c lma 0x8000000
Ошибка загрузки
(GDB)

Я должен прошить загрузчик с помощью 'st-flash', если я хочу, чтобы плата снова работала.

Я не уверен, что эта проблема с F103 такая же, как то, что я видел; кажется, что этот инструмент довольно хорошо поддерживается, и проблема L0 возникает даже на пустом чипе.

Первоначальное название этого вопроса было неверным, извините; поведение происходит на следующих двух устройствах:

• STM32L052K8

• STM32L082KZ

Я посмотрел на src/chipid.c и увидел, что для настроек использовались только справочные руководства для чипов L0x1 и L0x3; могут ли чипы L0x2 иметь какие-либо существенные отличия?

Следующая разница, похоже, полностью решает эту проблему для меня (с STM32L052K8), но я предполагаю, что это не идеальное решение:

diff --git a/src/common.c b/src/common.c
index b9b7382..7d2480d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1647,7 +1647,8 @@ int stlink_erase_flash_page(stlink_t *sl, stm32_addr_t flashaddr)
 }

 int stlink_erase_flash_mass(stlink_t *sl) {
-    if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    //if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    if (sl->chip_id == STLINK_CHIPID_STM32_L0_CAT2 || sl->chip_id == STLINK_CHIPID_STM32_L0_CAT5) {
         /* erase each page */
         int i = 0, num_pages = (int) sl->flash_size/sl->flash_pgsz;
         for (i = 0; i < num_pages; i++) {

Это изменение удаляет специфическое для L0 поведение для массового стирания с чипов, которые идентифицированы с помощью общей метки L0x3 связанной с идентификатором 0x0417 .

Я не знаю, почему специфическая для L0 логика может вызывать проблемы с этими микросхемами «Категория-3» L0x2 ; похоже, он отлично работает с платой STM32L031 Nucleo, где чип имеет идентификатор 0x0425 который идентифицируется как устройство «Категории 2».

Имея аналогичные проблемы с STM32L151CC.
Он выдает ту же ошибку и не работает на этапе проверки.
Проверка памяти вручную с помощью утилиты ST-Link показывает, что флэш-память записана правильно.
На устройстве не установлена ​​защита от чтения / записи.

st-flash --reset write 'build/bin'/uartbridge-mbiot.bin 0x08000000
st-flash 1.4.0-57-g7651d21
2019-02-28T09:33:08 INFO common.c: Loading device parameters....
2019-02-28T09:33:08 INFO common.c: Device connected is: L1 Medium-Plus-density device, id 0x10f86427
2019-02-28T09:33:08 INFO common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 256 bytes
2019-02-28T09:33:08 INFO common.c: Attempting to write 14376 (0x3828) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-02-28T09:33:08 INFO common.c: Finished erasing 57 pages of 256 (0x100) bytes
2019-02-28T09:33:08 INFO common.c: Starting Half page flash write for STM32L core id
2019-02-28T09:33:08 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-02-28T09:33:12 ERROR flash_loader.c: flash loader run error
2019-02-28T09:33:12 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2019-02-28T09:33:12 WARN common.c: 
write_half_pages failed == -1
 55/ 56 pages written
2019-02-28T09:33:25 INFO common.c: Starting verification of write complete
2019-02-28T09:33:25 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

@WRansohoff : Пожалуйста, проверьте, существует ли проблема в версии v1.5.1.

Конечно, рад проверить, происходит ли это еще с чипами STM32L0 категории 2.

Однако большинство моих плат находится в хранилище, поэтому я, вероятно, не смогу это сделать, пока не закончу переезд в мае. Извини за это.

@WRansohoff : Есть поводу ?

Привет, у меня такая же проблема с STM32L433RC.
Я использую st-util 1.6.1

Попробуйте стереть вспышку вашего MCU
Используйте эту статью: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

Возможно, вы забыли отметить контакты SWD / JTAG на STM32Cube