SDK14.2 DFU power cycle issue

RE: SDK14.2 DFU power cycle issue

Hung Bui — Tue, 30 Jan 2018 09:59:06 GMT

Hi Sensorion,

I'm sorry that I didn't think of the issue. It's a known issue that when the size of fds changed, there is a chance that the swap page is not recognized and throw FDS_ERR_NO_PAGES when you call fds_init().

Currently there isn't a function to format fds pages for the first use. You may need to erase the pages manually using fstorage. We also think of adding an option in the DFU bootloader to erase customer data when doing DFU but it's not implemented.

For now we suggest to keep the number of pages the same between different firmware version, or only increase not decrease number of pages, should also work.

RE: SDK14.2 DFU power cycle issue

Sensorion — Mon, 29 Jan 2018 15:15:37 GMT

The error was an application level error not a boot loader error. The boot loaders for both the SD v3.0.0 and SD v5.0.0 work correctly as does the package used to update a target chip from v3 to v5. The error was in the interaction between the FDS initialization in the v3 app and then the v5 app.

The application I was using for SD v3(App3) declared 8 virtual pages of FDS memory space. The new version based on SD v5(App5) only had 4 pages declared. When App3 was flashed to the chip it initialized 8 virtual pages, 7 data and 1 swap. These pages are not erased during the subsequent DFU processes. When App5 is installed and run it tries to initialize the FDS system and finds 4 initialized data pages but no swap page. This creates a no memory error, which causes a system reset.

The solution was to set the number of virtual pages in App5 to 8.

I have not experimented with this but perhaps it is possible that changing the number of virtual pages in this manner could result in the same error even without going through the update process. Also the system should have some means of dealing with the situation where it finds several data pages and no swap page.

RE: SDK14.2 DFU power cycle issue

Sensorion — Mon, 29 Jan 2018 15:05:00 GMT

The last byte of the sequence is not in the register space and I beleive that this is some form of checksum maybe, generated when the data is read from the target nRF chip. The line I quoted there breaks down to 4 UICR registers:

00000015
00000015
FFFFFFFF
FFFFFFFE

RE: SDK14.2 DFU power cycle issue

Hung Bui — Mon, 29 Jan 2018 09:57:28 GMT

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 ?

RE: SDK14.2 DFU power cycle issue

Hung Bui — Mon, 29 Jan 2018 09:50:31 GMT

There are 2 bits different in the 2 cases, have you found what the second bit is about ?

RE: SDK14.2 DFU power cycle issue

Sensorion — Sun, 28 Jan 2018 21:38:31 GMT

The UICR bit that is different is an indicator that the NFC pins are to be used as GPIO. Not the source of my on going issue.

RE: SDK14.2 DFU power cycle issue

Sensorion — Sun, 28 Jan 2018 19:26:51 GMT

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

RE: SDK14.2 DFU power cycle issue

Sensorion — Fri, 26 Jan 2018 17:45:33 GMT

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.

RE: SDK14.2 DFU power cycle issue

Hung Bui — Tue, 23 Jan 2018 16:25:49 GMT

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.

RE: SDK14.2 DFU power cycle issue

Sensorion — Tue, 23 Jan 2018 02:33:15 GMT

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.

RE: SDK14.2 DFU power cycle issue

Hung Bui — Mon, 22 Jan 2018 15:23:46 GMT

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.