Fehlersuche Hardfault ATSAME70Q19B

[Oliver T. (Firma: Pierenkemper GmbH) (oliver1968)]

Hallo,

wir setzen in einem neuen Projekt den Microchip µC ATSAME70Q19B ein. Wir 
haben hier auf mehreren Muster LPs das Problem, dass uns die Firmware 
regelmäßig in einen Hardfault Interrupt läuft.

Die Analyse des Hardfault Interrupts hat ergeben, dass der 
Programcounter verbogen ist und zwischen 2 gültigen Assembler Befehlen 
steht. Das BFAR Register ist leer. Das entsprechende Bit ist auch nicht 
gesetzt.

Das Projekt ist nicht komplett neu sondern sowohl die Firmware als auch 
die Hardware von einem bestehenden Produkt abgeleitet, das seit Jahren 
erfolgreich produziert wird. Der größte Unterschied zu dem laufenden 
Produkt ist, dass 48 GPIOs (PORTA und PORTC) des µC als Output 
konfiguriert werden und diese über Pegelkonverter jeweils einen MOSFET 
ansteuern. In der Firmware wird die ASF verwendet. RTOS kommt nicht zum 
Einsatz.

Die GPIOs werden direkt über die Portregister durch Beschreiben mit 
jeweils einer Bitmaske für PortA und PortC als Output konfiguriert.

Fehlerbild 1:
Während des Betriebs werden immer paarweise 2 Pins mit einer Frequenz 
von z.B. 80Hz für eine Impulszeit von z.B. 350µs auf High gesetzt. Das 
geht eine gewisse Anzahl an Loops gut. Dann tritt der Hardfault auf. Wir 
konnten nun den Fehler auf die Pins PC21 und PC22 eingrenzen.
Werden diese Pins aus der Config- Bitmaske entfernt, tritt der Fehler 
nicht mehr auf.
Werden diese Pins in Richtung Hardware mit 2 anderen Pins getauscht, 
bleibt der Fehler auf den Pins PC21 und PC22.
Werden diese Pins komplett von der Hardware abgetrennt, tritt der Fehler 
nicht mehr auf.
Die Signale der beiden Pins sind, was die Flanken und die Pegel angeht, 
perfekt.
Die Versorgungsspannung des µC ist stabil und bricht im Fehlerfall nicht 
ein.
Wenn ich im Code eine Funktion ergänze, so dass der Code anders im 
Speicher des µC platziert wird, tritt der Fehler reproduzierbar nicht 
mehr auf. Die Funktion wird niemals aufgerufen. Es reicht aus, wenn die 
Funktion nur im Code vorhanden ist.
Wir haben in der Hardware PC21 und PC22 gegen PC13 und PC14 getauscht. 
Seit einer Woche arbeite ich täglich mit dieser Hardware und ich konnte 
keinen Hardfault IRQ mehr beobachten.

Fehlerbild 2:
Wenn es ganz schlecht läuft, tritt der Hardfault IRQ Fehler bereits im 
Zuge der Konfiguration der Port Register als Output in der Init auf. 
Hier werden die Port A und Port C Register mit Konstanten beschrieben.
Wenn wir die Bitmasken um mehrere Bits reduzieren, tritt der Fehler 
nicht mehr auf. Teilweise müssen bis zu 4 Bits aus der Maske entfernt 
werden. Hier lässt sich der Fehler nicht eindeutig auf bestimmte Bits 
eingrenzen.
Wenn ich innerhalb der Register Config Befehle in der Init einen 
Haltepunkt setze und die Firmware nach dem Stopp über den Debugger 
wieder starte, läuft die Firmware anschließend komplett fehlerfrei. 
Fehlerbild 1 tritt nicht mehr auf.

Bisher konnten wir die eigentliche Ursache des Fehlers nicht 
identifizieren. Wir freuen uns daher über jeden Hinweis. Vielen Dank 
schon mal.

Gruß

[Wilhelm M. (wimalopaan)]

Oliver T. schrieb:
> Werden diese Pins in Richtung Hardware mit 2 anderen Pins getauscht,
> bleibt der Fehler auf den Pins PC21 und PC22.

Was soll das heißen?

[Andreas H. (ahz)]

Oliver T. schrieb:
> Die Analyse des Hardfault Interrupts hat ergeben, dass der
> Programcounter verbogen ist und zwischen 2 gültigen Assembler Befehlen
> steht. Das BFAR Register ist leer. Das entsprechende Bit ist auch nicht
> gesetzt.

Bist Du da sicher? Manche debugger kommen da durcheinander, wenn Du 
ihnen nur eine Adresse "hinwirfst".
Wenn Du einen Breakpoint in den Faulthandler setzt und der BP erreicht 
wird, dann ist die Adresse definitiv ok, oder?
Wenn Du die Adresse per Hand im Faulthandler überprüfst, dann aufpassen, 
welchen Stack Du Dir anschaust (process- oder Masterstack).
Ansonsten, nachdem der Faulthandler abgearbeitet wurde, mal einen 
(Assembler) SingleSpep im Debugger machen. Gibt es dann noch einmal 
einen Hardfault oder wird die (Asm-Anweisung ausgeführt?


Wenn Du mit "das "entsprechende Bit" das BFARVALID Bit meinst, dann war 
es kein Busfault. Was steht denn im CFSR Register?

> Werden diese Pins komplett von der Hardware abgetrennt, tritt der Fehler
> nicht mehr auf.
Das heisst, ihr trennt die Pins von der Elektronik auf dem PCB ab? Oder 
disabled ihr die Pinfunktion im Device?

Im ersten Fall wäre es interessant die Schaltung auf dem PCB zu sehen, 
insbesondere welche Rückkopplungen es zum M7 gibt.