How to upgrade 52833 firmware with UART interface ？

[can23]

My project consists of STM32 + 4G + nrf52833. When the 52833 firmware needs to be updated, the cloud service will
send the 52833 firmware to STM32, and then STM32 will send the firmware to 52833 through the UART interface. Now
there are some questions:

1. How to enter DFU mode

If there is a new firmware, STM32 sends a command to nrf52833 through UART interface. How does nrf52833 enter DFU，what API or setting?

2. How to send firmware to 52833

After nrf52833 enters DFU mode, how does STM32 send firmware to 52833 and package new firmware?

3. Are there any demo codes？

sdk:nRF5_SDK_17.0.2_d674dde

The following is the structure diagram of the product：

[Amanda Hsieh]

Hi, 

1. See DFU mode doc that Entering DFU mode is triggered by one of the optional sources:

• Button (NRF_BL_DFU_ENTER_METHOD_BUTTON),
• Pin reset (NRF_BL_DFU_ENTER_METHOD_PINRESET),
• Special value in GPREGRET register (NRF_BL_DFU_ENTER_METHOD_GPREGRET),
• Request from the application written to the settings page (NRF_BL_DFU_ENTER_METHOD_BUTTONLESS).

You can enable NRF_BL_DFU_ENTER_METHOD_GPREGRET in the sdk_config.h, and write the special value in the retention register GPREGRET register a flag (BOOTLOADER_DFU_START = 0xB1)  in the application and then do a soft reset (NVIC_SystemReset) to switch. 

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

3. There is no demo exactly as your requirement, but please see the above links I provide. 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.

Regards,
Amanda

[can23]

thanks for your reply！

[can23]

I decided to write a simple bootloader code myself. At the same time, I divided the application flash into two banks. One bank is app code and the other is new firmware (bin file received by stm32f4). In the bootloader code, if there is new firmware, write the new firmware to the app code bank, and then jump to the app code bank. Now there are several problems to be confirmed:
1. How to set the address of [main stack pointer]
In stm32f4, I can configure the [main stack pointer] address through this statement:

__ asm void MSR_ MSP(u32 addr)
{
   MSR MSP, r0 // set Main Stack value
   BX r14
}

52833 can also use this statement to set?
2. Check whether the stack top address is legal
When jumping from bootloader to app, first check the stack top address. After the stack top address is legal, set the [main stack pointer] address, and finally jump to app. Like stm32f4:

void iap_ load_ app(u32 appxaddr)
{
    if(((*(vu32*)appxaddr)&0x2FFE0000)==0x20000000) // Check whether the stack top address is legal
    {
        jump2app=(iapfun)*(vu32*)(appxaddr+4);  //
        MSR_MSP(*(vu32*)appxaddr);              // Initialize app stack pointer
        jump2app();                             // Jump to app
    }
}

52833 how to check that the stack top address is legal?
3. Interrupt vector of app
In the app program, how to remap the interrupt vector address? for example in stm32f4:

int main(void)
{
    SCB - > vtor = flash_base | 0x10000; / / 0x10000 is the start offset address of APP program
    while(1)
    {
    }
}

So is 52833?

[Amanda Hsieh]

Hi, 

1. Yes. Not sure why the branch instruction (BX) is needed though. You can also use the cmsis function __set_MSP() for the same.
2. Looks ok.
3. You can't use the VTOR register if the application uses the Softdevice. Then the interrupt forwarding goes like this: MBR->Softdevice->app. You should look at how we do it in the bootloader (i.e. what MBR API we use to enable interrupt forwarding to the Softdevice). It will effectively bypass the Softdevice if using the VTOR register, but you only can use the VTOR register if the app doesn't rely on the Softdevice. 

-Amanda

[can23]

hi，

For point 3, my application uses softdevice. Can you give me a demo code?

thanks!