hardfault in cortex m3

[Arne Helms (Gast)]

Hi,

ich versuche gerade ein Freertos auf dem sam3s4b zum Laufen zu bringen, 
dabei geht er allerdings in den Hardfault bei xTaskCreate().

Hier die Daten vom Handler und der entsprechende Assembler code:

r0  68
r1  0
r2  100
r3  100
r12  0x404729
lr  0x400987
pc  0x401354
psr  0x81000000



          xTaskGenericCreate:
00400954:   push {r7, lr}
00400956:   sub sp, #40     ; 0x28
00400958:   add r7, sp, #8
0040095a:   str r0, [r7, #12]
0040095c:   str r1, [r7, #8]
0040095e:   str r3, [r7, #0]
00400960:   mov r3, r2
00400962:   strh r3, [r7, #6]
 506        if( pxNewTCB != NULL )
0040098a:   ldr r3, [r7, #24]
0040098c:   cmp r3, #0
0040098e:   beq.w 0x400b00 <xTaskGenericCreate+428>
 530            pxTopOfStack = pxNewTCB->pxStack + ( usStackDepth - ( 
unsigned short ) 1 );
00400992:   ldr r3, [r7, #24]

          prvAllocateTCBAndStack:
00401344:   push {r7, lr}
00401346:   sub sp, #16
00401348:   add r7, sp, #0
0040134a:   mov r3, r0
0040134c:   str r1, [r7, #0]
0040134e:   strh r3, [r7, #6]
00401350:   mov.w r0, #68   ; 0x44
00401354:   blx 0x0
00401358:   mov r3, r0
0040135a:   str r3, [r7, #12]
0040135c:   ldr r3, [r7, #12]
0040135e:   cmp r3, #0

Was mich sehr irritiert ist das blx 0x0. Bedeutet dies "spring an 
Adresse 0"? Das könnte ja auch nicht wirklich gut gehen. Aber woher 
könnte das dann kommen?

Naja,

Viele Grüße und Vielen Dank,

Arne

[benedikt (Gast)]

BLX 0x0 bedeutet tatsächlich "springe zu Adresse 0" (und schreibe die 
Rücksprungadresse in LR). Woher stammt dieser Assembler-Code? Wenn er 
aus einem Objectfile vor dem Linken kommt, ist das möglicherweise eine 
noch unvollständige Anweisung, die erst der Linker mit der Springadresse 
auffüllt (nämlich genau dann, wenn die aufzurufende Funktion in einer 
anderen Compilation-Unit liegt, d.h. in einer anderen Quelldatei liegt).

[Arne Helms (Gast)]

benedikt schrieb:
> BLX 0x0 bedeutet tatsächlich "springe zu Adresse 0" (und schreibe
> die
> Rücksprungadresse in LR). Woher stammt dieser Assembler-Code? Wenn er
> aus einem Objectfile vor dem Linken kommt, ist das möglicherweise eine
> noch unvollständige Anweisung, die erst der Linker mit der Springadresse
> auffüllt (nämlich genau dann, wenn die aufzurufende Funktion in einer
> anderen Compilation-Unit liegt, d.h. in einer anderen Quelldatei liegt).

Danke,habs jetzt auch hingekriegt. Du hattest Recht, war ein 
Linkerproblem. Ich habe einfach die Dateien timer.c und heap_1.c aus 
Freertos nicht mit in den C sourcen stehen, sodass er es eigentlich 
nicht linken konnte. Dass ich keinen Fehler und keine Warnung bekommen 
habe, macht mir ein wenig sorgen.

Also für das nächste mal: wenn an Adresse 0 gesprungen werden soll, 
einfach mal gucken, ob alle Sourcen mitkompiliert sind

Viele Grüße,

Arne