bootloader stuck in wait_for_events if started programatically

[Tamas Varga]

Hi,

I have modified slightly the OTA bootloader sample in SDK6.1 and SoftDevice 7.1.0. After flashing the bootloader code to the nrf51822 it works like charm, I can update the firmware on the module OTA with MCP. If I upload OTA a modified version of hrs example code in SDK with OTA DFU support, the bootloader gets started by writing 0x01 to the DFU control characteristic, but afterwards it is stuck in wait_for_events function in bootloader.c. I use gcc 4.9.3 as compiler on Linux. Do you have any ideas what I should check?

I have checked with the unmodified codes in SDK v6.1. DFU does not work with MCP with those codes either. Is gcc problematic with bootloader?

Thanks,

Tamas

[Hung Bui]

Hi Tamas,

MCP v3.7 should work with DFU from SDK v6.1. Could you try and test with stock example (ble_app_hrs_dfu) in SDK v6.1 and let me know the result ?

Note that the ble_app_hrs_dfu won't do a chip reset, but jump directly from the application code to the bootloader when writing 1 to DFU control characteristic. So in the bootloader you should not reinitialize the softdevice when triggered from application.

Attached file: ble_app_hrs - TestDFU.zip ble_app_hrs_dfu.hex

[Tamas Varga]

Hi,

I have checked the unmodified sources as well, but the problem persisted. Speaking of unmodified sources I should note that I have moved the bootloader to address 0x35000 instead of 0x3C000 by altering linker script and bootloader address in header files. May it be relevant to the issue? Are you aware of any gcc issues that may cause this behaviour?

As a temporary workaround I have modified the bootloader and the application code to do a system reset and reinitialize the SD upon a DFU start command and then I could do OTA updates, but as I have read (and as you have written in your answer above), the SDK6.1 way of doing DFU update is that does not need a system reset nor reinitializing SD, so I would like to revert back to ble_app_hrs_dfu example's original intended behaviour.

Thanks for your help,

Tamas

[Tamas Varga]

I've uploaded some additional information.

I use gcc Makefile for bootloader (Board/nrf6310/device_firmware_updates/bootloader/gcc/Makefile) with the following contents: Makefile

I use gcc Makefile for hrs application (Board/nrf6310/s110/ble_app_hrs/gcc/Makefile) with the following contents: Makefile

Source codes are not modified, just the bootloader start address is altered to 0x35000 in dfu_types.h and linker script. I'm pretty sure I miss something trivial, but I don't know what it is.

Board is custom made, an I2C sensor is connected to MCU.

[Hung Bui]

Hi Tamas,

I summarize what I understand from your replies here please correct me if I am wrong:

• You modified the bootloader so the start address is at 0x35000 (because you remove optimization I guess)

• The modified bootloader worked fine with MCP that you can update different application firmwares and you used a button to enter DFU mode.

• The modified bootloader doesn't work if you use the ble_app_hrs_dfu application and trigger the DFU by writing to the DFU control characteristic

If it is the case, I think the easiest fix is to modify the bootloader_start() function in dfu_app_handler.c so that it will do a soft reset with sd_nvic_SystemReset after you have set the flag with sd_power_gpregret_set, note that you should also modify the bootloader source code so that it will reinitialize the softdevice, init_softdevice in ble_stack_init() should = true all the time.

What we do with this workaround is to set a flag and do a reset, and then the bootloader will start pretty much the same way as holding a button when reset (which worked fine for you).

It's pretty strange to here that it stuck at at wait_for_events(), how do you check that ? Step by step walkthrough with the code won't work with the softdevice active. Do you see the DFU bootloader advertise after the device enter DFU mode ?

[Tamas Varga]

Hi,

Your are correct, just a remark: for the first time I enter bootloader mode because there's no application on device, button is not needed nor it is available on the board. The workaround you have suggested is the workaround I have used, but I would like to use the official code to the extent possible for easy migration to new SDK versions if I should. I do see the DFU bootloader advertisement after entering DFU mode, but after connection it gets stuck. I see that the code is stuck at wait_for_events() by issuing gpio_pin_toggle command in the bootloader code. During transfer the led blinks rapidly but blinking is seen by eye (as events are arriving), after the problem arises, the led is lit with approximately half power because of rapid toggle of GPIO pin value (no way to tell its actually blinking with bare eyes).