Example of a bootloader that could boot 2 different app codes?

RE: Example of a bootloader that could boot 2 different app codes?

bjorn-spockeli — Wed, 29 Jan 2020 14:16:15 GMT

You can either do a Dual or Single Bank update, see Dual-bank and single-bank updates in the bootloader documenation.

RE: Example of a bootloader that could boot 2 different app codes?

samsam — Wed, 29 Jan 2020 02:44:45 GMT

Ok, Thanks - I followed your advice and made HID keyboard with FreeRTOS, don't see any other problems other than those that and the original example has, so far working good enough :) Can you recommend some manual or reference where can see what free space will need in the nRF52832 flash in order to DFU only App, or everything with bootlader etc.?

Thanks

RE: Example of a bootloader that could boot 2 different app codes?

bjorn-spockeli — Tue, 28 Jan 2020 08:17:21 GMT

OK, understand.

It is possible to jump to different applications from the bootloader using a legacy method, see snippet below

/**
 * @brief Function for aborting current application/bootloader jump to to other app/bootloader.
 *
 * @details This functions will use the address provide to swap the stack pointer and then load 
 *          the address of the reset handler to be executed. It will check current system mode 
 *          (thread/handler) and if in thread mode it will reset into other application.
 *          If in handler mode \ref isr_abort will be executed to ensure correct exit of handler 
 *          mode and jump into reset handler of other application.
 *
 * @param[in]  start_addr  Start address of other application. This address must point to the 
               initial stack pointer of the application.
 *
 * @note This function will never return but issue a reset into provided application.
 */
#if defined ( __CC_ARM )
__asm static void bootloader_util_reset(uint32_t start_addr)
{
    LDR   R5, [R0]              ; Get App initial MSP for bootloader.
    MSR   MSP, R5               ; Set the main stack pointer to the applications MSP.
    LDR   R0, [R0, #0x04]       ; Load Reset handler into R0. This will be first argument to branch instruction (BX).

    MOVS  R4, #0xFF             ; Load ones to R4.
    SXTB  R4, R4                ; Sign extend R4 to obtain 0xFFFFFFFF instead of 0xFF.
    MRS   R5, IPSR              ; Load IPSR to R5 to check for handler or thread mode.
    CMP   R5, #0x00             ; Compare, if 0 then we are in thread mode and can continue to reset handler of bootloader.
    BNE   isr_abort             ; If not zero we need to exit current ISR and jump to reset handler of bootloader.

    MOV   LR, R4                ; Clear the link register and set to ones to ensure no return, R4 = 0xFFFFFFFF.
    BX    R0                    ; Branch to reset handler of bootloader.

isr_abort
                                ; R4 contains ones from line above. Will be popped as R12 when exiting ISR (Cleaning up the registers).
    MOV   R5, R4                ; Fill with ones before jumping to reset handling. We be popped as LR when exiting ISR. Ensures no return to application.
    MOV   R6, R0                ; Move address of reset handler to R6. Will be popped as PC when exiting ISR. Ensures the reset handler will be executed when exist ISR.
    MOVS  r7, #0x21             ; Move MSB reset value of xPSR to R7. Will be popped as xPSR when exiting ISR. xPSR is 0x21000000 thus MSB is 0x21.
    REV   r7, r7                ; Reverse byte order to put 0x21 as MSB.
    PUSH  {r4-r7}               ; Push everything to new stack to allow interrupt handler to fetch it on exiting the ISR.

    MOVS  R4, #0x00             ; Fill with zeros before jumping to reset handling. We be popped as R0 when exiting ISR (Cleaning up of the registers).
    MOVS  R5, #0x00             ; Fill with zeros before jumping to reset handling. We be popped as R1 when exiting ISR (Cleaning up of the registers).
    MOVS  R6, #0x00             ; Fill with zeros before jumping to reset handling. We be popped as R2 when exiting ISR (Cleaning up of the registers).
    MOVS  R7, #0x00             ; Fill with zeros before jumping to reset handling. We be popped as R3 when exiting ISR (Cleaning up of the registers).
    PUSH  {r4-r7}               ; Push zeros (R4-R7) to stack to prepare for exiting the interrupt routine.

    MOVS  R0, #0xF9             ; Move the execution return command into register, 0xFFFFFFF9.
    SXTB  R0, R0                ; Sign extend R0 to obtain 0xFFFFFFF9 instead of 0xF9.
    BX    R0                    ; No return - Handler mode will be exited. Stack will be popped and execution will continue in reset handler initializing other application.
    ALIGN
}

However, I would recommend trying to either integrate the HID keyboard example in to the FreeRTOS code or vice versa to avoid adding on even more complexity. As stated, performing DFU with multiple application images may be difficult and is not supported by our bootloader.

Best regards

Bjørn

RE: Example of a bootloader that could boot 2 different app codes?

samsam — Tue, 28 Jan 2020 04:57:45 GMT

My motivation is the "line of minimum resistance" ;) I want to combine the HID keyboard example(with light modification) and some my code that use a lot of FreeRTOS. Both variants will not work together or1 1 / or 2 . So the easiest way I though would be just to change the start vector from the Bootloader, else will have to modify the HID example to work with FreeRTOS and I'm not sure will be lucky enough to make it in acceptable time frame as there is no proper manuals on the FreeRTOS<>nRFSDK "interface" and also SES debugger still cant get it when can and when cant use it reliably (also lacks documentation, or at least what are limitations there), so will be harder with just NRF_LOG_ * s

RE: Example of a bootloader that could boot 2 different app codes?

bjorn-spockeli — Mon, 27 Jan 2020 10:27:13 GMT

Hi Samsam,

we do not have any official examples for switching between multiple applications. The main reason for this is that the SoftDevice interrupts/events mechanism, i.e that it forwards interrupts and events to a vector table that it assumes is located on the first flash page after the SoftDevice.

It is possible to alter this by calling sd_softdevice_vector_table_base_set(), but in order to initialize the SD you will have to revert to a legacy approach for initializing the SD, see the example in this answer.

What is your motivation for switching between two applicaitons? This adds quite a lot of complexity and will make it difficult to perfrom DFU with the bootloader from our SDK.

Best regards

Bjørn