Start debug buttonless dfu with bootloader

[Turnaev]

Hello!

I want merge and write via SWD full firmware, including: main firmware, bootloader, settings page.

When I start debug, all data correctly writed, but main firmware not start, bootloader thinks that firmware broken. After that, I update firmware via phone, and main firmware start working.

I use:

• nrf52832 in nrf52810 mode;
• nRF5_SDK_15.3.0_59ac345;
• s112_nrf52_6.1.1_softdevice;

examples:

• ble_app_buttonless_dfu for pca10040e
• secure_bootloader pca10040e_ble

Bond mode disabled, all settings default

IDE: SES.

For generation firmwares zip and settings hex, I use next commands:

nrfutil pkg generate --hw-version 52 --sd-req 0xB8 --application-version-string 0.5.02 --application Output\Release\Exe\ble_app_buttonless_dfu_pca10040e_s112.hex --key-file PrivateKey.pem Firmware.zip

nrfutil pkg generate --hw-version 52 --sd-req 0xB8 --bootloader-version 2 --bootloader secure_bootloader_ble_s112_pca10040e.hex --key-file PrivateKey.pem Bootloader.zip

nrfutil settings generate --family NRF52810 --application Output\Release\Exe\ble_app_buttonless_dfu_pca10040e_s112.hex --application-version-string 0.5.02 --bootloader-version 3 --bl-settings-version 2 BlDfuSettings.hex

mergehex -m BlDfuSettings.hex secure_bootloader_ble_s112_pca10040e.hex -o bootloader.hex

I uploaded the entire flash memory to a file for both cases and compared them. Several differences were found:

Search for differences

1. C:\Temp2\1test.bin: 196 608 bytes
2. C:\Temp2\2test.bin: 196 608 bytes
Offsets: hexadec.

26000:	FF	DE
26001:	FF	C0
26002:	FF	AD
26003:	FF	DE

26005:	FF	01
26006:	FF	1E
26007:	FF	F1

27000:	FF	DE
27001:	FF	C0
27002:	FF	AD
27003:	FF	DE
27004:	FF	FE
27005:	FF	01
27006:	FF	1E
27007:	FF	F1

15 difference(s) found. 

These addresses do not apply to the loader, the softlibrary, or the firmware hex file.

After that, I found out that the ble_app_buttonless_dfu is recording at these addresses. What is this?

And interestingly enough, if you do not run the firmware for execution (only run to start of main() ), the addresses above will not be recorded, you can press the reset many times, and the controller will reach quite correctly to the main. 

In this case, if you unload the flash memory, it will completely coincide with the one loaded via the emulator.

I don’t understand why, immediately after writing the flash memory through an emulator, there is not run to main??

The biggest problem is that I can not start the program for debugging. And if I turn on the bond mode, the bootloader is not visible in the list of devices, because it is not bond with anyone.

[Einar Thorsrud]

Hi,

The bootloader (pca10040e_ble) starts at 0x28000, and the pages immediately below are FDS pages. What you are seeing at the beginning of the pages at 0x26000 and 0x27000 is the page tags used by FDS, which is written the first time FDS is initialized. (See Page tag).

The only reason I could think of that would make this prevent the bootloader from starting the application is if the CRC of the application includes the FDS pages, which will be the case if the application .hex file spans across this region in flash. Does it? If so that is probably a mistake, and you should make sure it does not happen (for instance by setting a smaller FLASH_SIZE in the linker settings in SES when you build the application). Another thing you could do is skip the CRC check in the bootloader altogether, by modifying the call to app_is_valid() in dfu_enter_check() in nrf_bootloader.c, always passing false.

[Turnaev]

Hello!

Thanks for the answer.

Changing the value of FLASH_SIZE has no effect. As it turned out, this value is not used anywhere at all, including in the flash_placement.xml file.

The skip of the checksum check works, and the transition to the main firmware is carried out, however, it is obvious that this option is invalid.

FDS not included in CRC calculation, because as I write above, after update via phone, main() run with empty and with writed FDS equally.

This is very strange, and could not understand yet..

[Einar Thorsrud]

Hi,

Turnaev said:

The skip of the checksum check works, and the transition to the main firmware is carried out, however, it is obvious that this option is invalid.

Since skipping CRC checksum works, this tells us that the flash region which the CRC is calculated for has changed. If the only difference is the FDS pages, then it seems that the FDS pages are part of the application are in this regard. That happens if the application .hex file you use to generate the bootloader settings page (via nrfutil) has some data above the FDS pages, as the CRC is calculated of everything between the lowest and highest address in the .hex file. Have you for instance put some persistent data at a specific location in flash in the application .hex file? Can you check the .hex file and verify at which address it ends?

Assuming this is the case, there are two obvious solutions:

• The best/correct is to move the persistent data to below the FDS pages. This is important for several reasons.
• Alternatively, skipping the CRC check in the bootloader doe snot actually have a significant down-side. It will help if the application get accidentally corrupted, but the likelihood of that happening with a properly tested application is small. And moreover, there is anyway no way to recover from accidentally corrupting flash in the bootloader and/or SoftDevice region. So the CRC check before every boot is in fact something that seems important, but really isn't for most applications.

Turnaev said:

FDS not included in CRC calculation, because as I write above, after update via phone, main() run with empty and with writed FDS equally.

 I did not understand what you are saying here. Can you elaborate?