STM32: Keine Interrupte nach Vector Table Relocation

Es reicht nicht den Code an anderer Stelle im Flash abzulegen und den 
Zeiger auf die Vektortabelle anzupassen. Am Anfang des Flash muss 
zusätzlich eigener Code (ein Jump oder eine geeignete VT) stehen, der 
die Code-Ausführung an das Programm weiter gibt.
(Habe lange keine STMs mehr programmiert. Hoffentlich verwechsel ich da 
nichts.)

Hallo,

ich tue drei Dinge, damit VTOR wirksam wird:

Linkerfile anpassen:
…
MEMORY
{
FLASH (rx)      : ORIGIN = 0x08005000, LENGTH = 108K   // <-hier
RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 20K
}
…

System_stm32f1xx.c anpassen:
…
#define VECT_TAB_OFFSET  0x5000 /*!< Vector Table base offset field.
                                  This value must be a multiple of 
0x200. */
…

Target Software Startup Script anpassen (Truestudio):
...
# Reconfig vector table offset reg to match pp location
set *0xe000ed08 = 0x5000

# Get app stackpointer
set $sp = *(unsigned int*)0x5000

# Get app entry point
set $pc = *(unsigned int*)0x5004
...


Habe ich etwas vergessen...?

Gruß

Ich meine schon. Der STM32 startet doch immer bei 0x08000000. Oder 
nicht?
Wenn das Programm bei 0x08005000 liegt, dann fehlt noch ein zweites 
Programm bei 0x08000000, welches den Sprung macht. In EMBlocks habe ich 
jedenfalls (aus welchen Gründen auch immer) so gemacht. Truestudio habe 
ich nie verwendet.

BrilleAuf schrieb:
> # Reconfig vector table offset reg to match pp location
> set *0xe000ed08 = 0x5000
>
> # Get app stackpointer
> set $sp = *(unsigned int*)0x5000
>
> # Get app entry point
> set $pc = *(unsigned int*)0x5004

Ich kenne TreuStudio nicht, aber muesste es da nicht 0x08005000 und
0x08005004 heissen?

Er verwendet aber ein start script im TrueStudio, das VTOR, SP und PC
explizit setzt. siehe oben.

Die SystemInit will doch auch die 'ganze' Adresse ins VTOR schreiben:
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in 
Internal FLASH */

Er setzt da aber nur 0x5000 rein.

Ich mutmasse jetzt natürlich, dass er später ab 0x08000000 eine 
Bootloader
einfügen möchte. Aber jetzt mit TrueStudion nur die Applikation testen
will.
Ist natürlich etwas viel gemutmasst.

Da CubeMX im Spiel ist, wird vermutlich HAL benutzt.

In der HAL Lib gibt es ein Beispiel IAP_Binary_Template das von 
IAP_Main(Bootloader) aufgerufen wird.

Brauchst davon nur den else Zweig:

1

/* Jump to user application */

Irgendwie muss er aber schon wissen wohin der Sprung gehen soll.

Ich entwickle meine Programme immer bei 0x08010000. Erst das Release 
wird für 0x08000000 kompiliert. Grund: Es kommt vor, dass ich zigtausend 
Flashvorgänge bis zum Release brauche. Auf diese Weise lässt selbst ein 
STMF030 (erlaubt wären dort nur 1000 Zyklen) mit gutem Gewissen 
debuggen.

Möglicherweise wusste ich nicht wie man eine "bootloader section" 
erstellt und habe mir deshalb mit einem zweiten Programm geholfen. Das 
zweite Programm müsste nur einmalig als Starterprogramm nach 0x08000000 
geflasht werden. Für "BrilleAuf" könnte es so aussehen:

1

int main(void)

2

{

3

  const void* ImgPtr = (void*)0x08005000;

4

  void (*pMainApp)(void) = *(void (**)(void))(ImgPtr+4);

5

  pMainApp();

6

  return 0;

7

}

