STM32F0 - Boot ins SRAM mit OpenOCD

[Sebastian E. (Gast)]

Ich habe seit kurzem das STM32 NUCLEO-F091RC (mit STM32F091RCT6 
Cortex-M0) und arbeite mit EmBitz beta 0.42. Leider versteht sich der 
STLink-V2-1 anscheinend nicht mit meinen USB-Port (USB3, Notebook), 
sodass ich auf OpenOCD 0.9.0 ausgewichen bin.

Flashen und Debuggen funktioniert problemlos solange der Code im Flash 
liegt. Um den Flash ein wenig zu schonen, möchte ich aber gerne aus dem 
RAM debuggen, nur leider hakt es genau da.

EmBitz lädt sämtliche Sections so wie es sich gehört in den RAM und 
scheint dann über einen Core-Reset das Programm zu starten:

Reading symbols from bin/Debug/test_sram.elf...
done.
Source directories searched: D:/C/arm_projects/SVN/STM32_NUCLEO_F091RC/test;$cdir;$cwd
Remote debugging using localhost:3333
0x000000000x00000000 in ?? ()
Connected
Loading section .text, size 0xe28 lma 0x20000000
Loading section .ARM.exidx, size 0x8 lma 0x20000e28
Loading section .data, size 0x6c lma 0x20000e30
Start address 0x20000000, load size 3740
Transfer rate: 57 KB/sec, 1246 bytes/write.

Leider startet der Core nicht aus dem SRAM sondern aus dem Flash, denn 
wenn ich per Debugger stoppe zeigt PC in 0x0800xxxx. In den 
Einstellungen für den ST-Link bietet EmBitz entsprechende Optionen an, 
um im SRAM zu debuggen:
- "Vector Start Table" = 0x20000000
- "Execute from RAM" = checked
- "Vector table relocation" = checked

Diese hatte ich vor einiger Zeit mit meinem Vorgänger-Notebook (USB2) 
und einem STM32F4DISCOVERY problemlos verwenden können.
Nur fehlen diese Optionen aber beim OpenOCD.

Weiteres Problem:
EmBitz kennt den ST32F091xx nicht, daher starte ich den OpenOCD manuell 
per Batch-File, d.h. ich wüsste auch nicht wie ich EmBitz überreden 
könnte, die obigen Einstellungen von Hand zu setzen ("Extra Commands" in 
den OpenOCD-Settings).

Hat jemand eine Idee, wie man das gescheit lösen könnte?

--------------------

Meine "ungescheite" Lösung:

Ich habe den Startup-Code um eine Art Bootloader ergänzt, welche beim 
Start aus dem Flash nachschaut, ob der Debugger vor dem Core-Reset ein 
Programm im SRAM abgelegt hat. Dazu werte ich die Interrupt Vector 
Tabelle aus, welche in dem Fall am Anfang des SRAMs liegt, und schaue ob 
die Initial-Werte für PC und SP ins SRAM zeigen. Ist das der Fall, 
springt der Bootloader in den SRAM, andernfalls gehts mit dem Code im 
Flash weiter.

Nicht schön, aber es funktioniert.

Die relevanten Dateien habe ich angehängt. In der Build-Konfiguration 
für die Ausführung aus dem SRAM (bei mir "Debug") muss das Macro 
"BOOT_FROM_SRAM" definiert werden.

[rmu (Gast)]

Sebastian E. schrieb:
> Um den Flash ein wenig zu schonen, möchte ich aber gerne aus dem RAM
> debuggen

Zum Problem selbst kann ich nicht viel beitragen, aber Flash schönen 
sollte nicht notwendig sein. Das hält IIRC einige 10000 Schreibzyklen 
aus. Beim Debuggen wird bei der CPU auch die debug Einheit verwendet, 
beim Steppen muss also nicht immer wieder eine brk Instruktion 
geschrieben werden.

[./. (Gast)]

Dazu muss der Debugger aber auch den Controller in die
richtige Stimmung bringen. Die Linkereinstellugen interessieren
den naemlich nicht die Bohne.

Beim M0 (ohne VTOR) waere das im SYSCFG.
Wenn es >M0+ ist: Schau halt ins DB/RM ob er VTOR hat.
Dann ist da der richtige Platz.

Den Bootlader kannst Du Dir sparen.
Wie Du schon bemerkt hast, tut der nicht das gewuenschte.

Also im Initskript des Debuggers auch das RAM-Mapping einschalten...
Zur Not kann Mann es auch in die Startup.s tun.