Using app_timer to determine if boot loader should start

RE: Using app_timer to determine if boot loader should start

Edvin — Thu, 22 Nov 2018 07:53:24 GMT

[quote user="esa"]Hmm, I tried to add the nrf_dfu_mbr_init_sd() back in to nrf_bootloader_app_start() again, but it fails if it is already called, which it now is. So I'll leave it commented out.[/quote]

Yes. Sorry. That is correct. Leave that commented out.

[quote user="esa"]
The reason I start the SD is that I didn't get the app_timer to run/count without it. I guess the RTC interrupts need the SD to be enabled to propagate them to the app_timer or something?[/quote]

It should be possible to use without the SoftDevice. However, if your application works now, I assume it is fine, but look into the nrf_drv_clock_init() function. It behaves a bit differently when the softdevice is enabled and when it isn't, depending on whether SOFTDEVICE_PRESENT is defined in your preprocessor defines or not.

Regarding the button3, I see your point. It is difficult to make it work "out of the box" on a DK, and at the same time be completely modifiable from one file. But I agree that the button 3 3 handling could be done in a different way.

One way is of course to modify your custom_board.h file, and define the BOOTLOADER_BUTTON from there, which will lead to a redefinition, but it could work as a reminder to remove the default define when porting to new SDKs.

BR,

Edvin

RE: Using app_timer to determine if boot loader should start

Erik — Wed, 21 Nov 2018 16:08:05 GMT

Thank you so much, that made me more confident that the modifications are robust. I also added the clearing of the ICPR.

Yes, I am aware of the newer SDKs and would love to upgrade to those, but I am not sure if the product-owner wants to pay for those developing hours so we stay at a minimum of SDK12 for now.

The reason I start the SD is that I didn't get the app_timer to run/count without it. I guess the RTC interrupts need the SD to be enabled to propagate them to the app_timer or something?

Hmm, I tried to add the nrf_dfu_mbr_init_sd() back in to nrf_bootloader_app_start() again, but it fails if it is already called, which it now is. So I'll leave it commented out.

BR Erik

RE: Using app_timer to determine if boot loader should start

Edvin — Wed, 21 Nov 2018 14:36:29 GMT

Hello Erik,

You mention that you use IAR 7.60.2 and IAR 8.30.1, so I just want to mention the release notes for our later SDKs regarding IAR versions. I don't think your are directly impacted by this, as your bootloader use IAR7, but it is worth keeping in mind for the future, in case you want to update the bootloader, and then use IAR8.

Questions:

[quote user=""]Is this ok? (it seems to work, but I need it to be bulletproof)[/quote]

I don't see any issues with moving the ble_stack_init() to before the nrf_dfu_enter_check(), but is there a particular reason why you want to start it in the bootloader if the transport layer isn't used? Do you use the softdevice to decide whether or not to enter DFU or application? I see that the softdevice's vector table is set in nrf_bootloader_app_start(), but softdevice_enable() is not called by default.

As long as you disable the softdevice before entering the app, I don't see a problem with it. I spoke to our SDK team, who has designed the bootloader, and he told me that there is no reason to change the nrf_bootloader_app_start() function, as long as you disable the softdevice before entering this. It doesn't actually start the softdevice, it only sets the vector tables. He actually also advised to clear the ICPR in addition to the ICER, like it is done in the bootloader from SDK15.2.0:

    // Disable and clear interrupts
    // Notice that this disables only 'external' interrupts (positive IRQn).
    NRF_LOG_DEBUG("Disabling interrupts. NVIC->ICER[0]: 0x%x", NVIC->ICER[0]);

    NVIC->ICER[0]=0xFFFFFFFF;
    NVIC->ICPR[0]=0xFFFFFFFF;
#if defined(__NRF_NVIC_ISER_COUNT) && __NRF_NVIC_ISER_COUNT == 2
    NVIC->ICER[1]=0xFFFFFFFF;
    NVIC->ICPR[1]=0xFFFFFFFF;
#endif

[quote user=""]Are there any thing else I need to de-init before jumping to the app now that I have initialized the ble_stack and SD?[/quote]

If you enable the softdevice, you have to disable before entering the application. It is also a good idea to disable any other hardware peripherals, such as timers, that you may have started in the bootloader, or else they will keep running, drawing power.

[quote user=""]Are there any stability reasons for these design changes in the secure bl vs the legacy?[/quote]

The bootloader has become easier to understand in the later SDKs, so it is easier to work with, in my opinion at least. As mentioned earlier, the latest bootloader clears the ICPR, which is an improvement, to prevent any old interrupts to fire right after you start the application. So I guess there are some improvements. In addition to these, softdevice changes are the main reason for updating the bootloader in the later SDKs (as well as in the other examples).

[quote user=""]In the legacy bootloader the SD was not initialized if the app_reset was set. Do I need to do a similar check in the secure BL with my modification?[/quote]

I guess that the reason for this is that there is no need to start the softdevice if it isn't used in the bootloader. It takes a bit of time, and hence, a bit of power to do this. If the chip resets without the intention of doing a DFU, there is no reason to start the SoftDevice in the bootloader.

I hope this answered some of your questions. Let me know if anything is unclear, or if you have other bootloader-related questions.

Best regards,

Edvin