Bootloader update problem

[Frederic]

I'm having an issue programming the bootloader using .hex file. I have "Erase all" by nrf52832 and was trying to debug my bootloader the code didn't stop at the beginning of the main. By breaking the code I was it was running in the Softdevice. Finally I figure out that the UICR[0] register wasn't written to the address of the bootloader. I manually write the address with nrfjprog.exe using the following command line and it start running properly:

nrfjprog.exe --family NRF52 --memwr 0x10001014 --val 0x00078000

Then I try to update the softdevice and applicative firmware and everything work fine.

I then try to update the bootloader version but it doesn't work. I'm trying to figure out what is not working properly but having some problem to run the bootloader in debug. Anyway I figure out that if I write the UICR[1] register to the __mbr_params_page_start__ (0x0007E000).

I was trying to see in the code where the UICR[1] register is use that could cause my problem. There is the following definition that I found but it doesn't seems to be used:

#define MBR_PARAMS_PAGE_ADDRESS (NRF_UICR->NRFFW[1])

Any idea why I can't update my bootloader if NRF_UICR->NRFFW[1] != 0x0007E000?

Also is there a way to have the NRF_UICR->NRFFW[0] and NRF_UICR->NRFFW[1] values included in the .hex file without modifying it manually?

Thank!

[Einar Thorsrud]

Hi,

Also is there a way to have the NRF_UICR->NRFFW[0] and NRF_UICR->NRFFW[1] values included in the .hex file without modifying it manually?

Yes and no. SDK 15.3 no longer uses the UICR but use the end of the MBR page (page 0) to store the bootloader settings and MBR params addresses. This is included when you build the bootloader project, so if you inspect the bootloader hex file (for instance by just opening it in nRF Connect Programmer, you will see that it includes two words at the end of page 0. Because of this, you must take care when programming the bootloader and SoftDevice initially, so that you don't accidentally erase either the MBR when writing the bootloader, or the other way around (erasing BL settings/MBR params address), which you will do if you erase all pages that you are writing to. This is a common problem with SDK 15.3.

[Frederic]

I'm comparing the .hex generated by the open_bootloader_usb_mbr_pca10056 example and my project and in the example .hex file I see the following 2 lines but not in mine:

:040FF80000000E00E7
:040FFC0000E00F0002

I understand that I won't have the same exact lines but lines that will begin with :040FF8 and :040FFC.

I have the definition of m_uicr_bootloader_start_address in my code as follow:

volatile uint32_t m_uicr_bootloader_start_address __attribute__ ((section(".uicr_bootloader_start_address")))
= BOOTLOADER_START_ADDR;

#define BOOTLOADER_START_ADDR (CODE_START)

#define CODE_START ((uint32_t)&_vectors)

In the linker script (bootloader.ld) the uicr_bootloader_start_address section is define in the MEMORY definition but not placed.

MEMORY
{
        UNPLACED_SECTIONS (wx) : ORIGIN = 0x100000000, LENGTH = 0
        uicr_mbr_params_page (wx) : ORIGIN = 0x00000ffc, LENGTH = 0x00000004
        uicr_bootloader_start_address (wx) : ORIGIN = 0x00000ff8, LENGTH = 0x00000004
        bootloader_settings_page (wx) : ORIGIN = 0x0007f000, LENGTH = 0x00001000
        mbr_params_page (wx) : ORIGIN = 0x0007e000, LENGTH = 0x00001000
        RAM (wx) : ORIGIN = 0x20000000, LENGTH = 0x00010000
        FLASH (wx) : ORIGIN = 0x00000000, LENGTH = 0x00080000
}

It's the same for the uicr_mbr_params_page section.

Any idea why the definition is remove? Optimization Level at None doesn't work.

[Turbo J]

Check your hex file generation command. It may not include the extra uicr_mbr_params_page section.

[Frederic]

Is this what you are talking about?

"C:\Program Files\SEGGER\SEGGER Embedded Studio for ARM 4.50\bin\mkld" -memory-map-segments "FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000;mbr_params_page RX 0x0007E000 0x1000;bootloader_settings_page RX 0x0007F000 0x1000; uicr_bootloader_start_address 0xFF8 0x4; uicr_mbr_params_page 0xFFC 0x4;" -section-placement-file d:/config/flash_placement_bootloader.xml -check-segment-overflow -symbols __STACKSIZE__=2048;__STACKSIZE_PROCESS__=0;__HEAPSIZE__=0 -section-placement-macros FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x78000;FLASH_SIZE=0x6000;RAM_START=0x20000008;RAM_SIZE=0xfff8 "d:/Output/Bootloader Release/Obj/Bootloader.ld"
"C:\Program Files\SEGGER\SEGGER Embedded Studio for ARM 4.50\gcc\arm-none-eabi\bin\ld" -X --omagic -eReset_Handler --defsym=__vfprintf=__vfprintf_long --defsym=__vfscanf=__vfscanf_long -EL --gc-sections "-Td:/Output/Bootloader Release/Obj/Bootloader.ld" -Map Output/Release/Exe/Bootloader.map -u_vectors -o Output/Release/Exe/Bootloader.elf --emit-relocs --start-group "@d:/Output/Bootloader Release/Obj/Bootloader.ind" --end-group
"C:\Program Files\SEGGER\SEGGER Embedded Studio for ARM 4.50\gcc\arm-none-eabi\bin\objcopy" Output/Release/Exe/Bootloader.elf d:/Output/Release/Exe/Bootloader.hex -Oihex

I've just added the uicr_bootloader_start_address 0xFF8 0x4; uicr_mbr_params_page 0xFFC 0x4;" in the -memory-map-segments parameter but it doesn't change anything.

I'm using Segger Embedded Studio.

[Turbo J]

You need to change the objcopy command. It processes only .text section by default IIRC.

[Frederic]

In Segger studio, in the project option, Code/Build section, the memory segment must have the uicr_bootloader_start_address and the uicr_mbr_params_page segment define WITH the RX parameter. I have added it manualy but forgot the RX.

FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000;mbr_params_page RX 0x0007E000 0x1000;bootloader_settings_page RX 0x0007F000 0x1000"