nRF52805 Buttonless OTA DFU

[StevenW807]

Hi, dear Nordic team. I would like to use buttonless OTA DFU for nRF52805.

Here is what I did: 

Step 1) install all tools

Step 2) Build my ADC code, rename the output hex file as "app.hex"

Step 3) Because I use nRF52805, so I selected PCA10040e. Since both S112 and S113 support the nRF52805 BLE function, I just randomly selected S112. The final selected folder for bootloader code is: SDK_17.0.2\examples\dfu\secure_bootloader\pca10040e_s112_ble\ses

Build this project, rename the output hex file as "bootloader.hex"

Step 4) Generating the BootLoader settings page hex file "settings.hex" by using this command in win10 command promot: 

nrfutil settings generate --family NRF52 --application app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex

/*
Win10 cmd returns:

Note: Generating a DFU settings page with backup page included.
This is only required for bootloaders from nRF5 SDK 15.1 and newer.
If you want to skip backup page generation, use --no-backup option.

Generated Bootloader DFU settings .hex file and stored it in: settings.hex

Bootloader DFU Settings:
* File:                     settings.hex
* Family:                   nRF52
* Start Address:            0x0007F000
* CRC:                      0x4ED1A154
* Settings Version:         0x00000002 (2)
* App Version:              0x00000001 (1)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x00009C10 (39952 bytes)
* Application CRC:          0xAC4D0291
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0xDF751A8C
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

*/

Step 5) Merge all above 3 hex files and softdevice s112 version 7.2.0 by using this command

mergehex --merge bootloader.hex settings.hex --output bl_temp.hex
mergehex --merge bl_temp.hex app.hex s132_nrf52_7.0.1_softdevice.hex --output whole.hex

Step 6) Upload combined hex file "whole.hex" to nRF52805 by using this command: 

nrfjprog --eraseall -f NRF52 
nrfjprog --program whole.hex --verify -f NRF52 
nrfjprog --reset -f NRF52

Question: 

When I'm using command nrfjprog --program whole.hex --verify -f NRF52, the win10 command prompt gives me the following error. I found it's my bootloader.hex and app.hex overlaps. 

Parsing image file.
ERROR: The file specified is not a valid hex file, has data outside valid areas
ERROR: or does not have data in valid areas.



/*
I found the issue was caused by bootloader.hex and app.hex, because in win10 cmd: 

D:\buttonlessOTA>mergehex --merge bootloader.hex app.hex --output bootloader_app.hex
Parsing input files.
Merging file "bootloader.hex" into output.
Merging file "app.hex" into output.
Overlapping segments detected at address 102400.ERROR: The hex files cannot be merged since there are conflicts.

My SEGGER link-->section placement macros is:

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x80000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x10000
FLASH_START=0x71000
FLASH_SIZE=0xd000
RAM_START=0x20005968
RAM_SIZE=0xa698
*/

What's the correct to select FLASH and RAM for my project, please? Should I choose "just enough" FLASH and RAM?

Thanks in advance! 

[Einar Thorsrud]

Hi,

You are not using the correct memory sizes. For instance the correct would be FLASH_PH_SIZE=0x30000 and RAM_PH_SIZE=0x6000. Please adapt your projects (both bootloader and app) as explained in Developing for the nRF52805 with nRF5 SDK.

[StevenW807]

Hi Einar, thanks for your reply! 

Yes, I followed the link which you provided. I used the default FLASH and RAM address in the example project to build both the bootloader (SDK_17\examples\dfu\secure_bootloader\pca10040e_s112_ble\ses)  and the application project.

Also, I changed NRF_SDH_CLOCK_LF_SRCA to 0 in sdk_config.h file.

Although both projects could build successfully, I still have the error:

Parsing image file.
ERROR: The file specified is not a valid hex file, has data outside valid areas
ERROR: or does not have data in valid areas.

Does the Section Placement Macros define the entire chip available FLASH and RAM, or just the FLASH and RAM required for my project? 

// ------------------------- Bootloader -------------------------

FLASH RX 0x0 0x30000;RAM1 RWX 0x20000000 0x6000;mbr_params_page RX 0x0002E000 0x1000;bootloader_settings_page RX 0x0002F000 0x1000;uicr_bootloader_start_address RX 0x10001014 0x4;uicr_mbr_params_page RX 0x10001018 0x4

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x30000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x6000
FLASH_START=0x28000
FLASH_SIZE=0x6000
RAM_START=0x200022c8
RAM_SIZE=0x3d38


// ------------------------- Application -------------------------

FLASH1 RX 0x00000000 0x00030000;RAM1 RWX 0x20000000 0x00006000

FLASH_PH_START=0x0 
FLASH_PH_SIZE=0x30000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x6000
FLASH_START=0x19000
FLASH_SIZE=0x17000
RAM_START=0x200022c8
RAM_SIZE=0x3d38

[Einar Thorsrud]

Hi,

