This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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.

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.

Parents
  • 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

  • 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.

  • Hi again. 

    My bad. I think i misunderstood the question. 

    /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

    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. 

    Best regards,
    Joakim. 

  • 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.

Reply
  • 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.

Children
Related