Getting error : mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.elf section `.text' will not fit in region `FLASH', while building mesh bootloader with debug option enabled.

[nksharma]

Development environment :

ARM-GCC version - "gcc-arm-none-eabi-6-2017-q2-update"

nRF SDK version - nRF5_SDK_15.2.0_9412b96

nRF Mesh SDK version - nrf5SDKforMeshv310src

Platform - nrf52840_xxAA

Problem :

cmake command used :  cmake -DBUILD_BOOTLOADER=1 -DCMAKE_BUILD_TYPE=MinSizeRel -DBOOTLOADER_DEBUG_ENABLE=1 -DPLATFORM=nrf52840_xxAA ..

I have not done any changes in nRF5_SDK_15.2.0_9412b96 and nrf5SDKforMeshv310src SDKs. I am building it as it is.

I am trying to build nRF Mesh bootloader with debug option enabled using above command but I am getting below error :

.....

.....

[ 3%] Building ASM object mesh/bootloader/CMakeFiles/mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.dir/home/nishants/Downloads/Tar_Files/Nordic/nRF5_SDK_15.2.0_9412b96/modules/nrfx/mdk/gcc_startup_nrf52840.S.obj
[ 3%] Linking C executable mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.elf
/usr/local/gcc-arm-none-eabi-6-2017-q2-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld: mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.elf section `.text' will not fit in region `FLASH'
/usr/local/gcc-arm-none-eabi-6-2017-q2-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld: region FLASH overflowed with .data and user data
/usr/local/gcc-arm-none-eabi-6-2017-q2-update/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 2096 bytes
collect2: error: ld returned 1 exit status
mesh/bootloader/CMakeFiles/mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.dir/build.make:634: recipe for target 'mesh/bootloader/mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.elf' failed
make[2]: *** [mesh/bootloader/mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.elf] Error 1
CMakeFiles/Makefile2:209: recipe for target 'mesh/bootloader/CMakeFiles/mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.dir/all' failed
make[1]: *** [mesh/bootloader/CMakeFiles/mesh_bootloader_serial_gccarmemb_nrf52840_xxAA.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Am I missing anything?

Ho do I build mesh bootloader with debug option enabled?

Regards,

Nishant.

[Joakim Jakobsen]

Hi Nishant. 

cmake command used :  cmake -DBUILD_BOOTLOADER=1 -DCMAKE_BUILD_TYPE=MinSizeRel -DBOOTLOADER_DEBUG_ENABLE=1 -DPLATFORM=nrf52840_xxAA

 The command -DCMAKE_BUILD_TYPE=MinSizeRel genererates build files optimized for size. 

If you take a look at Building the mesh stack and examples, under "Useful CMake command line options": 

CMake allows you to generate project files in release or debug configurations. To do so, use the -DCMAKE_BUILD_TYPE option:

build $ cmake -DCMAKE_BUILD_TYPE=Release ..      # Generates build files in release mode
build $ cmake -DCMAKE_BUILD_TYPE=Debug ..        # Generates build files in debug mode
build $ cmake -DCMAKE_BUILD_TYPE=MinSizeRel ..   # Generates build files optimized for size

The default build type is Debug if the CMake project is a Git repository (contains a .git directory). Otherwise, it is set to RelWithDebInfo.

Best regards, 
Joakim

[nksharma]

Thanks for your reply Joakim,

But here, I meant to say, DEBUG option BOOTLOADER_DEBUG_ENABLE which is for RTT logging. 

Sorry for the confusion here. 

Now I used cmake command - cmake -DBUILD_BOOTLOADER=1 -DCMAKE_BUILD_TYPE=Debug ..

- This builds, but I can't see the RTT logs. I think this cmake command is for debugging using arm-gdb or something.

Also I used cmake command - 

cmake -DBUILD_BOOTLOADER=1 -DCMAKE_BUILD_TYPE=Debug -DBOOTLOADER_DEBUG_ENABLE=1 ..

- Still not linking. Giving me same error that I posted earlier.

My goal is to build mesh bootloader having already existing RTT logs statement in the bootloader enabled.

Am I missing anything which is needed to enable existing RTT logs of the mesh bootloader and link it successfully?

How do I build mesh bootloader with RTT logs enabled?

Regards,
Nishant.

[nksharma]

Hi Joakim,

I made the changes in the linker script of the bootloader. Then I compiled, it successfully got linked this time. Then I used the compiled mesh bootloader in two cases below -

A] Flashed softdevice, bootloader and the device page. That is no application :- In this case I was able to see the bootloader logs. I did DFU of blinky binary and it got DFUed and saw all logs.

B] Flashed softdevice, bootloader, DFU example given in mesh SDK and the device page :- In this case I see below logs of the application

<t: 1>, main.c, 206, ----- Bluetooth Mesh DFU Example -----
<t: 8739>, app_error_weak.c, 99, Application memory access: 1032690:0

So, something went wrong in this case. 

Also, the link given after below paragraph says - 

The bootloader is limited to 22 kilobytes flash and 768 bytes RAM. In addition to the 22 kilobytes flash, the bootloader reserves the two last pages of the flash. This means that the total size of the bootloader is 32 kilobytes for the nRF52-series and 24 kilobytes for the nRF51-series. The actual size of the bootloader depends on whether it is compiled with the serial (UART) transport in addition to toolchain and optimization settings.

Link : //infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v3.1.0%2Fmd_mesh_bootloader_README.html&cp=5_1_2_4_1

Here, we have increased the size of the mesh bootloader to get success in the linking process. It appears that by doing it, something has gone wrong and we get the fatal error in the dfu application.

Now the question is - 

Is there any way we can enable the logs of the mesh bootloader when it is with application(i.e Case B above) in the system?

If yes,

Then, what will be the side effects or the complications in the system? As the link above clearly states about the limitation of the mesh bootloader size.

Thanks,

Nishant.

[Joakim Jakobsen]

Hi again. 

Talked to our Mesh team today, and this is actually a known problem. 

This is caused by; when you add the application you'll get two sets of RTT-Logs. It's only the first set of logs that is detected, which in this case will be the application logs.
Also, the bootloader RTT memory is located in the same spot as something for the application. So when you have enabled logs of the bootloader, the logs isn't just not being detected by SEGGER, it's also messing with the applications memory. 

A way to avoid this, is by forcing the RTT-blocks for both the bootloader and the application to the same address using attributes. 

_acUpBuffer, _acDownBuffer and _SEGGER_RTT in segger_rtt.c must all to specific addresses in RAM. 
With armcc you can use the at()-attribute. 

Best regards, 
Joakim Jakobsen

[nksharma]

Thanks Joakim, it works now. Appreciate your support on this issue.

Regards,

Nishant.

[Joakim Jakobsen]

I'm glad to hear that it works.

Feel free to create a new support ticket if you have any more questions for us.  

Best regards, 
Joakim Jakobsen

[Tomlee]

Hi, 

May I know which file I can change ORGIN and LENGTH in ?

Quote"""

I think you should be able to fix this by making making a change in the bootloader. 

Change the following,  
From: 
   FLASH (rx) :           ORIGIN = 0xf8000, LENGTH = 0x6000

To: 
   FLASH (rx) :           ORIGIN = 0xf7000, LENGTH = 0x7000

Please let me know if you're still having issues. 

""""