2017-05-17 7 views
4

ARM Cortex M3 (LPC1519)ARM M3 verlagern Code -> Fehler

Ich habe einen Bootloader geschrieben (die so weit scheint zu funktionieren), die in Flash läuft und schreibt das Programm in den Flash (hinter dem Bootloader). Das Programm wird geschrieben und beginnt ordnungsgemäß zu laufen (zumindest beim Debuggen).

Wenn ich den SEGGER Ozone Debugger benutze, kann ich einen Breakpoint auf 'main' setzen und durch die Firmware gehen. Allerdings, wenn ich einen größeren reagion in Code (zu einem anderen Haltepunkt) laufen, bekomme ich immer einige unerwartete Unterbrechungen:

  • UsageFault_Handler
  • BusFault_Handler
  • usw.

Dies geschieht nicht , wenn ich den Code Befehl für Befehl durchschritt. Es scheint, dass die Interrupts nicht richtig funktionieren.

Das Programm läuft gut, wenn ich es an Adresse 0x00000000 blinken. Ich habe das Linker-Skript so geändert, dass der Ursprung beim späteren Offset liegt (wo der Bootloader die Firmware platziert).

Hat jemand ähnliche Probleme erlebt?

Danke, Johann

PS: sorry ich eine minimale Probe nicht zur Verfügung stellen kann, denn ich weiß nicht, wo

bearbeiten starten - Weitere Informationen: ich heruntergeladen jetzt einen kleineren Projekt, wo ich einen Fehler im Debugger finden kann. Es gibt eine Variable uint32_t in einer Struktur, die den Fehler auszulösen scheint. Dort heißt es:

Mis-alligned Speicher lesen: Adresse: 0x00001596, NumBytes: 8, Ausrichtung: 4 (Word bündig)

In der Tat 0x1596 nicht devideable ist von 4, so ist der Fehler gerechtfertigt, aber wie kann das sein? Sollte der Compiler nicht darauf achten, Variablen in Strukturen auszurichten?

Bearbeiten - Zusätzliche Informationen: Es scheint, dass dieser Fehler immer auftritt, wenn der USART0 IRQ ausgelöst wird Könnte es möglich sein, dass ich ein Problem mit Interrupts habe? Der ARM Cortex SysTick (SysTick_Handler) läuft gut !?

[[noreturn]] 
inline void startFirmware(std::uint32_t address) noexcept 
{ 
    //<removed checks for correct address> 

    //pointer to the address 
    const auto ptr = reinterpret_cast<std::uint32_t*>(address); 

    // Set vector table offset 
    SCB->VTOR = address & SCB_VTOR_TBLOFF_Msk; 

    // Set top stack handler 
    __set_MSP(*ptr); 

    // Get address of reset handler 
    const auto resetHandler = *(ptr + 1); 

    // Jump to reset handler 
    reinterpret_cast<internal::ResetHandlerFunction>(resetHandler)(); 
    while(true); 
} 

bearbeiten - Weitere Informationen: Es scheint, dass alle von USART ausgelöst Alarme, CCTimer usw. in Ausnahmen am Ende, aber ich kann den Grund, warum es nicht herausfinden.

+1

Haben Sie die Vektortabelle an den Anfang Ihrer Hauptanwendung verschoben? –

+0

Tatsächlich ist 0x1594 durch 4 teilbar (aber nicht durch 8)! –

+0

ja, aber nicht 0x1596. Ich hatte es richtig in der Fehlermeldung, aber versäumt es im folgenden Satz ;-(behobene es - danke – Traummaennlein

Antwort

2

Ich fand heraus, warum die Interrupts nicht funktioniert hätten.

Im ARM Doku fand ich diesen Satz:

Wenn TBLOFF Einstellung, müssen Sie die auf die Anzahl der Ausnahme Einträge in der Vektortabelle versetzt auszurichten. Die minimale Ausrichtung ist 32 Wörter, genug für bis zu 16 Interrupts. Für weitere Interrupts passen Sie die Ausrichtung an, indem Sie auf die nächste Potenz von Zwei aufrunden. Wenn beispielsweise 21 Interrupts erfordern, muss die Ausrichtung an einer 64-Wort-Grenze liegen, da die erforderliche Tabellengröße 37 Wörter und die nächste Potenz von zwei 64 ist. Weitere Informationen zur Ausrichtung finden Sie in der Herstellerdokumentation für Ihr Gerät.

Das bedeutet, wenn Sie mehr als 16 Interrupts haben, können Sie Ihre SCB- nicht platzieren> VTOR an Adressen, die 32-Wort sind alligned (mit 0x80 endet), aber nur zu 64 Wort ausgerichtete Adresse (Ende mit 0x00). In meinem Fall 0x1100 statt 0x1080 (ich benutze die ersten 128byte für Informationen über das Programm, die der Bootloader verifizieren kann).

Verwandte Themen