• State Verified Answer
  • Replies 4 replies
  • Subscribers 89 subscribers
  • Views 1114 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 260440
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

custom bootloader and s132

snooooopy

Hi everybody, thanks for your time.

I try to develop an iot board with FOTA.  To do so, I have a custom bootloader (address 0x00000000 in flash ) who perform the following task:

- Update multiple CPU via a CAN BUS

- Ensure the running software is signed by server before running it.

- Ensure integrity of the running software.



I’m actually trying to implement the bluethoot stack and encounter the following problem.

S132 library seems to be forced at address 0x000000.


So I’m asking following questions:

- Is it possible to move S132 library to an other location? (I guess no, but that would be greatly appreciated).

- I read that if you keep the same version of the lib it will always use the same amount of Flash/ram. Is this assumption correct?

- Is there already a way to ensure the library is signed before executing it?

- Does the library launch somethings before launching the software is it just a passive jump?

have a nice day anyway.

Parents
  • +1

    Hi Snoooooooooooooopy, 

    - S132 uses absolute address so it can't be re-located to other location from the designed place (starts right after the MBR (0x1000), which can be consider part of the softdevice and the MBR starts at address 0x0000000) 

    - If you don't change the version (minor version and major version) the flash requirement of the softdevice unchange. But the RAM requirement is depends on the application configuration (for example how many services, characteristics, size of characteristics etc) will affect the RAM requirement for the softdevice. 

    - You meant to ensure the softdevice is signed before executing ? Yes you can develop that in your bootloader. We also have that implemented in our bootloader in SDK v17. You can have a look here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/lib_secure_boot.html?cp=7_1_3_5_0_8_1_2#secure_boot_mode_selection

    - You can read more about booting process in the documentation page above. The MBR starts first, then the bootloader, then the softdevice and then the application. The softdevice when initialized will handle the interrupts and only forward those interrupts available for the application to the application. 

    If you are developing your own bootloader, I would suggest to locate it to the bottom of the flash, the same way as our bootloader in nRF5 SDK. The MBR when detecting a bootloader (an address in MBR page) will jump to the bootloader instead of executing the softdevice. 

Reply
  • +1

    Hi Snoooooooooooooopy, 

    - S132 uses absolute address so it can't be re-located to other location from the designed place (starts right after the MBR (0x1000), which can be consider part of the softdevice and the MBR starts at address 0x0000000) 

    - If you don't change the version (minor version and major version) the flash requirement of the softdevice unchange. But the RAM requirement is depends on the application configuration (for example how many services, characteristics, size of characteristics etc) will affect the RAM requirement for the softdevice. 

    - You meant to ensure the softdevice is signed before executing ? Yes you can develop that in your bootloader. We also have that implemented in our bootloader in SDK v17. You can have a look here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/lib_secure_boot.html?cp=7_1_3_5_0_8_1_2#secure_boot_mode_selection

    - You can read more about booting process in the documentation page above. The MBR starts first, then the bootloader, then the softdevice and then the application. The softdevice when initialized will handle the interrupts and only forward those interrupts available for the application to the application. 

    If you are developing your own bootloader, I would suggest to locate it to the bottom of the flash, the same way as our bootloader in nRF5 SDK. The MBR when detecting a bootloader (an address in MBR page) will jump to the bootloader instead of executing the softdevice. 

Children
  • 0 in reply to Hung Bui

    Thank you for your time! This answere all my question.

  • 0 in reply to Hung Bui
    Hung Bui said:
    If you are developing your own bootloader, I would suggest to locate it to the bottom of the flash, the same way as our bootloader in nRF5 SDK. The MBR when detecting a bootloader (an address in MBR page) will jump to the bootloader instead of executing the softdevice. 

    So , something I am not catching by reading the Bootloader and DFU modules sections of the Infocenter, is the MBR.
    If I may add, my additional questions here:
    The mbr is a fixed .hex file in the SDK , called      mbr_nrf52_2.4.1_mbr.hex , we don't make this file , anywhere , is that correct? This file has no source or project?

    From the open_bootloader makefile it appears I need to load this file loaded as well as the boot loader hex.
    So it it standard to just use this file?

     

  • 0 in reply to AMarch

    Hi Anthony, 

    Yes you are correct. It's a standard to use this file if  you plan to use our bootloader or softdevice. The MBR is included inside the softdevice. So in any application that you flash the softdevice the MBR is also flashed. 
    We don't provide MBR source code, the only purpose of the MBR is to support bootloader functionality and does interrupt vector forwarding. 

Related
Terms of service