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

bootload flush and flushing address rodata too large to fit flash memory

hello Nordic

i am using nrf52832, sdk 16.0 s132 v7.0.1

i used the secure_uart_bootload example, the start flash in the example starts at 64000, though in this link the memory layout looks different (should start at 78000)

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_bootloader.html&anchor=lib_bootloader_memory

when i flashed the bootload with the dsk default configs then my app would not run at all. 

when i tried to change the start address to 78000 i got a compilation error of the bootloader saying 'rodata is too large to fit FLASH memory'

how can i know how much space the bootloader will need to update my app, also how much space my app will take .. also in RAM ??

(my app is build on the central bla_app_blinky example)

hope to read from you soon 

 best regards

Ziv

Parents
  • Hello Ziv,

    I just flashed the unmodified uart bootloader for nRF52832 from SDK 16, and this is what it looks like. Screenshot from nRF Connect for Desktop -> Programmer:

    It starts at 0x0007 8000.

    Are you sure it starts at 0x64000? If so, what changes did you initally do? What compiler did you use? Can you please try with an unmodified SDK?

  • one more question:

    after i flashed the bootloader can i flash a new application via segger debuger or once the bootloader is flashed the program can only be updated via the bootloader ??

    best regards

    Ziv

  • ziv123 said:
    or once the bootloader is flashed the program can only be updated via the bootloader ??

     Almost.

    It is a secure bootloader, meaning it will check the CRC of the application. If the CRC doesn't match the signed init file from the DFU update, it will reject the application, and run into DFU mode. This is why you can't flash the application via SES after you program the bootloader. 

    Usually you would set an application flash address in the start of the flash, and as you expand your project, the application's flash size increases, and grows in flash size. That is not a problem, since you set the flash address at the start of the flash (or directly after the bootloader). However, the bootloader is placed at the end of the flash (to not take up valuable space from the application). This means that if you expand the project (bootloader in this case) it will grow outside the flash, so you would need to adjust the start address for the bootloader. This is the main difference between the _debug and normal bootloader projects. The start address is further down, and logging is enabled (since the log module requires a bit more flash). 

    Back to the application issue. There are two ways of setting the bootloader settings (which is the part that holds the CRC). You can either program the application via a DFU. This is a bit tedious, since it takes some time, and you need to do it every time you recompile the application.

    What you can do is to generate bootloader settings using "nrfutil settings generate ..." (nrfutil settings generate --help for hints). This will generate a .hex file that you can program together with the application, and the application should start. 

    Please note that if you start a debug session in SES, then it will flash the application from your .elf file, which is not identical to the .hex file that you would use to generate the DFU image. So if you want to run a debug session, you should use Attach debugger:

    Which will not flash anything, but just assume that the correct application is flashed. 

    So revert the changes you did to the flash settings in the bootloader, unless you for some reason need to change it, because you added something to the bootloader. If so, let me know. It is not trivial in SES.

    BR,

    Edvin

Reply
  • ziv123 said:
    or once the bootloader is flashed the program can only be updated via the bootloader ??

     Almost.

    It is a secure bootloader, meaning it will check the CRC of the application. If the CRC doesn't match the signed init file from the DFU update, it will reject the application, and run into DFU mode. This is why you can't flash the application via SES after you program the bootloader. 

    Usually you would set an application flash address in the start of the flash, and as you expand your project, the application's flash size increases, and grows in flash size. That is not a problem, since you set the flash address at the start of the flash (or directly after the bootloader). However, the bootloader is placed at the end of the flash (to not take up valuable space from the application). This means that if you expand the project (bootloader in this case) it will grow outside the flash, so you would need to adjust the start address for the bootloader. This is the main difference between the _debug and normal bootloader projects. The start address is further down, and logging is enabled (since the log module requires a bit more flash). 

    Back to the application issue. There are two ways of setting the bootloader settings (which is the part that holds the CRC). You can either program the application via a DFU. This is a bit tedious, since it takes some time, and you need to do it every time you recompile the application.

    What you can do is to generate bootloader settings using "nrfutil settings generate ..." (nrfutil settings generate --help for hints). This will generate a .hex file that you can program together with the application, and the application should start. 

    Please note that if you start a debug session in SES, then it will flash the application from your .elf file, which is not identical to the .hex file that you would use to generate the DFU image. So if you want to run a debug session, you should use Attach debugger:

    Which will not flash anything, but just assume that the correct application is flashed. 

    So revert the changes you did to the flash settings in the bootloader, unless you for some reason need to change it, because you added something to the bootloader. If so, let me know. It is not trivial in SES.

    BR,

    Edvin

Children
No Data
Related