nRF52840 OTA update with a GSM modem (UART)

[HRomain]

Hello,

We are looking to do OTA device firmware update by GSM for the nRF52840.

We have a custom board with a nRF52840 and a GSM/LTE-M modem. They are communicating together by an UART.

The new firmware is downloaded and stocked by the GSM modem.

We did some research and it appeared that is not possible to use DFU with uart transport exemple in our case. DFU target (nRF52840) need a DFU controller and the gsm modem has no application/logic.

After some read on the DevZone we understood that we must implement a custom bootloader.

We relied on this example: OTA Firmware Updates with nRF52840 and SIM7600E LTE Module – ravikiranb.com

If we understand correctly, steps are:

1. Receive the new firmware by uart
2. Stock it on flash with nrf_nvmc lib
3. Start the bootloader

Questions are:

1. On which address we have to write the new firmware ?
   according to this document Nordic Semiconductor Infocenter, the new app has to be written to the “bank 1” (we use dual-bank configuration).
   
2. How to start the check of the new application and do the switch between bank 1 and bank 0 ?
   we just have to start the bootloader (nrf_bootloader_init) ?
   “The original application is located in memory bank 0. The transferred image is stored in bank 1. After the new application image is received, both the old and the new application are present. This ensures that fallback to the old application is possible if the new application cannot be activated. If the new application can be activated, it is copied from bank 1 to bank 0. Existing application data can be retained; see Preserving application data for more information.”

 

Thanks for your help.

[Edvin]

Hello,

The bootloader in the SDK is a passive bootloader, meaning that by default the behavior is that it enters DFU mode, and then the DFU master will send the image to the nRF. I guess your GSM module isn't capable of that, and that the nRF needs to manually pull the firmware from the GSM module, right?

So as I see it you have two options:

Either modify the bootloader to request the application image from the GSM module, or have the application pull the application image, and then start the bootloader to verify and move the application to the correct bank.

1. It doesn't really matter what address you use, as long as the bootloader is aware of the start address for the new application.

2. Please see the answer I wrote in this ticket yesterday. It is pretty much the case that you are facing as well.

Best regards,

Edvin

[HRomain]

Hi, thanks for your answers.

You're right, it will probably be easier to pull and write the new firmware from the app.
for that we need to write .bin and .dat files to the bank1 and then call the bootloader right ?

I'm a little confused on the bootloader, about how to implement it.

should we start with the example "dfu\secure_bootloader\pca10056_uart" and skip the transport phase or is it better to use the "background DFU" from "components\iot\background_dfu" ?
We use SDK16

Best regards

[Edvin]

HRomain said:

should we start with the example "dfu\secure_bootloader\pca10056_uart" and skip the transport phase or is it better to use the "background DFU" from "components\iot\background_dfu" ?

 I have not done this myself, but I believe that is the way to go. Look at what functions are called on the object execute command, which I tried to point to in the other ticket that I linked to.

And yes, you would need the .bin and .dat file generated by nrfutil, as if you were using the unmodified secure_bootloader.

Actually, you may not need to store the init packet in flash, as this is just used to check whether the application is signed (before it decides whether to receive the rest of the application image). You can check this in your application if you like, but you can probably only use the .bin file.

I suggest that you try to perform a DFU operation from the unmodified bootloader, and look at what is located in the flash before the object is executed.

Best regards,

Edvin