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, 

ziv123 said:

ok so the config of " NRF_BL_DFU_ENTER_METHOD_BUTTON  " to 0 solved the first dfu issue, and the app works after the first one

Good to hear.

ziv123 said:

the log for the first and second dfu is this:

The log does not go far enough back, only start in the middle of the second DFU. Perhaps  Can you make a log that covers everything as intended? (sometimes it is easier to use the Logging feature of the RTT viewer if the amount of data becomes too much:

[ziv123]

the dfu in the log that you see is of the first dfu

there is nothing in the log regarding second dfu

after i send the application the commend to set the register and restart

it halts at Unknown function at address 0x275FC which is actually not in the bootloader address scope:

when i press F5 then the application returns to run.. if i send the command for dfu again the jlink informs me that the register is already set

any ideas ?

i think the problem is this: i have tried some things but what i get after the command to start dfu from my application which is that to remind,

NRF_POWER->GPREGRET = 0xB1;
NVIC_SystemReset();

i am stopped by a vector catch 

it is the same if i run only the application in debug mode without the bootloader flashed and command the app to start the dfu 

or if i debug in the bootlader after flashed and give the dfud application and then commend the running application to start the dfu i don't even send the next nrf defu serial command from terminal .. so i think the problem has something to do with the app or the command to the register 

what do you say ?

[Einar Thorsrud]

Hi,

I did not think about this before as you do not use the SoftDevice for serial DFU. However, if the SoftDevice is enabled when you call this code snippet:

NRF_POWER->GPREGRET = 0xB1;
NVIC_SystemReset();

that will not work. The reason is that writing to GPREGRET directly is not allowed. You need to write via the SoftDevice API instead when that is enabled, using sd_power_gpregret_set(). 

[ziv123]

ok .. maybe that will explain that i found out that i get asserted before even reaching the bootloader 

the address 0x275FC is the assertion of NRF_BREACK_COND or something like that which i compare to the blue screen of death.. any way i will try to change and see how it goes

[Einar Thorsrud]

Yes, you will get a SoftDevice fault with reason NRF_FAULT_ID_APP_MEMACC in this case. (A god tip is to enable logging when testing the app as well. If you tested the app with debug logging enabled you should have seen "SOFTDEVICE: INVALID MEMORY ACCESS" in the log.)