BLE Nano OTA DFU Bootloader Beispiel läuft nicht

[Markus S. (1fc_schinkenwurst)]

Hallo zusammen,

ich benutze aktuell das BLE Nano v2 mit dem nrf52832 drauf und einen 
DAPLink USB-Dongle zum programmieren. IDE ist Eclipse mit gcc und nrf5 
SDK v14.2. Mein Ziel ist es, Software über BLE aufzuspielen, also habe 
ich das Beispiel bootloader_secure_ble aus dem SDK nach diesem Tutorial 
versucht aufzuspielen: 
https://devzone.nordicsemi.com/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader
Ich habe die Funktion leds_init() & buttons_init() an das BLE Nano 
angepasst, die Datei dfu_public_key.c mit einem neuen public key 
aktualisiert und zusammen mit dem s132 softdevice v4.0, meiner Anwendung 
und den bootloader Einstellungen per Drag and Drop geflasht. Meine 
Anwendung läuft gut und ich komme auch in den dfu-Modus durch Drücken 
des Tasters -> LED leuchtet, aber ich kann kein advertisen feststellen. 
Außerdem springt der Bootloader im dfu-Modus nach der in der sdk_config 
angegebenen Zeit nicht mehr zu meiner Anwendung zurück.
Hat das schonmal jemand von euch gemacht und kann eventuell 
weiterhelfen? Ich bin im Moment leider ratlos..

Danke im Voraus
Markus

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Markus S. schrieb:
> Meine
> Anwendung läuft gut und ich komme auch in den dfu-Modus durch Drücken
> des Tasters -> LED leuchtet, aber ich kann kein advertisen feststellen.



Hast Du Dich in dem Moment mal mit einem Debugger verbunden und Dir den 
Callstack angeguckt?

[Markus S. (1fc_schinkenwurst)]

Ja habe den Debugger angeschmissen, leider mit mäßigem Erfolg ;) Im 
Anhang das Debug-Fenster von Eclipse mit dem Call Stack im dfu-Modus. 
Zuletzt wird der Timer gestartet um dann nach dem Ablaufen die Anwendung 
zu starten. Außerdem habe ich noch die Log-Funktion aktiviert und 
nochmals ohne Anwendung getestet, also nur softdevice und bootloader. 
Hier die Ausgabe:

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> app: in weak nrf_dfu_init_user
<debug> app: In real nrf_dfu_init
<debug> nrf_dfu_settings: Running nrf_dfu_settings_init(sd_irq_initialized=false).
<debug> nrf_dfu_flash: Calling nrf_dfu_flash_init(sd_irq_initialized=false)...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> app: Initializing the clock.
<info> clock: Function: nrf_drv_clock_init, error code: NRF_SUCCESS.
<debug> app: Enter nrf_dfu_continue
<error> app: Single: Invalid bank
<debug> app: Enter nrf_dfu_app_is_valid
<debug> app: Return false in valid app check

Der Error kommt weil keine gültige Anwendung gefunden wurde. Ich kann 
irgendwie nichts außergewöhnliches finden...

Grüße
Markus

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Markus S. schrieb:
> Der Error kommt weil keine gültige Anwendung gefunden wurde. Ich kann
> irgendwie nichts außergewöhnliches finden...

Das sieht so aus, als hättest Du nocht irgend welche Interrupt-Quellen 
aktiv, wenn Du den Bootloader aktivierst. Oder evtl. sogar den Watch Dog 
Timer? Es kann aber auch sein, dass der Debugger das "falsch" zu 
WDT_IRQHandler auflöst und in Wirklichkeit der Default_Handler 
ausgeführt wird. (Das kannst Du im Map-File oder lis-File nachgucken)

[Markus S. (1fc_schinkenwurst)]

Ich habe im Debug-Modus das Programm einfach laufen lassen und dann 
pausiert um den Screenshot zu machen. In der map-file stehen für 0x78c2a 
sämtliche IRQHandler. Unter anderem auch der Default_Handler und 
WDT_IRQHandler:

...
0x00078c2a                WDT_IRQHandler
...
0x00078c2a                Default_Handler
...

Von meiner Anwendung her dürften keine Interrupts aktiviert sein, das 
ist nur eine einfache LED-Blinklicht-Hello-World Anwendung die mit 
nrf-delay realisiert wurde. Und der Bootloader ist eigentlich reiner 
Beispielcode, mit Ausnahme der Anpassung der Pins für LED und Taster. 
Kann natürlich sein, dass der Button um den Bootloader zu aktivieren mit 
einem Interrupt abgefragt wird. Auch könnte der Timer, der für den 
Sprung zum Hauptprogramm nach einer bestimmten Zeit verantwortlich ist, 
dann einen Interrupt auslöst.

Gruß Markus

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Markus S. schrieb:

> Von meiner Anwendung her dürften keine Interrupts aktiviert sein, das
> ist nur eine einfache LED-Blinklicht-Hello-World Anwendung die mit
> nrf-delay realisiert wurde.

Beide Handler haben die selbe Adresse. Es wird also der Default_Handler 
ausgelöst. Grund hierfür wird Dein delay sein, das wahrscheinlich auf 
dem Systick Timer aufsetzt, welches einen Interrupthandler hat, wechler 
periodisch einen globale Variable hoch zählt.

> Auch könnte der Timer, der für den
> Sprung zum Hauptprogramm nach einer bestimmten Zeit verantwortlich ist,
> dann einen Interrupt auslöst.

Genau, wäre auch mein Favorit. Das könnte man aber auch als Bug in der 
Aktivierung des Bootloaders bezeichnen. Du kannst das ja mal bei Nordic 
einkippen, die sind ja eigentlich ganz offen für soetwas.

Ansonsten entweder alle Interrupts vor dem Ändern der vector table 
abschalten, oder eine extra Runde durch einen Reset drehen und dann 
direkt nach dem Reset den Bootloader starten.

mfg Torsten

[Jim M. (turboj)]

Markus S. schrieb:
> Von meiner Anwendung her dürften keine Interrupts aktiviert sein

Wieso sehe ich dann app_timer im Call Stack? Dort sind 2 Interrupt 
Handler mit drin (RTC und EGU).

Leider sind alle default Handler dieselbe Funktion, so dass man nicht 
sieht welcher Handler es wirklich war.

Ich tippe auf HardFault, denn sollte man sich sowieso definieren - damit 
man eigene Programmierfehler schneller findet.

[Markus S. (1fc_schinkenwurst)]

Habe das "Problem" "gelöst" bekommen. Ich habe mit der nrfConnect App 
auf einem Android Pixel Tablet gearbeitet. Diese entdeckt mein BLE Nano 
nicht im Bootloader Modus. Dieselbe App auf einem iPad erkennnt es und 
das Update funktioniert dann auch. Keine Ahnung woran das jetzt liegt.. 
Aber trotzdem danke für eure Mühe.

Grüße Markus