DFU over cellular internet

RE: DFU over cellular internet

Edvin — Wed, 12 Aug 2020 09:32:35 GMT

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:

[quote user="TimA"]And to be clear, when we say "image", we mean the DFU package created using nrfutil, yes?[/quote]

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

RE: DFU over cellular internet

Tim Adu — Tue, 11 Aug 2020 12:41:47 GMT

Fair enough. I'm having trouble deciding where to start (there's quite a number of ways to go around this).

Here's what I've gathered so far:

I will be transferring the image from the modem to the nrf52840 mcu via UART (within the application context). Would it then make sense to look at the UART version of the secure bootloader to get inspiration on how the image transfer is made via UART?
In my application project, I need to include the DFU library, and initialize my chosen transport mechanism (UART). Would this potentially create a conflict since the UART instance is already being used by the modem? - If this is a problem, I'm thinking one way around it is to move the whole DFU process to the bootloader (the application gets a notification that an update is available, restarts in DFU mode, and the bootloader initializes the transport + modem, transfer the image, validate and activate).
I'm a little fuzzy about the concept of putting an image in bank 1. How does one go about that from an application context? Any examples that show this? And to be clear, when we say "image", we mean the DFU package created using nrfutil, yes?

RE: DFU over cellular internet

Edvin — Tue, 11 Aug 2020 08:17:21 GMT

It is experimental, and the IoT section was deprecated in the latest SDK (SDK17.0.0). It may work, but I am not familiar with it.

RE: DFU over cellular internet

Tim Adu — Mon, 10 Aug 2020 18:30:57 GMT

I recently bumped into "Bootloader for background DFU" in the experimental IoT libraries section. Could this also be used, and since it's experimental, how reliable is it?

RE: DFU over cellular internet

Edvin — Mon, 06 Jul 2020 15:28:25 GMT

1. It is possible, but it requires that you have space for the current application and the new application at the same time in your flash. If you intend to do a softdevice update as well, which typically requires a new bootloader update, you need to fit 2xBL + 2xSD + 2xAPP in flash.

2. Yes, but it requires you to do some changes to the bootloader. You need to find what function is called when the transfer of the image in the bootloader is normally done, and call that directly when you enter bootloader mode (if there is a new image present). Essentially you will skip the transfer part in the bootloader, because it is already done from the application.

3. not necessarily. You transfer the image in the chunk size that you want to. You need to use your UART handler to stored the received chunks in the flash. It doesn't really matter what UART buffer size you use. You can transfer 8 bytes at the time if you want to, or you can transfer 512 bytes at the time.

BR,

Edvin

RE: DFU over cellular internet

Edvin — Mon, 06 Jul 2020 15:18:43 GMT

NB: We are really short staffed due to Summer Holidays in Norway. You must expect some extra delay in technical questions these days, I am afraid. I am sorry for the inconvenience.

I will get back to you as soon as I can, hopefully tomorrow.