Benutzerdefinierte Bootloader für Kinetis MKE06Z Mikrocontroller auf IAR EWARM Ausgabe

Question

Zuerst möchte ich mich vorstellen, wie ich neu auf der Website bin. Ich bin ein Elektroniker, spezialisiert auf Design und Entwicklung von Embedded Systemen. Ich habe lange Zeit Informationen von der Seite gesammelt, und ich denke, dass es viele Leute mit sehr viel Wissen gibt. Ich hoffe, dass andere von Ihnen über dieses oder ein ähnliches Problem gestolpert sind.

Ich habe einige Probleme bei der Implementierung eines benutzerdefinierten Bootloaders für einen Kinetis MKE06Z Mikrocontroller, nicht im Bootloader selbst, sondern in der Verlagerung des Anwendungscodes und des Verhaltens nach dem Springen zu ihm. Die Anwendung ist vollständig in C codiert.

Der Bootloader führt alles wie erwartet aus und bestimmt, ob er ausgeführt werden oder zur Benutzeranwendung springen soll. Dies ist die Sequenz, die den Sprung implementiert:

__disable_interrupt(); 
SCB->VTOR = RELOCATION_VECTOR_ADDR & 0x3FFFFE00; 
JumpToUserApplication(RELOCATION_VECTOR_ADDR); 

wo:

void JumpToUserApplication(uint32_t userStartup) 
{ 
    /* set up stack pointer */ 
    asm("LDR r1, [r0]"); 
    asm("MOV r13, r1"); 
    /* jump to application reset vector */ 
    asm("ADDS r0,r0,#0x04 "); 
    asm("LDR r0, [r0]"); 
    asm("BX  r0"); 
} 

als in Frescale des AN4767 umgesetzt.

So weit, so gut. Sobald der Sprung ausgeführt wird, verfolge ich das Anwendungsverhalten (im Disassembly-Fenster) und finde nach einigen Anweisungen heraus, dass es bei einer bestimmten Adresse mit einer Sprunganweisung blockiert wird, die letztendlich eine Endlosschleife ist. Ich führe es dann Schritt für Schritt durch, um festzustellen, welcher Befehl diese Fehlfunktion verursacht hat. Es ist sehr merkwürdig, da es OK läuft und plötzlich zu einer RAM-Adresse springt. Ein paar Zyklen und springt dann in die Endlosschleife. Ich habe die Adressen notiert, bei denen der Befehl diesen merkwürdigen Sprung verursacht hat und der mit der Endlosschleife. Ich schaue auf die Kernregister und finde heraus, dass es eine Ausnahme gibt, und bemerke, dass es die Nummer 0x03 (Hard Fault) ist. Wechseln Sie dann zum Debuggen der Benutzeranwendung.

Sobald in der Benutzeranwendung, starte ich Debuggen. Die Benutzeranwendung läuft einwandfrei (kein Sprung vom Bootloader). Dann suche ich nach den relevanten Adressen und entdecke, dass die Routine, die den harten Fehler beim Sprung vom Bootloader verursacht, von IAR: __iar_data_init3 stammt. Die Sache ist, es ist Teil einer vorkompilierte Bibliothek, und ich bin nicht sicher, ob es sicher ist, um es zu entfernen (durch die __iar_program_start entfernt und direkt mit dem Aufruf von main auf der Startdatei ersetzt

Die eigentliche Frage ist.: Warum verhält sich die Anwendung nach dem Sprung vom Booloader, aber nicht, wenn es keinen solchen Sprung gibt? Warum springt diese Routine zu einer RAM-Adresse (wenn nicht?)

Natürlich kann es eine sein wenig bis spezifisch, aber hoffentlich gibt es jemanden, der mir helfen kann

Answer 1

Es scheint, dass etwas, das IAR mit der Linkerkonfiguration tut, nicht sehr klar ist, aber etwas damit zu tun hat dieses Problem. Die Sache ist, ich .text Segment verlegt:

define symbol __ICFEDIT_intvec_start__ = 0x00001800; 
define symbol __ICFEDIT_region_ROM_start__ = 0x00002000; 
define symbol __ICFEDIT_region_ROM_end__ = 0x0000FFFF; 

define region APP_ROM = mem:[from (__ICFEDIT_region_ROM_start__) to (__ICFEDIT_region_ROM_end__)]; 

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec }; 
place at start of APP_ROM { readonly section .text }; 

Es scheint, dass die Linke nicht weiß dies zu schätzen und etwas machen die App schlecht benehmen beim Springen von anderen App. Statt dessen wurde das Problem behoben, indem die ursprüngliche ICF-Datei beibehalten und in der GUI nur die .intvec_start-Datei bearbeitet wurde. Der Code beginnt jedoch direkt neben der Vektortabelle. Kein Problem, aber ich wollte den Code etwas weiter verschieben.

Danke.