Application firmware shifted wrt the end of the softdevice space

[ste2108]

Hello,

In my application I use BT DFU to update a Nordic 52840. The new fw is flashed starting from 0x26000 (i.e. the end of the softdevice) and after the update the application starts correctly.

I would like now to leave a space between the end of the softdevice and the start of the application fw, where I can copy some custom data. Let's say I want to start the application fw from 0x27000. I can correctly manipulate the hex files to obtain this, and I can verify that after the DFU the application fw starts from 0x27000 by reading the MCU content with a j-link. However the application won't start cause the bootloader (which is the official Nordic DFU bootloader) has not been informed that it should not point at the end of the softdevice space when starting the application, but it should rather add 0x1000 to that value.

Looking on the internet, I found that until sdk 14.2 the application address was explicitly passed to the nrf_bootloader_app_start, but in later sdk's (I am using sdk 16.0.0, which cannot be upgraded) a nrf_bootloader_app_start call points to the softdevice, which in turn takes care of starting the application by addressing the space immediately after the softdevice space:  NRF52 S132 and application with custom address 

My question is: how can I execute an application shifted by n*0x1000 (with n strictly greater than 0 :) ) with respect to the end of the softdevice in sdk's > 14.2, thus leaving some space for custom data? These data cannot be at the end of the application fw, cause I want to access them from the fw itself (and so with a future larger fw their address would be different) while at the same time keeping the application fw size as small as possible (so I don't want to put them, say, at the end of the flash space).

Thank you.

Regards,

Stefano

[Einar Thorsrud]

Hi Stefano,

The way I understand it this means that each application you DFU in also needs to contain a big chuck of data which is the ST firmware? And as this is part of the application update it does not really have to be in the same location every time, as thy are in sync? It is no problem keeping it in the same location though, by doing as I suggested in my previous post. Moreover, that means that it does not matter if it is "in the middle" of your application, does it? And the size can change over time, as it only changes whenever the application changes?

If my understanding is correct, it seems to me that you just need a static array that could be placed anywhere, and that contains the binary representation of your ST firmware. I would go with that approach then, as it is flexible (you can always move things around and change sized for every update a then both the nRF application and the firmware for the other device (that is just a big chunk of data) are always updated together. Which practical approach you would use here depends on which workflow etc you need/prefer, but one could even think of taking the firmware, using a form of bin2c tool to generate an array, and just include that when you build your nRF firmware. They you would have the firmware as a binary, and it could be located wherever the linker places it without that mattering. But this is details that just needs to be adjusted to what works for you.

Einar

[ste2108]

Dear Einar,

Sorry for the late answer. In the end the solution that worked for us was to put the sizes we need at exactly half the size available for the update. This results in a small increase in the fw size to be uploaded from app to Nordic (and hence of the transfer time, cause the firmware now occupies like 80% of the half size and putting the sizes at half the available size fills the gap with 0xffff) but a huge reduction in the Nordic-to-ST transfer time (cause the application now knows exactly which size to transfer). Thank you for your support!
Regards,

Stefano