SDK14.2 DFU power cycle issue

[Sensorion]

Situation: Trying to upgrade previous versions of the SD and BL (V3.0.0) to (V5.0.0) Problem: device power cycles after a new application is flashed to the device into the V5.0.0 SD and BL.

Steps:

1. Take target device, including dev board, and program SD3.0.0 and V3.0 buttonless bootloader
2. DFU an App appropriate for SDV3.0.0 and run it.
3. DFU the new SD and BL (V5.0.0) package to the device
4. DFU an App appropriate for SDV5.0.0 and run it

Result of performing all 4 steps is that the device keeps power cycling. If you skip step 2, the procedure works and the device functions as desired.

I am guessing that there is some internal register that is written to during the DFU process in step 2, and that this register is not being updated to accommodate the position changes due to the larger SD.

Is there a work around?

[Hung Bui]

Hi Sensorion,

When you flash the bootloader that works on Softdevice v3.0 which SDK the bootloader belong to ?

There is a bug with the bootloader in SDK v13.x, and v14.0 that updating to softdevice will not be successful. The issue is fixed in SDK v14.1 and above. Please have a look here.

[Sensorion]

In my case the update of the SD + BL is successful. Also the DFU process of loading an app into the system after the SD + BL update is also successful but the unit then gets into some type of power cycle loop. I added a triple blink LED pattern to the start of my boot loader as an indicator, and this is the only pattern to occur.

My thought is that the issue is in that something must be messed up when the boot loader tries to load the app.

[Hung Bui]

Please try debug step into the new bootloader code and see why the new application is not executed. Another thing you can do is to read the flash out into a hex (nrfjprog --readcode) and then use compare tool (notepad++ for example) to check if the correct image is stored in the correct place or not.

You haven't revealed which SDKs you used.

[Sensorion]

I have managed to debug the boot loader while it is in this failed state. It is failing during a call nrf_bootloader_app_start(MAIN_APPLICATION_START_ADDR)in the nrf_dfu.c file. The system tries to call the function each power cycle. There are two spots in code where the call can be made from, bottom of main (line 128) and at the end of nrf_dfu.c (line 232). My thought is that the call is made from the nrf_dfu.c file after the successful download of a new application, and that the call from the file main is made if the system is turned on and there is no active DFU process and a valid app is found. I my debugging the only place this function is called from is from the nrf_dfu file. So maybe the system thinks it is still in a DFU downloading state? I used 12.2 for the first loader and 14.2 for the next. The fix you referred to before is active in the 14.2 loader.

[Hung Bui]

Your understanding is correct. But " So maybe the system thinks it is still in a DFU downloading state? " is not correct, if it's still DFU download state, it shouldn't call nrf_bootloader_app_start().

So you dumped the flash out and can find that the application is at correct location ? And there is no different when you diff the flash if you flash SD+APP+BL (SDv5) except for the swap bank?

Have you tried testing with our SDK examples as the application, instead of yours ?