FreeRTOS in hardfault nach BLE User Event

King Julian Gast 06.03.2019 08:07 #5760493

Lesenswert?

•

Ich hab ein CM4 Nucleo und ein BLE shield. Auf dem Cortex läuft FreeRTOS 
mit 3 Tasks.
Einer der Tasks wäre eigentlich für's Abarbeiten der BLE User Events 
zuständig.

void hci_user_evt_proc(void)
  tHciDataPacket * hciReadPacket = NULL;
  /* process any pending events read */
  while (list_is_empty(&hciReadPktRxQueue) == FALSE)
    list_remove_head (&hciReadPktRxQueue, (tListNode **)&hciReadPacket);
    if (hciContext.UserEvtRx != NULL)
      hciContext.UserEvtRx(hciReadPacket->dataBuff);
    list_insert_tail(&hciReadPktPool, (tListNode *)hciReadPacket);


Initialisieren des BLE funktioniert (d.h. ich kann auch darauf 
verbinden). Wenn ich nun aber einen User Event auslöse (z.B. service 
discovery) dann landet der Cortex im HardFault_Handler().
Wenn ich nur den BLE Task am laufen hab oder ihm entsprechend eine 
höhere Priorität gebe dann funktioniert das Ganze.

Hat jemand Erfahrung mit solchen Problemen und kann mir sagen wie ich 
dem auf die Schliche komme? Der BLE Code stammt aus dem ST Beispiel, 
könnte also sein, dass ich da noch Anpassungen machen muss, damit das 
multithread-fähig wird.

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Johnny B. (johnnyb) 06.03.2019 11:12 #5760737

Lesenswert?

•

▲
▼

Das naheliegendste ist, dass dem FreeRTOS zu wenig Speicher zur 
Verfügung steht. z.B. Speicher für die Tasks oder den Heap. Du könntest 
das mal auf gut Glück heraufsetzen oder das in FreeRTOS abfragen 
(uxTaskGetStackHighWaterMark, xPortGetFreeHeapSize).

Antwort Zitieren Bearbeiten Löschen Beitrag melden

King Julian Gast 06.03.2019 13:34 #5760960

Lesenswert?

•

▲
▼

Das scheint es gewesen zu sein!
Dem Task etwas mehr Stack gegeben und es läuft.
Wenn ich hier die Frage noch anhängen darf, wieso hast du direkt auf den 
Stack geschlossen?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

RAc Gast 06.03.2019 15:04 #5761067

Lesenswert?

•

▲
▼

Gehört zur Standardcheckliste. FreeRTOS ist enorm stabil und 
zuverlässig. WENN es Probleme gibt, die nicht in Richtung 
Applikationsprogrammierfehler/Synchronisation o.ä. gehen, ist es sehr 
oft entweder ein geplatzter Taskstack, eine fehlerhafte dynamische 
Speicherverwendung (doppeltes free, Wiederverwendung bereits befreiten 
Speichers, Überschreiben von alloziiertem Speicher etc) oder fehlerhafte 
Betriebssystemkonfiguration (falsch definierte Taskprioritäten etc). Ich 
gucke immer erst auf diese drei Dinge, wenn ein Fault irgendwo "aus dem 
Nichts" einschlägt. In 80% der Fälle

Viele IDEs bieten auch FreeRTOS plugins an, die Dir zum Faultzeitpunkt 
eine Analyse der Tasks anbieten. Da FreeRTOS so konfiguriert werden 
kann, dass es beim Anlegen eines Taskstacks den gesamten Stack mit einer 
konstanten Signatur belegt, sind geplatzte Stacks recht schnell als 
Fehlerquelle identifizierbar.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

RAc Gast 06.03.2019 15:05 #5761068

Lesenswert?

•

▲
▼

<zu schnell Absenden gedrückt>

In 80% der Fälle hat man den Fehler damit.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Johnny B. (johnnyb) 06.03.2019 16:25 #5761167

Lesenswert?

•

▲
▼

King Julian schrieb:
> wieso hast du direkt auf den Stack geschlossen

Ist bei mir auch schon mal passiert mit dem Hardfault, darum kam mir 
dieses Verhalten bekannt vor.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Daniel Gast 06.03.2019 16:35 #5761181

Lesenswert?

•

▲
▼

Das übliche Vorgehen ist, mit JTAG nachzuschauen bei welcher Instruktion 
die CPU in die Exception gesprungen ist.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

RAc Gast 06.03.2019 17:14 #5761235

Lesenswert?

•

▲
▼

Daniel schrieb:
> Das übliche Vorgehen ist, mit JTAG nachzuschauen bei welcher
> Instruktion
> die CPU in die Exception gesprungen ist.

Das hilft aber leider oft nicht. Ein Stacküberlauf z.B. wird erst dann 
Folgeprobleme generieren, wenn auf den korrumpierten Speicher 
zugegriffen wird, was viele viele viele Instruktionen nach dem 
tatsächlichen Übertrampeln des Speichers sein kann. Je nachdem was in 
dem überschriebenen Speicherbereich liegt, kann das ein komplett Anderes 
Fehlerbild sein. In sofern ist eine Analyse der Task stacks (vor Allem 
wenn die IDE das unterstützt) ein guter erster Filter.

Was tatsächlich helfen würde wäre ein Trace, aber für den brauchst Du 
beim Cortex zusätzlich herausgeführte Leitungen, eine teurere Probe und 
eine IDE, die die Tracedaten aufbereiten kann (das ist eine recht 
diffizile Angelegenheit, weil der Cortex die Tracedaten komprimiert 
liefert, d.h. die IDE muss dazu in der Lage sein, die Daten an Hand der 
Imagedatei wieder zu entpacken).

Antwort Zitieren Bearbeiten Löschen Beitrag melden

FreeRTOS in hardfault nach BLE User Event

Antwort schreiben