Всем привет!

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


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

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

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

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

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


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

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



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

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

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

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



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

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

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



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

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

st-flash read r.bin 0x8000000 16384


stm32flash -r r.bin /dev/ttyUSB0


stm32loader.py -V -p /dev/ttyUSB0


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

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

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

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

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