DFU over cellular internet

[Tim Adu]

Hi,

This is actually a followup ticket based on this: https://devzone.nordicsemi.com/f/nordic-q-a/56228/fota-dfu-over-internet.

Now the situation is a bit more concrete (or at least how I imagine the situation):

1. I am using a cellular modem. This will be used to download a dfu package from a third party endpoint using AT commands.
2. The dfu package will be copied to mcu (nrf52840) via UART, also using AT commands
3. The mcu is rebooted and enters DFU mode (using the power management API). The bootloader activates the DFU image

Questions

1. Is the above scenario even possible? What am I missing?
2. Would the secure BLE bootloader be able to activate an image downloaded in this manner?
3. Given the potential size of the dfu image - should the UART buffer be a large as possible?

Thanks 

Tim

[Edvin]

Hello,

I assume that your 3rd party AT command device is a passive device, meaning you will not be able to push UART packets from that one to the nRF, but that the nRF has to request it via AT commands, correct?

If so, as I see it you have two options:

1: Download the application in the background, just like it is done in the bootloader. Then enter the bootloader, and skip the whole transportation part, and move straight to the execution of the image.

2: Modify the bootloader to ask for packets via AT commands instead of waiting for them to come by themselves.

Whatever way you want to go, I suggest that you study the  secure bootloader (uart) example. Preferably by using the pca10056_uart_debug example, enable logging, and see whats going on in a normal use case when you just use nrfutil. Look at what functions that are being called to store the data from the UART, and what functions that are used to execute the image when either the init packet or the application image is done. Also study the message flow chart.. 

If you choose to transfer the data in the background of your application using alternative 1, I believe you would want to call nrf_dfu_validation_init_cmd_execute() (as used in nrf_dfu_req_handler,c) more or less immediately.

Remember that you need to tell the bootloader when this is supposed to happen and not from the application. Please check how you can use the GPREGRET register from dfu_enter_check() in nrf_bootloader.c ->

    if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
       (nrf_power_gpregret_get() & BOOTLOADER_DFU_START))
    {
        NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
        return true;
    }

Q1: Yes. It would make sense to look at the UART version of the secure bootloader. 

Q2: Are you using the same physical UART (I believe so). If so, you just need to filter out what UART messages that are intended for DFU and which ones that are not, then save only the application images to flash.

Q3: 

 

Tim Adu said:

And to be clear, when we say "image", we mean the DFU package created using nrfutil, yes?

 Yes.

Do you know the concept of dual bank vs single bank?

Basically, you need some way of knowing where (what address) you want to put your new application. And the bootloader needs to be aware of this as well. The nrf_dfu_validation_init_cmd_execute() only takes a start_address and a firmware_size. If your bootloader uses dual bank, this means that it will set the start address = the start address of the second bank, but in your case, you just need to call it with the start address and size of your application image.

BR,

Edvin