0

SDK11 serial DFU to s132v4 from s132v2

Bert gravatar image

asked 2017-07-07 21:35:04 +0200

updated 2017-07-10 16:07:32 +0200

Recently I have been working with the serial bootloader from SDK 11. I can upload a softdevice, and supporting application using this bootloader without issue, as long as it’s the same softdevice version. In the case of SDK 11, that would be s132v2.

Now for the problem:

I have a separate application built against SDK 13, using s132v4. It blinks an LED and exposes a BLE service, nothing fancy. My thought process was that I would use this application as input to the bootloader described above, updating the softdevice from s132v2 to s132v4, and loading my test blinky application.

This however does not work. It happily accepts the new softdevice, resets the device, but fails on softdevice_enable, specifically: NRF_ERR_NO_MEM, regardless of linker adjustments in .icf. There’s plenty of posts which describe how to solve this issue, but in my case app_ram_base matches and returns with:

sd_ble_enable() returned unexpected value: 0x04

After a bit of searching I found this, which describes a fix in dual_bank.c, but it didn’t seem to have an impact, and I think its downstream of my immediate issue.

Below is my linker file and a snippet from dfu_types.h. I also verified UICR as a test.

define symbol __ICFEDIT_intvec_start__ = 0x70000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__   = 0x70000;
define symbol __ICFEDIT_region_ROM_end__     = 0x7dfff;
define symbol __ICFEDIT_region_RAM_start__   = 0x20002c00;
define symbol __ICFEDIT_region_RAM_end__     = 0x2000ff7f;
export symbol __ICFEDIT_region_RAM_start__;
export symbol __ICFEDIT_region_RAM_end__;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__   = 0x800;
define symbol __ICFEDIT_size_heap__     = 0x200;
/**** End of ICF editor section. ###ICF###*/

dfu_types.h:

#elif NRF52     

#define BOOTLOADER_REGION_START             0x00070000                  /**< This field should correspond to start address of the bootloader, found in UICR.RESERVED, 0x10001014, register. This value is used for sanity check, so the bootloader will fail immediately if this value differs from runtime value. The value is used to determine max application size for updating. */
#define BOOTLOADER_SETTINGS_ADDRESS         0x0007F000                  /**< The field specifies the page location of the bootloader settings address. */
#define BOOTLOADER_MBR_PARAMS_PAGE_ADDRESS  0x0007E000                  /**< The field specifies the page location of the mbr params page address. */

#define CODE_PAGE_SIZE                      0x1000                      /**< Size of a flash codepage. Used for size of the reserved flash space in the bootloader region. Will be runtime checked against NRF_UICR->CODEPAGESIZE to ensure the region is correct. */

#else

Verify UICR:

$ nrfjprog --memrd 0x10001014 --n 4
0x10001014: 00070000

In the end, my goal is to use the existing bootloader from SDK 11, and upload an application which is built against SDK 13, s132v4.

The use case above can be reproduced by running the dfu example from SDK 11 and using nRFGoStudio's bootloader utility to generate a zip of s132v4 from SDK 13. I am 99 percent sure the issue is something I am doing wrong on my end, but can't seem to get around it. Any direction would be greatly appreciated.

Steps:

1.) Flash s132v2 from nRFGoStudio
2.) Run dfu example and put into DFU mode
3.) Go into nRFGoStudio's bootloader util and flash s132v4 softdevice only as zip
4.) Results in NRF_ERR_NO_MEM. Tried with multiple linker configurations. As well as enabling/disabling softdevice protection in nRFGoStudio for the initial softdevice.

As a side note, I should also mention that I would like to stick with the basic bootloader from SDK11, not the secure bootloader from SDK13.

Update:

A few more details. This happens while updating from S132 v2.x.x to S132 v4.x.x. I have provided screenshots below:

Prior to running the bootloader example:

image description

Initial bootloader in DFU mode waiting for update:

image description

After update, nRFGoStudio reports back "Device Programmed", program then resets and fails with NRF_ERR_NO_MEM:

image description

edit retag flag offensive close delete report spam

Comments

When you say that softdevice_enable() returns error code 0x04, is this in the bootloader or the application?

Bjørn Spockeli ( 2017-07-10 13:14:50 +0200 )editconvert to answer

Hi @Bjørn Spockeli, this is in the bootloader, specifically via ble_stack_init within the dfu_dual_bank_serial_s132 example. The error happens at step 3. The bootloader starts and enters DFU mode, at this point I switch over to nRFGoStudio and upload s132v4 with its utility, the bootloader then gives NRF_ERR_NO_MEM.

Bert ( 2017-07-10 14:12:48 +0200 )editconvert to answer

So this is after you have updated from from S132 v2.x.x to S132 v4.x.x? Also is the bootloader present on the device after the update built against SDK v11.0.0 and the S132 v2.x.x ?

Bjørn Spockeli ( 2017-07-10 15:22:43 +0200 )editconvert to answer

Hi @Bjørn, I have update the original with the details you requested. One thing I noticed right away was that the application address is different in the two screenshots, I guess that makes sense though as the s132v4(124kB) > s132v2(112kB).

Bert ( 2017-07-10 16:02:17 +0200 )editconvert to answer
1

Yes, that is because the S132 v4.x.x SoftDevice is larger than the S132 v2.x.x, which means that application start address must be shifted upwards. However, you did not answer my question: Is the bootloader present on the device after the update of the SD and Application still based on SDK v11.0.0 and S132 v2.0.0? If that is the case then you have a bootloader that is incompatible with the S132 v4.0.0 SoftDevice and that is why your're getting an error. You will have to compile the SDK v11.0.0 bootloader against the S132 v4.0.0 headers and update the bootloader, application and SoftDevice.

Bjørn Spockeli ( 2017-07-10 16:18:08 +0200 )editconvert to answer

I'm sorry @Bjørn but I don't fully understand the question. I'll try to answer the best I can. I am trying to update to an application built against SDK 13 that requires s132v4. The SDK11 s132v2(0x81) bootloader is present on the device, and does get updated according to the FWID(0x98). After reading your comment though, I think I see what your're saying. Due to the fact that my application requires s132v4, the SDK11 s132v2 bootloader must be updated to s132v4, and compiled with the s132v4 headers?

Bert ( 2017-07-10 17:04:33 +0200 )editconvert to answer
1

Yes, that is correct. The bootloader is using the SD API and it must therefore be compatible with the SoftDevice present on the device.

Bjørn Spockeli ( 2017-07-10 17:22:10 +0200 )editconvert to answer

1 answer

Sort by » oldest newest most voted
1
Bert gravatar image

answered 2017-07-17 15:52:17 +0200

To summarize, thanks to @Bjørn Spockeli, I learned that using the DFU implementation in SDK11 s132v2 while attempting to upgrade the softdevice to s132v4 would require the softdevice headers to be swapped out. This change is required because the bootloader itself leverages the softdevice API. Thus, swapping a new softdevice, without the headers, would not work in most cases.

This however poses major issues as the jump from 11 to 13 changes certain constructs in terms of the softdevice and SDK. For example SDK11 s132v2 uses pstorage for the bootloader, while SDK 13 has moved entirely to fstorage, not to mention the addition of sdk_config. There's a few ways to solve that problem, and I was able settle on one in order to to get a rough version up and running. With that said, it felt like a force fit. I opted to move to the new secure serial DFU in SDK 13 and all is well.

edit flag offensive delete publish link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

User menu

    or sign up

Recent questions

Question Tools

1 follower

Stats

Asked: 2017-07-07 21:35:04 +0200

Seen: 76 times

Last updated: Jul 17