FreeRTOS in hardfault nach BLE User Event

[King Julian (Gast)]

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.

[Johnny B. (johnnyb)]

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).

[King Julian (Gast)]

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?

[RAc (Gast)]

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.

[RAc (Gast)]

<zu schnell Absenden gedrückt>

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

[Johnny B. (johnnyb)]

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.

[Daniel (Gast)]

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

[RAc (Gast)]

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).