GDB + ST-Link Опции

[koluna]

Всем привет!

Программатор-отладчик - ST-Link на плате STM32L-Discovery.
GDB-сервер - поделка st-util от texane.
Клиентом коннекчусь, запускаю, останавливаю софтину, работает нормально.
Но прошить удалось только 1 раз (команда load).
При повторном использовании команды выдается ошибка:

(gdb) load
Loading section .isr_vector, size 0x1d0 lma 0x8000000
Load failed

Судя по всему FLASH надо как-то почистить.
Как это сделать?
Читал доку по GDB, но она слишком "универсальная", никакой конкретики на этот счет.
В доке от texane тоже ничего нет.
Подскажите, пожалуйста.

st-flash, кстати шьет только чип на плате.
Снаружи не шьет, почему-то размер памяти в 2 раза больше показывает...

[koluna]

Что, никто моим путем не ходил?
Можно, конечно, попробовать stm32flash или OpenOCD... но начал возиться в данном направлении и хочется всетаки разобраться...
Вообще, в и-нете есть статьи, но там все ограничивается target extended remote, load, run и continue...
По самой отладке вопросов нет.

Фигня какая-то... заработало!

[demiurg_spb]

В openocd есть ключики для очистки и разлочки флеша.
Я для stm32 использую такой аргумент для прошивания через бат-файл:

Код

...
-c "flash write_image erase unlock %TARGET_ELF%"
...

Кстати, вы что используете в качестве клиента gdb-server для пошаговой отладки?
Понятно что eclipse позволяет это сделать, но хочется найти чего-то более легковесное и при этом ещё работоспособное типа arm-none-eabi-insight или tui.
insight - крешится при попытке соединиться с сервером (если кому-то удалось его завести под виндой - поделитесь опытом).
tui отсутствует в сборке arm-none-eabi-gdb.
Остаётся попробовать code::blocks и codelight. Никто не пробовал их для отладки через gdb?

[koluna]

В openocd есть ключики для очистки и разлочки флеша.

В основном OpenOCD и используют... про разлочку и очистку встречал информацию.
Кстати, а почему она залочивается?

Кстати, вы что используете в качестве клиента gdb-server для пошаговой отладки?
Понятно что eclipse позволяет это сделать, но хочется найти чего-то более легковесное и при этом ещё работоспособное типа arm-none-eabi-insight или tui.
insight - крешится при попытке соединиться с сервером (если кому-то удалось его завести под виндой - поделитесь опытом).
tui отсутствует в сборке arm-none-eabi-gdb.
Остаётся попробовать code::blocks и codelight. Никто не пробовал их для отладки через gdb?

Пока для отладки ничего не использую (на работе Keil + j-link).
Дома ковыряюсь с GCC и пр. свободным софтом в расчете на будущее.
GDB-клиент (из комплекта Sourcery CodeBench Lite) у меня в данный момент используется только для прошивки МК...
Про отладку через C::B кто-то когда-то, кажется, писал здесь.

[demiurg_spb]

Кстати, а почему она залочивается?

Сама она не лочится.
Это делается принудительно и нужно лишь в случае изделий на продажу, чтобы сохранить интеллектуальную собственность.

[koluna]

Сама она не лочится.
Это делается принудительно и нужно лишь в случае изделий на продажу, чтобы сохранить интеллектуальную собственность.

Это понятно все, я про другое...
Не понятно почему вчера команда "load" не работала в GDB.
Думал, что в режим какой-то зашел, не позволяющий прошивать МК.

[koluna]

Чисто случайно нашел команду "flash":

(gdb) help flash
Erase all flash memory blocks.

Работает
Как я понимаю, нужны доки именно на GDB-сервер, т. е., на st-util.
Удручает одно - так и не нашел документации...

[koluna]

Команда "load" перед загрузкой очищает память или нет?
Есть какая-нибудь команда, позволяющая считать данные из памяти (под GDB, естественно)?

[koluna]

Скачал с гугля stm32flash.
Собрал под линухом.
Работает.
Только вот неправильно определяет тип процессора (и количество памяти, соответственно)!

koluna@intel:~/prj/test$ stm32flash /dev/ttyUSB0
stm32flash - http://stm32flash.googlecode.com/

Serial Config: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0420 (Medium-density VL)
RAM : 8KiB (512b reserved by bootloader)
Flash : 128KiB (sector size: 4x1024)
Option RAM : 15b
System RAM : 2KiB

Resetting device... done.

А процессор на самом деле - STM32F100C4T6B (4 кб RAM и 16 кб FLASH).

[koluna]

В общем, попробовал:

st-flash read r.bin 0x8000000 16384

2013-09-13T14:47:53 INFO src/stlink-common.c: Loading device parameters....
2013-09-13T14:47:53 INFO src/stlink-common.c: Device connected is: F1 Medium-density Value Line device, id 0x10016420
2013-09-13T14:47:53 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x8000 bytes (32 KiB) in pages of 1024 bytes

stm32flash -r r.bin /dev/ttyUSB0

stm32flash - http://stm32flash.googlecode.com/

Serial Config: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0420 (Medium-density VL)
RAM : 8KiB (512b reserved by bootloader)
Flash : 128KiB (sector size: 4x1024)
Option RAM : 15b
System RAM : 2KiB

Read address 0x08020000 (100.00%) Done.

Resetting device... done.

stm32loader.py -V -p /dev/ttyUSB0

Open port /dev/ttyUSB0, baud 115200
*** Get command
Bootloader version: 0x22
Available commands: ['0x0', '0x1', '0x2', '0x11', '0x21', '0x31', '0x43', '0x63', '0x73', '0x82', '0x92']
Bootloader version 22
*** GetID command
Chip id `['0x4', '0x20']
'

Все три утилиты возвращают ID 0x0420 - Medium Density. А процессор - Low Density. Где косяк?

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

Где косяк?

Возможно это действительно Medium Density. Попробуйте прописать все 64к. Бывает, что производитель сам маркирует большие кристаллы как маленькие и связано это уменьшеным объемом тестирования. Во всяком случае представитель ST объяснял это именно так. Т.е. Там может быть 64К памяти, но они гарантируют работу только первых 16К

[koluna]

Возможно это действительно Medium Density. Попробуйте прописать все 64к. Бывает, что производитель сам маркирует большие кристаллы как маленькие и связано это уменьшеным объемом тестирования. Во всяком случае представитель ST объяснял это именно так. Т.е. Там может быть 64К памяти, но они гарантируют работу только первых 16К

Оригинально... а как разработчику быть?
Зашивать сколько влезет?
Как я понимаю, некоторое ПО (загрузчики со стороны хоста) из-за этого могут работать неправильно?

Спасибо за объяснение

[Lagman]

там еще и периферия есть от Medium Density которая не тестируется т.к. выпускают Low Density.
И как написал Сергей Борщ, работать с ним надо как с Low Density, работу всего остального производитель не гарантирует. (но как я понял они ничего не блокируют при выпуске).