StevenW807 said:

Yes, I followed the link which you provided. I used the default FLASH and RAM address in the example project to build both the bootloader (SDK_17\examples\dfu\secure_bootloader\pca10040e_s112_ble\ses)  and the application project.

Your addresses looks good now.

StevenW807 said:

Parsing image file.
ERROR: The file specified is not a valid hex file, has data outside valid areas
ERROR: or does not have data in valid areas.

This is from nrfjprog when you try to program the merged hex, wright? What happens if you first do a chip erase, then program the SoftDevice, application, bootloader and bootloader settings (in that order - or at least the SoftDevice before the bootloader)? Make sure you program without the sector erase option, as the bootloader hex files contains data in the MBR page. I ask because there is a bug in recent mergehex versions that is fixed in the latest one, where it creates corrupt hex images. So you should in any case update nRF Command Line tools to (at least) 10.12.2.

Can you upload both the separate hex files you generate and the merged hex file here so that I can inspect them?

StevenW807 said:

Does the Section Placement Macros define the entire chip available FLASH and RAM, or just the FLASH and RAM required for my project? 

Both. The *_PH_* macros define the entire chip. The other macros define the specific application's flash and RAM start address and size (which must be within the physical limitations, but also not overlap with others. Lastly, the application must start at the page immediately after the SoftDevice. So the application start address is always equal to the size of the SoftDevice (which is always stated as a multiple of 0x1000 / full pages) - and your value here, 0x19000, is correct for S112 7.2.0.

[StevenW807]

Thanks for your professional support. 

Q1

I founded the issue! Because I'm using nRF52805, so when I generate the settings.hex, I need to use the correct hardware family version. Because I use nRF52805 (same Flash and Ram with nRF52810), so I need to use "--family NRF52810 ", not "--family NRF52".

However, although I could see "Nordic_Buttonless" in nRF Connect Mobile App, I cannot use the OTA DFU function. When I downloaded the ZIP file for my customized application, it keeps showing "Starting DFU, Starting Bootloader" repeatly. OTA DFU process is never finished. Any idea, please? Below are my cmd commands and all hex files. 

nrfutil settings generate --family NRF52810 --application app.hex --application-version 3 --bootloader-version 2 --bl-settings-version 2 settings.hex

nrfjprog --eraseall -f NRF52

nrfjprog --program s112_nrf52_7.2.0_softdevice.hex --verify -f NRF52

nrfjprog --program app.hex --verify -f NRF52

nrfjprog --program bootloader.hex --verify -f NRF52

nrfjprog --program settings.hex --verify -f NRF52

nrfjprog --reset -f NRF52

nrfutil pkg generate --application app_new.hex --application-version 3 --hw-version 52 --sd-req 0x0103 --key-file priv.pem OTA_BUTTONLESS_NRF52805.zip

8424.buttonlessOTA.zip

Q2

Einar said: 
Both. The *_PH_* macros define the entire chip. The other macros define the specific application's flash and RAM start address and size (which must be within the physical limitations, but also not overlap with others. 

Does this sentence mean that I need to use different FLASH and RAM addresses for bootloader and application? Because my bootloader and application FLASH and RAM overlap: 

// Bootloader 
FLASH_START=0x28000
FLASH_SIZE=0x6000
RAM_START=0x200022c8
RAM_SIZE=0x3d38

// Application
FLASH_START=0x19000
FLASH_SIZE=0x17000
RAM_START=0x200022c8
RAM_SIZE=0x3d38

Thank you again, Einar! 

[Einar Thorsrud]

Hi,

StevenW807 said:

I founded the issue! Because I'm using nRF52805, so when I generate the settings.hex, I need to use the correct hardware family version. Because I use nRF52805 (same Flash and Ram with nRF52810), so I need to use "--family NRF52810 ", not "--family NRF52".

Good catch! Yes, the BL settings page must be on the last page of the flash, and then you must select a device with the same amount of flash memory as your device.

StevenW807 said:

When I downloaded the ZIP file for my customized application, it keeps showing "Starting DFU, Starting Bootloader" repeatly. OTA DFU process is never finished. Any idea, please?

I am not sure wat goes on here. Can you check the log from nRF connect on the phone? Also, what happens if you try to do DFU from nRF Connect for Desktop (you need additional DK/dongle connected to the computer for this to work)?

StevenW807 said:

Does this sentence mean that I need to use different FLASH and RAM addresses for bootloader and application?

No, the *_PH_* can be the same. It is not actually used by the linker.

StevenW807 said:

Because my bootloader and application FLASH and RAM overlap: 

This overlap in flash could have been a problem.  You should make sure that the application's FLASH_START + FLASH_SIZE <= the bootloader's FLASH_START. That way you would get a linker error if the application is too large. I checked the hex files though, and it does not overlap, so while it would be good to fix this it does not explain the issue you are seeing.

overlap in RAM is no problem, as the application and bootloader does not run at the same time.