Currently, I'm trying to flash my custom board that has nRF52832 with an uart application that I integrated buttonless DFU. I'm running into a problem where when I try to flash my hex file that has the following combination :
I got the following error :
"ERROR: The file specified is not a valid hex file, has data outside valid areas"
"ERROR: or does not have data in valid areas."
From what I understand, it is an error on the memory side where my program might have passed its limit. But I don't know how to fix it. I'm not sure the type of model of my nRF52832, but on nRF Connect, it says that it is NRF52832_xxAB_REV1, Core RAM: 32KiB and Core ROM: 256KiB in pages of 4KiB. I'm using SES with SDK 16.0.0
I see. You have the small version of the nRF52832, and I suspect that both the bootloader and the bootloader settings page hex files are configured for the 512 variant (not the 256 variant).
If you try to flash only the bootloader or only the bootloader settings file without merging them, does it give the same message?
Go to your project settings for the bootloader, and change all the start addresses according to your flash size. The range of the flash is:
512kB variant: 0x0000 0000 -> 0x0008 0000
256kB variant: 0x0000 0000 -> 0x0004 0000
So what you need to do is to change the bootloader start address to move all the flash placement settings to match your flash size.
Most important are the settings in Section Placement Macros:
And you can also change the settings in Memory Segments:
Then you may need to edit your section placement macros in the flash_placement.xml file, mainly the "bootloader_settings_page" and "mbr_params_page". You find this file by right clicking your project from the project explorer in SES, and select "Edit Section Placement".
Then you need to set the correct size for your bootloader settings file. This is done when you generate them:
>nrfutil settings generate --help
Usage: nrfutil settings generate [OPTIONS] HEX_FILE
nRF IC family: NRF51 or NRF52 or NRF52QFAB
or NRF52810 or NRF52840 [required]
--application TEXT The application firmware file. This can be
omitted ifthe target IC does not contain an
application in flash.Requires --application-
version or --application-version-string.
--application-version INTEGER The application version.
The application version string, e.g.
"2.7.31". Will be converted to an integer,
--bootloader-version INTEGER The bootloader version. [required]
--bl-settings-version INTEGER The Bootloader settings version.Defined in
nrf_dfu_types.h, the following apply to
|SDK12.0.0 - SDK15.2.0|1|
|SDK15.3.0 - |2| [required]
--start-address INTEGER Custom start address for the settings page.
If not specified, then the last page of the
flash is used.
--no-backup Do not overwrite DFU settings backup page.
If not specified, than the resulting .hex
file will contain a copy of DFU settings,
that will overwrite contents of DFU settings
--backup-address INTEGER Address of the DFU settings backup page
inside flash. By default, the backup page
address is placed one page below DFU
settings. The value is precalculated based
on configured settings address
(<DFU_settings_address> - 0x1000).
The method of boot validation for
The method of boot validation for
--softdevice FILE The SoftDevice firmware file. Must be given
if SD Boot Validation is used.
--key-file FILE The private (signing) key in PEM format.
Needed for ECDSA Boot Validation.
--help Show this message and exit.
Try to use the --family NRF52QDAB option, and it will put the start address for this file to 0x0003F000 instead of 0x0007F000.
I did some changes to my bootloader's Section Placement Macros as following :
I only changed the FLASH_PH_SIZE and FLASH_START. I did not make any changes to Memory Segments and flash_placement.xml file as I'm not sure what and how exactly to modify it into. So I would like your recommendation on what these modifications should be, please. Then I tried to reflash the program with the new setting for the bootloader and there was no more error but our custom board does not seem to be working. Nothing was advertising.
A weird remark I notice was, I flashed my custom board with the bootloader with the default setting as shown in the following image :
nRF Connect managed to see the custom board advertising DFUTarg and I was able to DFU the custom board with my uart application that was integrated with buttonless DFU.