This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

bootloader stuck in wait_for_events if started programatically

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

  • Hi Varga,

    Could you record a sniffer trace when the issue occurs ? I want to see what happens over the air when the bootloader stopped response.

  • Hi,

    Sorry, but I cannot do a sniffer trace as I have only one development dongle (PCA10000) and I could not upload firmware OTA nor with an IPhone (IPhone 5 w/ IOS8) neither with an Android phone (Samsung Galaxy S3 w/ Android 4.3) even when uploading with Master Control Panel and dev dongle was possible.

    I have attached the Master Control Panel log instead, maybe it helps. Log file

    The log file contains a service discovery when the nordic_hrm example has already been uploaded OTA to the device. After this I have pressed the DFU button, and I tried to upload a hex file. The DFU procedure failed. After the failed DFU procedure I have pressed the Service Discovery button again. During this service discovery the bootloader has hung as seen in the logs.

    I try to reproduce the issue with the Android Master Control Panel and do sniffing too.

    Tamas

  • Hi,

    Now I have made a separate test:

    1st step: uploaded SD and bootloader to device.

    2nd step: uploaded app firmware w/ MCP (PC - v3.7.1.8567) and dev dongle to device.

    3rd step: initiated DFU w/ MCP (PC) and dev dongle (failed).

    4th step: updated dev dongle to act as sniffer, started sniffer app on PC

    5th step: pressed connect button on MCP (Android smart phone v 2.1.0) - nothing happened.

    6th step: pressend connect button on MCP (Android smart phone) - application crashed.

    7th step: stopped Wireshark, capture saved.

    Link to capture file is here.

    Thanks for your help,

    Tamas

  • Hey,

    i have a similar problem with the S310 bootloader.

    1. I can flash softdevice S310 V2.0.1 and Bootloader from SDK 7.2.0 --> Start in Bootloader mode
    2. Flash a custom applciation with DFU support --> Application starts --> ok
    3. Writing 0x01 to the DFU control characteristic --> Bootloader starts --> ok
    4. Connect with MCP and starts Discovery Services --> Bootloader hangs up! --> Failure

    I don't know the problem. If i use sd_nvic_SystemReset() instead of jump to the Bootloader address all works as it should. The only difference I can see here is:

    • With sd_nvic_SystemReset() i always initialize sd_mbr_command(&com);
    • Jump to the Bootloader address --> sd_mbr_command(&com); is not executed before enable the softdevice

    Do you already have new knowledge?

  • Hi Varga, Earlier you mentioned that the DFU worked fine if you do a reset (start DFU by holding a button when reset ?), but above I read that "After this I have pressed the DFU button, and I tried to upload a hex file. The DFU procedure failed." Which button is that ? Could you give more information ?

    I suspect that there could be something has not been completely turned off after you jump from your application to the bootloader. From your sniffer trace, I can see that the phone has discovered the DFU service and characteristics but nothing happened after that, have you clicked DFU button ?

    Could you send me your source code (include the compiled hex file) of the bootloader and the application you use. So that I can test on the PCA10000 here ?

Related