Firmware on custom board (Application + Bootloader)

[Tim Adu]

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

[Edvin]

Hello Tim,

1: Yes, there is a bootloader in the SDK. I don't know what SDK version you use (which one is it?)

2: It is possible if you use the serial bootloader, but my impression is that the bootloader that uses BLE to transfer the application is the most used. If so, I would recommend going directly to phase 2.

3: The bootloader will take care of this. You can use a tool called nrfutil to create the DFU(/FOTA) images, and there you will set what the image contains (Bootloader, softdevice or application (or a combination).

4: Yes. Check out this tutorial, which will explain how to use the BLE bootloader. It is written for a fairly old SDK version (12.0.0), but you should be able to follow it using the latest SDK (SDK15.3.0) as well.

5: As mentioned, I suggest that you do this directly. The blogpost in the link above will take you through this.

I hope that clears up some of your questions. I suggest that you walk through the guide from the link (without your application, just use the examples from the SDK to get familiar with it), and then try to combine it with the example found in:

SDK\examples\ble_peripheral\ble_app_buttonless_dfu

And then move to including this in your application.

Let me know if you are stuck somewhere in the testing.

Best regards,

Edvin

[Tim Adu]

Thanks Edvin,

• I use SDK 15.2.0
• A little bit about your response in (2) - you mentioned a serial bootloader. How does this work? I'll have to use this for now, as we are working on optimizing the Bluetooth antenna for phase 2, which is why we split into two phases. Could you elaborate a bit on the serial bootloader.

Thanks for the links and response. I'll check them out and reply in a few days,

/Tim

[Tim Adu]

Edvin said:

Did you use the corresponding public and private key in the bootloader and bootloader settings, respectively?

Okay.. I think I see what you are referring to there. I just saw in the nrfutil settings generate help text that there is an option of validating the boot using the private key. Is that what you mean?

If that's the case, then this was completely omitted from the tutorials. Can you describe exactly the syntax then for validating using the private key?

[Edvin]

My last question

Edvin said:

Did you use the corresponding public and private key in the bootloader and bootloader settings, respectively?

 You don't use your key to sign off the application image when you create your bootloader settings? Can you try to add the following:

"--key-file private.key" before $output_file

That should create the correct signature for your file, so that the bootloader will accept the application if you flash it together with the BL + SD + app + BL_settings.

Yes, unfortunately, the bootloader settings is not part of the guide. 

[Tim Adu]

I tried it. It didn't work. My updated script:

#---------- Settings ----------------#
device_family="NRF52840"
app_image_path="../path_to_production_app_hex/application.hex"
app_version="0"
bl_version="0"
bl_settings_version="1"
key_file="../path_to_generated_keys/private.key"
output_file="../path_to_store_generated_bl_settings/bootloader_settings.hex"
softdevice_file="../path_to_softdevice_image/s140_nrf52_6.1.0_softdevice.hex"
#-----------------------------------#

echo "---------------------------------------------------------------"

#Delete any existing bootloader settings image
rm -f $output_file
nrfutil settings generate --family $device_family --application $app_image_path --application-version $app_version --bootloader-version $bl_version --bl-settings-version $bl_settings_version --softdevice $softdevice_file --key-file $key_file $output_file

I read a thread with a similar problem: https://devzone.nordicsemi.com/f/nordic-q-a/19068/uploading-application-and-bootloader-application-not-starting.

Is  there maybe an equivalent way to do it in SDK 15.2.0

[Tim Adu]

Also, do you think this is a bit odd: I generate the bootloader settings, read it out immediately, and the start address is different, plus I get a warning message: Bad access at 0x7F000: not enough data to read 4 contiguous bytes:

Generated Bootloader DFU settings .hex file and stored it in: ../production/images/ns_wms_bootloader_settings.hex

Bootloader DFU Settings:
* File:                     ../production/images/ns_wms_bootloader_settings.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0x390CDFC7
* Settings Version:         0x00000001 (1)
* App Version:              0x00000000 (0)
* Bootloader Version:       0x00000000 (0)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x0002AD34 (175412 bytes)
* Application CRC:          0x2D2EC708
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00024E7C (151164 bytes)
* Boot Validation CRC:      0x00000000
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

Bad access at 0x7F000: not enough data to read 4 contiguous bytes

Bootloader DFU Settings:
* File:                     ../production/images/ns_wms_bootloader_settings.hex
* Family:                   NRF52840
* Start Address:            0x000FE000
* CRC:                      0x390CDFC7
* Settings Version:         0x00000001 (1)
* App Version:              0x00000000 (0)
* Bootloader Version:       0x00000000 (0)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x0002AD34 (175412 bytes)
* Application CRC:          0x2D2EC708
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x00000000
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

Any thoughts about this?

[Edvin]

I believe this post has become a duplicate of your latest ticket:

https://devzone.nordicsemi.com/f/nordic-q-a/53464/generating-production-image-without-dfu-ota

Let us follow up in that thread, and give me a detailed explanation on how you determine that "it doesn't work", and what it says when you program the different parts (BL, SD, BL_settings, application).

BR,

Edvin