Alex D. schrieb:
> Dann wäre es am einfachsten schon jetzt eine bootloader section
> einzubauen und dort nur einen jump zur application machen. Sollte dann
> evtl funktionieren.

Auch wenn er explizit 0x5000 ins VTOR schreibt?

BrilleAuf schrieb:
> Target Software Startup Script anpassen (Truestudio):
> ...
> # Reconfig vector table offset reg to match pp location
> set *0xe000ed08 = 0x5000

Wie gesagt, TrueStudio hab ich nicht.
Also eigentlich bin ich ja auch der Meinung, es ist besser, sofort ein
Bootloader-Placebo zu benutzen.
Dann kann man auch gleich testen ob es ohne Debugger startet.
Man weiss ja nicht so genau, was die da sonst noch so alles
initialisieren.

Es kann doch VTOR nur per -Programm- beschrieben werden. Der Start ist 
dann aber schon geschehen. Die Startadresse in der Vektortabelle wird 
also nicht mehr berücksichtigt. Das heisst, es muss -vorher- für 
passende Daten bei 0x08000000 (eine VT evtl. mit Code) für den Sprung 
zum Programm gesorgt werden. Entweder per zweites Programm oder Einträge 
im Linkerskript evtl. automatisch generiert infolge eines 
Häkchens/Befehls in Truestudio.

"BrilleAuf" hat das Problem vermutlich schon gelöst.

Man braucht kein komplettes Programm, man muss lediglich dafür sorgen, 
dass der Reset-Vektor an 0x0800004 die richtige Adresse (hier: 
0x08005000) beinhaltet. Stackpointer-Initialwert auch an 0x08000000 
eintragen. Dann klappts auch mit dem Starten eine Applikation an 
beliebiger Stelle im Speicher.

Marvin M schrieb:
> Man braucht kein komplettes Programm, man muss lediglich dafür sorgen,

Bist du sicher?

Ich habe das gerade mit einem BluePill Board probiert und es klappt 
nicht.

Mein vorgehen:

1

1. in CubeMX normales Projekt angelegt, PC13 ist LD1

2

2. SW4STM32 Projekt erzeugt

3

3. in der main.c LD1 Blinky eingebaut

4

3.1. in der system_stm32f1xx.c -> #define VECT_TAB_OFFSET  0x00005000U

5

3.2. in der STM32F103C8Tx_FLASH.ld -> 

6

     FLASH (rx) : ORIGIN = 0x8005000, LENGTH = 64K - 20k

7

4. Projekt bauen

8

5. mit STM32CubeProg GUI kontrolliert, Programm liegt an 0x08005000

9

6. bei disconnet startet STM32CubeProg das Programm, es blinkt

10

7. noch einmal CubeMX aufgerufen, verändert, Projekt erzeugt, 

11

die system_stm32f1xx.c und die STM32F103C8Tx_FLASH.ld behalten die Änderungen und werden nicht überschrieben!

12

8. mit dem CubeProgrammer CLI ab Adresse 0x08005000 gestartet, blinkt

13

Aufruf: ./STM32_Programmer.sh -c port=SWD -g 0x08005000

14

15

Ein schreiben von 20005000 und 08005000 an Adresse 0x08000000 funktioniert allerdings nicht. Das Programm startet nicht nach Reset oder PON.

16

17

Startet mit Punkt 8 aber sofort wieder.

Aha, an die 0x08000004 muss nicht 08005000 sondern die wirkliche Start 
Adresse die auch auf 0x08005004 steht, dann läufts.

Dann braucht man wirklich keinen Bootlader oder Sonstiges.

Darth Moan schrieb:
> Er verwendet aber ein start script im TrueStudio, das VTOR, SP und PC
> explizit setzt. siehe oben.
>
> Die SystemInit will doch auch die 'ganze' Adresse ins VTOR schreiben:
> SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in
> Internal FLASH */
>
> Er setzt da aber nur 0x5000 rein.

Ja, aber im VTOR steht dann 0x8005000. Es geht ja hier nur um vereiste 
ISR. Die App würde sonst nicht laufen.

