Debugger stürzt ab - Nucleo-Board mit STM32WB55, Ubuntu, STM32CubeIDE

Peter Gast #7339730
Lesenswert?
• ▲
▼

Hallo,

ich arbeite mich gerade in den MAC Treiber für die STM32WB55 Controller ein. Die Beispiel-Projekte für MAC-FFD / MAC-RFD laufen auch ohne Fehler. Alledings sind das Demos ohne FreeRTOS, welches ich aber benötige.

Also bin ich hergegangen und habe mir mal das BLE-FreeRTOS Project 'HeartRate' angesehen (nat. auf einem anderen Board mit dem BLE-Treiber für MCU2).

Das Aufspielen der Software funktioniert soweit. Aber nachdem ich den Debugger (STLINK) laufen lasse, läuf er zunächst, bis dann das TransportLayer TL mit TL_Enable() aktiviert wird (Fehlermeldung: Cannot connect to Target).

Jetzt habe ich das Ganze mal umgestöpselt, um mit dem JLINK zu debuggen. Da spielt er mir die Firmware auch auf, und stürtzt danach ebenfalls ab (Fehler: Cannot read register while CPU is running).

Es handelt sich dabei um die Original-Projekte, die ich ohne jegliche Änderung in die STM32CubeIDE importiert habe. Und ich denke, ich kann ausschließen, dass mir beim Flashen der Binaries (zuerst stm32wb5x_FUS_fw.bin, danach stm32wb5x_BLE_Stack_full_fw.bin / stm32wb5x_BLE_Mac_802_15_4_fw.bin) ein Fehler passiert ist. Ich habe das mittlerweile mehrfach gemacht und die MAC-Anwendung ohne FreeRTOS läuft ja auch.

Ich weiss jetzt nicht mehr so recht, was ich da als nächstes testen kann? Kennt jemand das Problem oder hat eine Vermutung?

Danke, Peter

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Peter Gast #7340029
Lesenswert?
• ▲
▼

Erstmal danke für die Hilfe.

Harry L. schrieb:

Wenn sowas mit FreeRTOS passiert, liegt es meist an der Stackgrösse der einzelnen Tasks. Ich würde den Stack der beteiligten Tasks mal testweise vergrössern.

Das war eine sehr gute Idee. Und normalerweise mach ich das auch, sobald bei FreeRTOS irgendwas 'merkwürdig' erscheint. Aber bei einer Demo-Anwendung gehe ich eigentlich davon aus, dass diese gleich mal lauffähig konfiguriert ist.

Jedenfalls stürzt das Programm jetzt an anderer Stelle ab: APPD_Init().

Dirk B. schrieb:

Könnte auch noch mit dem stop-Mode oder abgeschaltetem SWD zusammen hängen.

Und sowas in der Art wars dann jetzt auch: Es war zwar kein abgeschalteter SWD, aber dafür ein falsch gesetztes Flag: CFG_DEBUGGER_SUPPORTED = 0.

So, das nun auf 1 gesetzt und alles geht.

Und ich wiederhole mich: kann man denn nicht davon ausgehen, wenn sich jemand ein Demo-Projekt herunterlädt, dass das dann out-of-the-box lauffähig ist und natürlich auch der Debugger enabled?

Sowas muss doch von vornherein konfiguriert sein. Mann, Mann, Mann, ...

Jedenfalls läuft jetzt alles.

Vielen Dank nochmal, Gruß Peter

Antwort Zitieren Bearbeiten Löschen Beitrag melden
J. S. #7340030
Lesenswert?
• ▲
▼

also beim BLE Beispiel steht das hier in der Projektbeschreibung:

1
 
  - This application is by default configured to support low power mode (STOP1) ( No traces - No debugger )

2
 
    This can be modified in app_conf.h (CFG_LPM_SUPPORTED, CFG_DEBUG_BLE_TRACE, CFG_DEBUG_APP_TRACE)

https://github.com/STMicroelectronics/STM32CubeWB/blob/bceb1dae09f912eae47fba059251d499ba32f4ca/Projects/NUCLEO-WB15CC/Applications/BLE/BLE_HeartRate/readme.txt#L79

oder welches Beispiel hast du für BLE FreeRTOS benutzt?

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter Gast #7340037
Lesenswert?
• ▲
▼

J. S. schrieb:

also beim BLE Beispiel steht das hier in der Projektbeschreibung: - This application is by default configured to support low power mode (STOP1) ( No traces - No debugger ) This can be modified in app_conf.h (CFG_LPM_SUPPORTED, CFG_DEBUG_BLE_TRACE, CFG_DEBUG_APP_TRACE)

https://github.com/STMicroelectronics/STM32CubeWB/blob/bceb1dae09f912eae47fba059251d499ba32f4ca/Projects/NUCLEO-WB15CC/Applications/BLE/BLE_HeartRate/readme.txt#L79

oder welches Beispiel hast du für BLE FreeRTOS benutzt?

Genau das habe ich benutzt. Und wenn das da drin steht, dann ist das lobenswert und ich bin dann auch nicht ganz unschuldig, zugegeben.

Trotzdem: Eine Demo-Anwendung sollte man - so sehe ich das jedenfalls - immer debuggen können. Und zwar ohne erst die richtige Stelle in der Doku zu suchen bzw. zu finden.

Wieder was dazu gelernt.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren