Spurious UsageFault bei STM32F4,

[Robert S. (razer)]

Habe ein SM32F4 Discovery mit Ethernet Phy (DM83848) am laufen. Am uC 
läuft FreeRTOS zusammen mit lwIP. Genauer gesagt es läuft ein Beispiel 
Webserver aus den Sourcen von ST.

Nun folgendes verhalten: Bei einem Ethernet-Stresstest (wget der 
index.html) habe ich undefinierte UsageFaults mit dem dem Unaligned Bit 
gesetzt.

Ein Stack-Trace im UsageFault Handler ergibt folgende Register:

R0:  0x00000023
R1:  0x20002308
R2:  0x20002201
R3:  0x200016D8
R12: 0x200033F8
LR:  0x080093E7
PC:  0x08008E0C
PSR: 0x00000000

An der Adresse des Program Counters steht folgender Befehl:

   278:         ethernet_input(msg->msg.inp.p, msg->msg.inp.netif); 
   279:       } else 
   280: #endif /* LWIP_ARP */ 
0x08008E0A 9A00      LDR           r2,[sp,#0x00]
0x08008E0C E9D20102  LDRD          r0,r1,[r2,#0x08]
0x08008E10 F7FAFB06  BL.W          ethernet_input (0x08003420)
0x08008E14 E004      B             0x08008E20

Wie gesagt, dieses Verhalten ist "zufällig", tritt nach einigen 100 
Zugriffen auf.

Hat jemand eine Idee woran das liegen kann - oder woran man näher an die 
Ursache kommt?

lg Robert

[Matthias (Gast)]

Im Zweifelsfall mal die üblichen verdächtigen abklopfen:

1. Stack / Heapgrenzen
2. Amoklaufende Pointer
3. Besonderheiten des Prozessor Cores
4. Errata vom Hersteller

Beim FreeRTOS kannst Du dir für alle Tasks den Abstand zur Oberkante 
ausgeben lassen. Es gib dafür eine speielle Funktion. Man muss sich 
allerdings ein wenig drum herumbasteln, da die eine ganz schöne Menge 
Text in ein übergebenen Speicherbereich schaufelt (das erfordert 
Augenmaß, da die Leute, die das Programmiert haben, leider keinen 2. 
Parameter für die Arraygröße eingebaut haben)

Alternativ müsste man sich das Alignment der Stacks vom Compiler her 
anschauen. Ich weiß nur vom GCC, dass da irgendwas mal gebastelt werden 
musste.

[Marcus H. (mharnisch)]

Robert S. schrieb:
> [...] undefinierte UsageFaults mit dem dem Unaligned Bit
> gesetzt.
>
> [...]
>
> R2:  0x20002201
>
> [...]
>
> 0x08008E0C E9D20102  LDRD          r0,r1,[r2,#0x08]
>
> Hat jemand eine Idee woran das liegen kann - oder woran man näher an die
> Ursache kommt?

LDRD muss auf word aligned Daten zugreifen.

--
Marcus