Update NRF52 Firmware (DFU) via External MCU STM32

[Mayur Patel]

Hi all,

I am new to NRF world & I have gone through Nordic's Tutorials about

• Getting Started
• custom Services / Characteristics
• Bootloader, Softdevices
• DFU via OTA / UART (PC)
• creating/signing DFU packet etc..

So now in my case, main (Host) CPU is the STM32 and main Programme runs on this. nRF52832 is on the same PCB as BT connectivity provider. 
I want to update the firmware of the nRF not via Standard ways like OTA but via STM32. (reason: due to complete system update in one go).

So my Que.:

1. nRF side: How this can be done on the  (while prev. firmare + softdevice is already running) via UART / SPI Bootloader?
   (Info: I know that to go again to Bootloader mode we need to impl. Buttonless DFU via PINRESET or GPREGRET register set)
   
2. Which is the best interface to connect both ? SPI or UART?
   
   
3. STM32 side: What type of implementation / Bootloader is required (with STM32 Host App Binary) so that DFU packet can be catched abd then can be send to nRF?

complete step by step explaination to acheive this will be a really helpfull for me.
(Info: I have already seen the posts of updating the STM32 via nRF but in my case its reverse.)

Dev-Setup:

• nRF52832 Evalboard (PCA10040)
• Nordic Tools (pc-nrfconnect, nrfutils, nrfconnect-App, etc...)
• STM32F10xxx

[Edvin]

Hello,

We don't have any SPI bootloaders for the nRF52832 in the examples in the SDK, but I know that several customers have ported the UART bootloader (found in SDK\examples\dfu\secure_bootloader\pca10040_uart) to use SPI instead of UART. It shouldn't be too much work.

As for the master side, we don't have anything STM specific, but we have some experimental projects using both UART and SPI written for an nRF, so perhaps it is possible to port that to an STM without too much work.

One of the examples are found close to the bottom of the Getting started with DFU guide, which is the one I believe you referred to, found here. Search for "DFU Master Code".

Another project that does more or less the same is from one of our FAEs' github: nrf-slim-serial-uart-dfu-host-c-code.

To answer your questions:

1: While the software is running, you need to tell the application to enter DFU mode, somehow. We have several means of doing so. One way can be to reset the device. If you have connected the RESET pin to the application processor (the STM) and then pull another pin low (or high) that the bootloader will check before entering the already programmed application again. Search for NRF_BL_DFU_ENTER_METHOD_BUTTON in the bootloader example project, and see how it is used. Another way to trigger DFU mode is to set some power register before the reset. Check the function dfu_enter_check() in the bootloader example project:

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

Then it is possible to write this register from the application, and then reset the device to trigger DFU mode. Let me know if this is what you want to do, but struggle with this. The trick is to wait until the register is written before you reset. So write to it, then read it back until the correct value is read back, and then reset.

What method you decide to use depends on the HW setup. Either way you need some way to communicate from the STM to the nRF application that it should enter DFU mode, and the then may have to do some preparations (e.g. write to the power register) and reset the device.

2: Both SPI and UART can be used. As mentioned, we don't have an out of the box SPI bootloader, but it is possible to port the UART Bootloader to support SPI instead of UART. After that, it is only your preferred communication that decides this.

Please note that the flash operations takes some time, when you update the device. So it is probably not the UART throughput that will cap the DFU speed.

3: Please see the DFU getting started, and Jimmy's nrf-slim-serial-uart-dfu-host-c-code repo that I linked above. They are not written for an STM, but it can be a starting point. In case you need it, you can also check the bootloader's serial transport documentation on infocenter.

Best regards,

Edvin

[Mayur Patel]

Hi Edvin,

Thank you for your reply.

I went through your links and cleared my doubts. It helped me to enter Bootloader mode from App mode without doing button press. Now the open Que. are,

1. Do I need an external memory to store the Firmware to update NRF52 via STM32? Or can STM32 can tunnel the data directly via UART that it receives via CAN?

2. Is this DFU via UART possible at all if the nRF52xx SoC is empty(from production) and does not contain any type of Softdevice or Bootloader? 

[Edvin]

Mayur Patel said:

1. Do I need an external memory to store the Firmware to update NRF52 via STM32? Or can STM32 can tunnel the data directly via UART that it receives via CAN?

 You can do the option that suits best in your case. When the nRF is in DFU mode, it will be in a passive waiting state, waiting for the next packet or command, and handle that packet. The only thing you need to consider is some sort of timeout. If the nRF has a valid application (but you set the device in DFU mode via button press), it will start a timer during intialization. Look at nrf_bootloader_init() -> nrf_bootloader_dfu_inactivity_timer_restart(initial_timeout, inactivity_timeout);

inactivity_timeout is a callback function, so when this function is called once, it will reach that handler if initial_timeout ticks passes without this being called again. It will be called on every "object received" event, which resets the timer, and the default timeout is 120 seconds, so probably not something you need to worry about as long as you keep sending the packets. 

 

Mayur Patel said:

2. Is this DFU via UART possible at all if the nRF52xx SoC is empty(from production) and does not contain any type of Softdevice or Bootloader? 

 It requires at least a bootloader and either a SoftDevice or the MBR pre-programmed in order to work. (MBR is part of the softdevice, so if you don't use the softdevice, you need to program the standalone MBR). 

The "normal way" to do this, is to program the bootloader, Softdevice/MBR, application and bootloader_settings during production, so that you have the first set of application and bootloader already present.

The bootloader settings is something you can generate externally using "nrfutil settings generate --help". What this does is that it signs the application, and generates a hex file containing this signature in the flash area that the bootloader uses to verify the signature. 

But yes, you need the bootloader pre-programmed in order to perform a serial DFU.

Best regards,

Edvin