Darth Moan schrieb:
> Ich mutmasse jetzt natürlich, dass er später ab 0x08000000 eine
> Bootloader
> einfügen möchte. Aber jetzt mit TrueStudion nur die Applikation testen
> will.
> Ist natürlich etwas viel gemutmasst.

Liegst aber schon ganz richtig. Deshalb eine 
Grüne-Wiese-Testapplikation.

pegel schrieb:
> Dann braucht man wirklich keinen Bootlader oder Sonstiges.

Ja, das war auch so mein Verständnis...nach dieser Literatur:

http://info.atollic.com/hubfs/Whitepapers/Atollic_Develop_Debug_BootloaderApps_ARMCortex.pdf


..und nein, BrilleAuf hat das Problem noch nicht gelöst :-(

Hänge mal deine fertige hex an, dann versuche ich zu vergleichen.

pegel schrieb:
> Hänge mal deine fertige hex an, dann versuche ich zu vergleichen.

Ich habe das Gefühl, dass Pegel hier schon auf dem richtigen Weg ist.

Das sind jetzt zwei Varianten. eine ohne VT Offset und ein mit VT Offset 
0x5000.

Auf den ersten Blick sieht das gut aus.

Alle Int. Vectoren sind um 0x00005000 versetzt, so wie es sein muss.

Der Tim2 Interrupt an 0x080050B0 ist vermutlich auch richtig belegt.

Es ist nicht ein fehlendes volatile oder so etwas in der Art, oder?

Lass doch deinen Timer2 ein Pin toggeln, am Besten PC13.

Mit Oszi sieht man dann leicht was sich tut.

Man kann in der Hauptschleife mit dem Debugger stoppen. Dann sehe 
ich,dass Systick und Timerwerte erhöht wurden. Die funktionieren, denke 
ich.

Was ich wirklich nicht sicher klären kann ist, warum der aktuelle IR 0x3 
sein soll und was das bedeutet. Man kann das z.B. aus xPSR lesen...Man 
muss dort noch 16 abziehen, also 3-16=-13 :-\

Scheint vllt so zu sein, dass dieser IR alles blockiert...

BrilleAuf schrieb:
> Liegst aber schon ganz richtig. Deshalb eine
> Grüne-Wiese-Testapplikation.

Es soll also einen Bootloader geben. Gibt es den?

In "TestISR.VTOR_5k.hex" ist nichts für den Startbereich (ersten 8 Bytes 
von 0x0800000) definiert. Solange Du diesen nicht definierst (Bootloader 
oder Linkerskript), wird das Laufverhalten definitiv undefiniert sein! 
Es ist daher fraglich was du da debuggst.

OK.

für diesen Test gibt es aktuell keinen BL. Ich probiere hier alles ohne.

Im Linkerfile gibt es genau eine Anpassung:

…
MEMORY
{
FLASH (rx)      : ORIGIN = 0x08005000, LENGTH = 108K   // <-HIER 
angepasst
RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 20K
}
…

Kann es sein, dass der MSP hier noch her muss? :-|

Moin,

BrilleAuf schrieb:
> Was ich wirklich nicht sicher klären kann ist, warum der aktuelle IR 0x3
> sein soll und was das bedeutet. Man kann das z.B. aus xPSR lesen...Man
> muss dort noch 16 abziehen, also 3-16=-13 :-\

Na wenn ich mich nicht verzähle müsste das ja dann der Hard Fault sein.
Wenn also aus irgendeinem Grund der Debugger an Adresse 0x5000 nicht das
selbe liest, wie an 0x08005000 dann könnte er ziemlich bald in den Hard
Fault wollen.
Wenn der Vector, den er zu lesen glaubt aber illegal ist, was dann?
Hattest du mal versucht die set Anweisungen mit 0x08005000 und 
0x08005004
auszuführen?
Kannst du dann den Startup code single steppen?

So ein Verhalten hatte ich nur mal als der Hard Fault versehentlich 
mitten
ins Programm gezeigt hatte. Der wurde angesprungen, und alles unterhalb
war damit blockiert. Ich lief dann irgendwann auf meinen BP, aber eben
nur zufällig.

Darth Moan schrieb:
> Na wenn ich mich nicht verzähle müsste das ja dann der Hard Fault sein.
Ohne Bootloader wäre das eigentlich nicht unerwartet.

BrilleAuf schrieb:
> Kann es sein, dass der MSP hier noch her muss? :-|

Zur Zeit wird zwar der neue Code geflasht, der aktive ist aber 
irgendwas. Dein Linkerskript hat zur Zeit keine oder keine passenden 
Einträge, da im  Hex-File nichts für 0x08000000 definiert ist.

Das Anpassen des Linkerskripts (etwas Code ist auch nötig) wäre zwar 
weniger Arbeit, ist aber deutlich schwerer (viele Fehlerquellen -> 
dauert länger). Da du sowieso einen Bootloader verwenden willst, würde 
ich an deiner Stelle eher das tun. Du bräuchtes dann ein zweites 
Projekt. Beispiel für main.c vom Bootloader:

1

int main(void)

2

{

3

  const void* ImgPtr = (void*)0x08005000;

4

5

  // Set VectorTable

6

  SCB->VTOR = (uint32_t)ImgPtr;

7

8

  // Set Stack Pointer

9

  __set_MSP((*(uint32_t*)ImgPtr));

10

11

  // Set Program Pointer

12

  void (*pMainApp)(void) = *(void (**)(void))(ImgPtr+4);

13

  pMainApp(); // ist eigentlich ein Call statt Jump, aber egal

14

  return 0;

15

}

Da evtl. nach dem Bootloader noch irgendwo falsche Werte für VTOR 
gesetzt werden, füge bitte zu Testzwecken in deiner main.c vom 
Hauptprogramm eine erneute Zuweisung der Vektortabelle durch:

1

SCB->VTOR = 0x08005000;

Ich hatte mich auch schon gefragt, ob ich mich verzählt habe. Scheint 
theoretisch wirklich der Hardfault zu sein. Schön, das es einer 
verifiziert hat.

Die Zusammenhänge erscheinen mir aber komisch. Das fehlt irgendwas :-(

Muss ich mal am WE drüber nachdenken...

Danke an alle für die bisherigen Infos!

BrilleAuf schrieb:
> Die Zusammenhänge erscheinen mir aber komisch. Das fehlt irgendwas :-(

Warum "komisch"???

Da wird irgendwas ausgeführt, da der Bootloader fehlt. Erstelle erst 
einen Bootloader!

Äh, mal ne doofe Frage, muss das Start Script SP setzen oder MSP?
Macht TrueStudio da einen Unterschied?

> set $pc = *(unsigned int*)0x5004

Jump schrieb:
> __set_MSP

Jump schrieb:
> Warum "komisch"???
>
> Da wird irgendwas ausgeführt, da der Bootloader fehlt. Erstelle erst
> einen Bootloader!

Er setzt im Debugger explizit den PC auf seinen Applikations-Einstieg 
und
lässt dann den Core loslaufen. Wenn der Debugger richtig funktioniert,
wovon ich ausgehe, sollte er nicht erst den Core durch den Reset 
schicken.
Aber wer weiss.
Daher die Frage nach dem Steppen.

Darth Moan schrieb:
> Er setzt im Debugger explizit den PC auf seinen Applikations-Einstieg
> und

Wirklich? Hat er das geschrieben?

Jump schrieb:
>> Er setzt im Debugger explizit den PC auf seinen Applikations-Einstieg
>> und
> Wirklich? Hat er das geschrieben?

BrilleAuf schrieb:
> Target Software Startup Script anpassen (Truestudio):
> ...
> # Get app entry point
> set $pc = *(unsigned int*)0x5004

Also ich interpretiere das TrueStudio Start Script genau so.
Aber ich habe TrueStudio nicht, also erstmal nur Vermutung.
Vielleicht sollte ich TrueStudio mal ausprobieren.

Ok, er hat es wirklich geschrieben. Das "Startup Script" betrifft also 
den Debugger und nicht wie ich glaubte den Compiler/Linker. Es sollte 
dann eigentlich ohne Bootloader laufen.

Im "Startup Script" setzt er VTOR, Stackpointer und Entry point. Das 
sieht alles richtig aus. Aber - möglicherweise wird VTOR beim Startup 
seines Programms (EntryPoint bis main.c) unbewusst verändert (bei 
"EmBlocks" würde das nämlich in  SystemInit() passieren). Man könnte 
einen Breakpoint in der main.c setzen und prüfen, ob VTOR (*0xe000ed08) 
tatsächlich noch 0x08005000 ist.

Bernd K. schrieb:
> EmBlocks ist eine IDE, was hat die damit zu tun was der OP in seiner
> SystemInit macht?

Bei EmBlocks wird beim Anlegen eines Standardprojekts Code 
zusammengestellt. Die SystemInit() steht in der Datei 
"system_stm32f10x.c". Als Autor wird "MCD Application Team" genannt. Der 
Code kann bei allen IDE's laufen, muss aber nicht (z.B. geht auch reines 
ASM).

Bernd K. schrieb:
> Ich verstehe nicht was der Zirkus soll. Flash doch einfach schonmal den
> Bootloader drauf, danach...

Nein. Wenn über Debugger (richtig) gestartet, dann braucht man den 
Bootloader nicht. Dort liegt nicht das Problem. (Ich selber würde es 
aber auch über den Bootloader machen.)

Joe J. schrieb:
> ...Alignement...

Gefordert sind 0x200 Alignment und "BrilleAuf" verwendet 0x5000. -> 
passt

Bernd K. schrieb:
> Der Debugger müsste dann aber auch VTOR umstellen bevor er es startet.
> Oder das Programm muss irgendwo beim Start selbst das ...

Unterstreiche ich alles.

Ich habe da noch einen Speziallfall...
Ich verwende den STMF030 sehr häufig. Da der Flash nur 1000 Zyklen 
verträgt, verschiebe ich das Programm beim Debuggen in den oberen 
Flash-Bereich. Ein separater Bootloader ist für diesen speziellen Fall 
ziemlich umständlich. Deshalb pfusche ich den Bootloader direkt mit in 
das Projekt hinein. (Das Ganze macht natürlich nur dann Sinn, wenn der 
Flasher nicht grundsätzlich den gesamten Flash neu beschreibt, sondern 
unveränderte Flash-Seiten erkennt und überspringt.)


Ergänzung bzw. Änderung im Linkerskript:

1

MEMORY

2

{

3

    ROMB (rx) : ORIGIN = 0x08000000, LENGTH = 64   /* neue Zeile */

4

    ROM  (rx) : ORIGIN = 0x0801ac00, LENGTH = 4K   /* bestehende Zeile geändert */

5

    ...

6

}

Ergänzung im Linkerskript:

1

SECTIONS

2

{

3

    .myboot :

4

    {

5

        KEEP(*(.myboot.vtable));

6

        KEEP(*(.myboot.loader));

7

    } > ROMB

8

    ...

9

}

Ergänzung im Quellcode:

1

// Bootloader-Source

2

void __attribute__((naked, optimize("-Os"), section(".myboot.loader"))) MyBoot_Loader()

3

{

4

  extern uint32_t __isr_vector;

5

  SCB->VTOR = (uint32_t)&__isr_vector;

6

  goto *(void*)((&__isr_vector)[1]);

7

}

8

// Bootloader-vtable

9

extern uint32_t __StackTop;

10

__attribute__((section(".myboot.vtable"))) void* MyBoot_VectorTable[2] =

11

{

12

  &__StackTop,

13

  MyBoot_Loader

14

};