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

Firmware on custom board (Application + Bootloader)

I've reached a critical point in the firmware development process where I need to start considering integrating a bootloader with the application code.

I have a custom board with an nrf52840 SoC. I have created a new bsp for the board and I'm able to execute code and run debugging on the board using Segger Embedded Studio. At some point, we'll have to integrate a bootloader in order to be able to create a release image.

Based on the requirements at my company, it has been decided to implement the application in two phases:

  • Phase 1 will include the application and bootloader
  • Phase 2 will include the application, bootloader and softdevice, once the BLE-related requirements have been locked.

I wish to implement phase 1 and as this is critical, I do not wish to get fragmented information.

My questions

  1.  Are there any ready-made bootloaders I can use?
  2. How do I go about combining the application and bootloader (without softdevice)
  3. How do I fragment the flash memory so that I can have the application, bootloader, and eventually softdevice?
  4. Are there any detailed tutorials explaining the integration processes?
  5. Eventually we'll implement FOTA over Bluetooth. Anything I should be specially aware of here?

Any link to documentation/tutorials will be very much appreciated. I apologize in advance if the questions seem a bit broad. I'm a bit new to this process of integrating application code and bootloaders.

Thanks,

/Tim

  • 1: Yes. You can merge the hex files and program them in one chunk, but it is also possible to program them separately. Note that the bootloader has a CRC check, so unless you program the bootloader settings generated with the correct application and private key, the bootloader will reject the application, and stay in bootloader mode.

    2: If you mean to use .bat scripts to program using nrfjprog and/or update the firmware via DFU using nrfutil, then yes. It is possible. (I usually do this to test DFU stuff).

    3: There are some precompiled bootloaders located in:

    SDK15.2.0\examples\dfu\secure_dfu_test_images.

    However, I really (!) recommend you to compile your own bootloaders with your own keys generated the way that is described in the tutorial that I linked to in the first reply.

    The reason for this is that I am not sure what sort of keys or bootloader's that are compiled in the precompiled .hex files and .zip files.

    The bat scripts that I usually use to test looks something like this:

    REM nrfutil keys generate private.key
    REM nrfutil keys display --key pk private.key --format code --out_file public_key.c
    
    nrfjprog -e --snr 123456789
    nrfjprog --program softdevice.hex --snr 123456789
    nrfjprog --program bootloader.hex --snr 123456789
    nrfjprog --reset --snr 123456789
    
    nrfutil pkg generate --application application.hex --application-version 1 --hw-version 52 --sd-req 0xB6 --key-file private.key dfu_test_image.hex
    
    nrfutil dfu serial -pkg dfu_test_image.zip -p COM4 -snr 123456789 -b 115200

    Just change the serial numbers after --snr or -snr to match the serial number of your debugger (or on the DK).

    Also, you need to use the correct names for the softdevice hex file, the bootloader.hex is the .hex file from bootloader that you compiled, the application is the hex file for an application that you want to flash, and so on...

    Best regards,

    Edvin

  • Hello Edvin,

    I've been able to do  the following

    1. Build a debug image of my application, flashed the custom board and works as expected.
    2. Build a release image, flashed the board (just to see what happens). Nothing happens

    (1) and (2) are done from within Segger Embedded Studio. Are there any settings to be aware of when building a release configuration?

    As for the bootloader generation, I managed to (in this exact sequence):

    1. Generate private key
    2. Compile the uecc library
    3. Build the bootloader
    4. Generate the bootloader settings hex
    5. Merge the built bootloader and settings using nrfutil (lets call the output device_bl.hex)
    6. Merged device_bl.hex and my application hex (release version)
    7. Flashed the device using nrfjprog. Nothing happens.
    8. Repeated (1) to (7) with a debug build image. Nothing happens

    Questions:

    • How do I debug this? (I need to generate an image that can be flashed at the factory, so it cannot be a dfu package)
    • When flashing the device, should it be done in stages (bootloader first, and then application), or can I merge the bootloader and application into a single image and flash that instead?

    My setup

    • Segger Embedded Studio v4.22
    • SDK 15.2.0
    • Secure ble dfu bootloader project used

    Thanks

    Tim

  • In step 6 you should also include the softdevice hex file. Then you should have a complete image that can be flashed in one go.

  • Hello,

    You can merge all the hex files and program them in one go. That shouldn't be a problem.

    Are you still working on the serial bootloader? Again, I have to say that if you intend to use the BLE bootloader in the end, it is easier to work with the BLE bootloader. If anything, it will advertise as "DfuTarg" if there is something wrong with the bootloader settings, so you should know that something is working.

    If you don't use the softdevice in your bootloader, you still need the MBR. It is found in SDK\components\softdevice\mbr\nrf52840\hex\mbr_nrf52_2.4.1_mbr.hex.

    merge this with your bootloader.

     

    Tim Adu said:
    How do I debug this? (I need to generate an image that can be flashed at the factory, so it cannot be a dfu package)

     It is a bit tricky to debug the bootloader project, because turning off optimization makes the project too big for the size limit of the flash area (since the bootloader is placed near the end of the flash, unlike a normal application that will typically start at the start of flash.

     

    Tim Adu said:
    When flashing the device, should it be done in stages (bootloader first, and then application), or can I merge the bootloader and application into a single image and flash that instead?

     That is not a problem. You should be able to merge everything and flashing it as one .hex file. Remember to reset the device after it is programmed. Either power cycle it, or run "nrfjprog --reset".

    If you need to debug, then you must use the project that is called ..._debug, e.g. the SDK\examples\dfu\secure_bootloader\pca10056_ble_debug. This bootloader takes up a bit more space, and is placed a bit further down in the flash, so there is room for both debugging (step through without optimization turned on) and logging. 

    If you generated the dfu image with the same key as you used in your bootloader (private_key->image, public_key->bootloader project), then it should jump to the application if these are programmed:

    MBR or softdevice
    Application
    Bootloader
    Bootloader settings.

    I suspect that you were missing the MBR. Try to program that as well and see if the application starts up.

    Best regards,

    Edvin

  • Alright. I finally have time to do this. I'm dedicating this week to get this to work.
    Thanks for your previous reply.

    1. Could I also just merge the MBR with the image and flash the output image as a single hex file?
    2. Do these hex images need to be merged in any particular order?
    3. When I try merging the Bootloader (+settings), Application, MBR and Softdevice, I get an error - "the hex file cannot be merged since there are conflicts". How can I determine the conflict source?

    And FYI, I'm going for the BLE bootloader Slight smile
    Thanks

    Tim

Related