few questions about bootloader settings

[ziv123]

hello Nordic

i am working with nrf52832 soc with SDK 16.0, S132 V7.0.1

following this path:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

and this : https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrfutil%2FUG%2Fnrfutil%2Fnrfutil_settings_generate_display.html

1. when trying to read current setting of existing bootloader in the examples i get this:

C:\Nordik SDK\examples\dfu\secure_bootloader>nrfutil settings display pca10040_uart\ses\Output\Release\Exe\secure_bootloader_uart_mbr_pca10040.hex
Bad access at 0x7F000: not enough data to read 4 contiguous bytes
Usage: nrfutil settings display [OPTIONS] HEX_FILE

Error: Failed to parse .hex file: Bad access at 0xFF000: not enough data to read 4 contiguous bytes

why is that ?

2. if i generate a setting for the bootloader and i include the softdevice in the "nrf settings generate command (like so:  --softdevice FILE s132_nrf52_7.0.1_softdevice.hex)

do i still need to mergehex the bootloader with the s132 hex file ? considering that when i flash my application (using SEGGER) after erasing the nrf52832 i do not need to flash the softdevice separately

3. the settings generate command refers to application version, do i need to change the setting each time i change application version or it's name (considering the version is in the name) ?

4. if i mergehex the bootloader settings hex file with the bootloader hex file and i flash the bootloader without having an application flashed on the device, what will happen ? would i be able to flash the application via SEGGER normally or must i have the application hex flashed before the flashing of the bootloader or mergehex with the bootloader ?

that it for now

p.s. 5. in the dfu examples, what's the difference between pca10040_uart to pca10040_uart_debug can both be used for production also can they be used for a PCB not an nrf52832DK ? 

hope to read from you soon

best regards

Ziv

 

[Einar Thorsrud]

Hi Ziv,

ziv123 said:

indeed the watchdog seems to be the cause for the reset.

That is good. Then things make sense.

ziv123 said:

so, is it true that the only way i have to get a reset which will also rest the watchdog (considering no user intervention on pin pressing or shutting of the system) is to stuck my application until i get a timeout event ?

if this is the case this is very awkward

Yes that is true, as you see from the reset behavior table. It is also intentional to prevent any accidental disabling of the watchdog.

ziv123 said:

i don't want to create a dependency between the bl and the application

There is a dependency here, but it it quite weak as the bootloader reads the watchdog configuration from the watchdog itself, though you may need to make some adjustments in special cases. Generally the main thing is that you should ensure that you do not have a too short watchdog timeout. In any case there is no way around handing this in the bootloader if you use a watchdog, as you cannot disable the watchdog in an elegant way. (And if you do disable it by allowing it to time out, a watchdog reset also clears the retention registers, so you cannot rely on those for entering DFU mode).

[ziv123]

Hi Einar 

my bootloader has a WTD

if (dfu_enter)
    {
        nrf_bootloader_wdt_init();
        scheduler_init();
        dfu_enter_flags_clear();

not sure i understand where the configuration copy takes place, so maybe i am missing something there ?

the WTD timeout in my app is 15 seconds so is should be enough time since the timer in the bootloader for feeding the WTD is:

#define MAX_FLASH_OP_TIME_TICKS 3200 // ~100 ms

also, why not using nrfx_wtd..  in Nordic's bootloader uart (or any) examples ?

hope to read from you soon

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

ziv123 said:

not sure i understand where the configuration copy takes place, so maybe i am missing something there ?

This is all handled in the implementation in components\libraries\bootloader\nrf_bootloader_wdt.c. You can see that the reload value is read using nrf_wdt_reload_value_get(), and that is used to determine the frequency of feeding the bootloader.

ziv123 said:

the WTD timeout in my app is 15 seconds so is should be enough time since the timer in the bootloader for feeding the WTD is:

15 seconds should be no problem. This is not the time for feeding the WDT though, but a margin added because the CPU cannot run during flash operations.

ziv123 said:

also, why not using nrfx_wtd..  in Nordic's bootloader uart (or any) examples ?

The WDT driver primarily contain code for configuring and starting the WDT. That is not part of what the bootloader implementation does, as it just feeds a running bootloader. (strictly speaking the WDT driver also feeds the bootloader, but that is just by a single function call - nrf_wdt_reload_request_set() - which is also used by the bootloader).

It is a bit odd that you get this problems with the configuration you describe. Particularly it like the reset happens quite early as several things that should have been logged in the beginning of the bootloader is missing (like "WDT enabled CRV" etc).

Some suggestions:

1. Double check that the WDT reload value really is 15 seconds.
2. Make sure to feed the WDT right before you reset into the bootloader.
3. Add some logging when the bootloader feeds the WDT in the wdt_feed() function together with the call to nrf_wdt_reload_request_set(i) to see that it is actually fed.