bootloader does not work if compiled using armgcc

RE: bootloader does not work if compiled using armgcc

Sigurd — Thu, 25 Apr 2019 14:00:33 GMT

Hi Eliot,

The main reason for this was convenience. I agree that the name is now confusing, and I have requested the name to be updated in the next SDK release.

RE: bootloader does not work if compiled using armgcc

Eliot Stock — Mon, 15 Apr 2019 23:44:09 GMT

Why did you not rename uicr_bootloader_start_address at the same time? It is no longer in the UICR, so the name is very confusing.

RE: bootloader does not work if compiled using armgcc

Elias Löwe — Fri, 15 Mar 2019 17:06:12 GMT

Sigurd

Thank you it works!

RE: bootloader does not work if compiled using armgcc

Sigurd — Fri, 15 Mar 2019 14:15:37 GMT

Hi,

The reason why --sectorerase is erasing the MBR(0x0 to 0x1000), is that the bootloader in SDK 15.3 stores the uicr_bootloader_start_address and uicr_mbr_params_page in the MBR part of the flash (0x0FF8 and 0x0FFC ). See this page. --sectorerase then erases the whole page(0x0 to 0x1000) before writing the hex file. The make flash and make flash_softdevice commands have unfortunately not been updated to reflect this change in SDK 15.3

A workaround is then to use mergehex, and merge the SoftDevice hex(it includes the MBR) and the application/bootloader hex. You can change the makefile to include something like this:

# Flash softdevice and app
flash_softdevice_and_app:
	@echo Flashing: s132_nrf52_6.1.1_softdevice.hex and app
	mergehex -m $(OUTPUT_DIRECTORY)/nrf52832_xxaa_s132.hex $(SDK_ROOT)/components/softdevice/s132/hex/s132_nrf52_6.1.1_softdevice.hex -o sd_app.hex
	nrfjprog -f nrf52 --program sd_app.hex --sectorerase
	nrfjprog -f nrf52 --reset

and then use make flash_softdevice_and_app, to flash both the SoftDevice and the bootloader.

RE: bootloader does not work if compiled using armgcc

Elias Löwe — Fri, 15 Mar 2019 13:59:23 GMT

Yesterday I've found the solution or workaround:

I've changed in secure_bootloader_gcc_nrf52.ld

MEMORY
{
  FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000
  RAM (rwx) :  ORIGIN = 0x200057b8, LENGTH = 0xa848
  uicr_bootloader_start_address (r) : ORIGIN = 0x00000FF8, LENGTH = 0x4
  uicr_mbr_params_page (r) : ORIGIN = 0x00000FFC, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x0007E000, LENGTH = 0x1000
  bootloader_settings_page (r) : ORIGIN = 0x0007F000, LENGTH = 0x1000
}

MEMORY
{
  FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000
  RAM (rwx) :  ORIGIN = 0x200057b8, LENGTH = 0xa848
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x0007E000, LENGTH = 0x1000
  bootloader_settings_page (r) : ORIGIN = 0x0007F000, LENGTH = 0x1000
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
}

taken from older SDK.

Please confirm if it is safe solution or suggest correct one?

RE: bootloader does not work if compiled using armgcc

Elias Löwe — Thu, 14 Mar 2019 14:04:32 GMT

I've just tried to flash HEX file produced by SES using nrfjprog ang got the same state.

nrfjprog -f nrf52 --program ../ses/Output/Release/Exe/secure_bootloader_ble_s132_pca10040.hex --sectorerase
Parsing hex file.
Erasing page at address 0x0.
Erasing page at address 0x78000.
Erasing page at address 0x79000.
Erasing page at address 0x7A000.
Erasing page at address 0x7B000.
Erasing page at address 0x7C000.
Erasing page at address 0x7D000.
Applying system reset.
Checking that the area to write is not protected.
Programming device.

It seems problem is not in FW itself or toolchain.

It seems nrfjprog erases 0x0 page where softdevice is (if I am not wrong)