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.

[Sensorion]

After recreating the failure repeatedly and dumping the code and UICR from various stages of programming that lead to the failure and to a successful unit I can state the following:

• The program space/code is being updated correctly, and to the correct spot in memory space
• The UICR is different in one field when I compare the failed unit to the passed unit.
• in the pass cases the entry is : 101200001500000015000000FFFFFFFFFFFFFFFFBC
• in the failed cases the entry is:101200001500000015000000FFFFFFFFFEFFFFFFBD

This entry is added to the UICR after the V3.0 app is written to the device So now I need to figure out which UICR it is and what it controls