nRF52832 Mesh Bootloader not running

[Arif@Lynxemi]

Hi,

I'm using a custom board with an nrf52832. I can also emulate using an nrf52840dk. I have to compile the bootloader because there is no LF crystal on my custom board. So I set:

#define NRF_SDH_CLOCK_LF_SRC 0 // RC
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_XTAL_ACCURACY 7
#define NRF_SDH_CLOCK_LF_ACCURACY 1
#define NRFX_CLOCK_CONFIG_LF_SRC 0
#define CLOCK_CONFIG_LF_SRC 0

in sdk_config.h in both the application and bootloader include folders. The precompiled bootloader does not work either.

My mesh application runs fine without the bootloader but with the device address page and softdevice. The mesh application is using nrf sdk for mesh v5.0.0 with nrf5 SDK v17.0.2. The address page is compiled for the s132 v7.2.0 softdevice and for the nrf52832_xxAA hardware:

python .\device_page_generator.py -c .\bootloader_config_X49_REV_B.json -d nrf52832_xxAA -sd "s132_7.2.0" --output bin\X49_REV_B_device_page_nrf52832_xxAA_s132_7.2.0.hex

The softdevice is the s132 v7.2.0 and has worked fine on my other nRF52832 projects. 

When I add the gccarmemb bootloader compiled for the nRF52832, the application does not start at all. Compiling the bootloader with the BOOTLOADER_DEBUG_ENABLE flag set causes compilation to fail with memory overflow:

[build] c:/progra~2/gnuarm~1/102020~1/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: mesh\bootloader\mesh_bootloader_gccarmemb_nrf52832_xxAA.elf section `.text' will not fit in region `FLASH'
[build] c:/progra~2/gnuarm~1/102020~1/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: region FLASH overflowed with .data and user data
[build] c:/progra~2/gnuarm~1/102020~1/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 1084 bytes
[build] collect2.exe: error: ld returned 1 exit status
[build] ninja: build stopped: subcommand failed.

I have other projects that are working well. Mesh applications for the nRF52840 with the mesh bootloader work, and Mesh LPN applications with the nRF5 SDK secure bootloader also work.

I have not tinkered with the linker script. What could be the problem?

[Joakim Jakobsen]

Hi. 

Talked to a colleague of mine about this;

Could you test this on the DFU example and see what happens when you add the bootloader there?

Mesh applications for the nRF52840 with the mesh bootloader work

Does it work on the nRF52840-DK or is it a similar custom board to what you are working with now?

________

Compiling the bootloader with the BOOTLOADER_DEBUG_ENABLE flag set causes compilation to fail with memory overflow:

This will cause and issue with flash, so that is expected. However, we don't have a solution for it. 

Br,
Joakim

[Arif@Lynxemi]

The pre-compiled bootloader together with the DFU example stops at ble_stack_init in main.c, line 229. Changing the clock source to RC oscillator allows the application to run. I used a device page with the default bootloader config json this time.

Odd. The pre-compiled bootloader uses the LF crystal as a clock source right? Why does it run in this case?

[Joakim Jakobsen]

I'll need to look at this a little closer, and confer with some colleagues that have more experience on the matter. 

Will get back to you with an update early next week. 

Br, 
Joakim

[Arif@Lynxemi]

Hi Joakim,

I think I found the issue and it's not related to anything hardware-wise. The issue was this:

/** Device product identifier. */
#define DEVICE_PRODUCT_ID (0x0000)

/** Device version identifier. */
#define DEVICE_VERSION_ID (0x0000)

in nrf_mesh_config_app.h. For this new application, I just copied the config from the light switch example and used the corresponding values in the bootloader_config.json.

When I changed the DEVICE_VERSION_ID to a non-zero number, it started working. I suspect that the bootloader has an assert on a DEVICE_VERSION_ID of 0. Can you confirm this? If this is the case, how does a user know when an assert has been triggered on the bootloader side of things? I'm not seeing anything on RTT when it occurs.

Regards,

Arif

[Joakim Jakobsen]

Thanks for sharing.

I've asked around, and it doesn't seem that it is a known issue with DEVICE_VERSION_ID = 0.

Are you using the pre-compiled BL when you see this?

BR,
Joakim

[Arif@Lynxemi]

Yes, I tested with the pre-compiled bootloader. Shall I mark this issue as solved for now?

Regards,

Arif

[Joakim Jakobsen]

Thanks. 

You don't have to mark the issue as resolved.

I'll do some investigation on why the error occurred in the first place. Meanwhile you can use your workaround for the issue. 
I'll leave the ticket open for a while, and I'll get back to you if I have any more information to share. 

Please let me know if you have any further questions. 

Br, 
Joakim