SDK11 serial DFU to s132v4 from s132v2

RE: SDK11 serial DFU to s132v4 from s132v2

Bert — Mon, 17 Jul 2017 13:52:17 GMT

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.

RE: SDK11 serial DFU to s132v4 from s132v2

bjorn-spockeli — Mon, 10 Jul 2017 15:22:10 GMT

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

RE: SDK11 serial DFU to s132v4 from s132v2

Bert — Mon, 10 Jul 2017 15:04:33 GMT

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?

RE: SDK11 serial DFU to s132v4 from s132v2

bjorn-spockeli — Mon, 10 Jul 2017 14:18:08 GMT

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.

RE: SDK11 serial DFU to s132v4 from s132v2

Bert — Mon, 10 Jul 2017 14:02:17 GMT

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).

RE: SDK11 serial DFU to s132v4 from s132v2

bjorn-spockeli — Mon, 10 Jul 2017 13:22:43 GMT

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 ?

RE: SDK11 serial DFU to s132v4 from s132v2

Bert — Mon, 10 Jul 2017 12:12:48 GMT

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.

RE: SDK11 serial DFU to s132v4 from s132v2

bjorn-spockeli — Mon, 10 Jul 2017 11:14:50 GMT

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