Firmware on custom board (Application + Bootloader)

RE: Firmware on custom board (Application + Bootloader)

Edvin — Mon, 21 Oct 2019 13:22:12 GMT

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

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Mon, 21 Oct 2019 13:16:42 GMT

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?

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Mon, 21 Oct 2019 12:32:23 GMT

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

RE: Firmware on custom board (Application + Bootloader)

Edvin — Mon, 21 Oct 2019 11:56:37 GMT

My last question

[quote user="Edvin Holmseth"]Did you use the corresponding public and private key in the bootloader and bootloader settings, respectively?[/quote]

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.

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Fri, 18 Oct 2019 09:58:48 GMT

[quote userid="26071" url="~/f/nordic-q-a/51423/firmware-on-custom-board-application-bootloader/215637"]Did you use the corresponding public and private key in the bootloader and bootloader settings, respectively?[/quote]

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?

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Fri, 18 Oct 2019 09:26:54 GMT

I started with the pca10056_ble project. The only change I made was removing the dummy/default public_key.c and replacing with the one I generated using nrfutil
Below is the shell script I made to generate the bootloader settings:

---------- Settings ----------------#
device_family="NRF52840"
app_image_path="../production/images/application_v2.hex"
app_version="0"
bl_version="0"
bl_settings_version="1"
output_file="../production/images/bootloader_settings.hex"
#-----------------------------------#

#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 $output_file

(I am using the latest nrfutil version (5.2.0).

3. I followed the guide here: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader (steps A1 and A2) to generate the public and private keys.

What exactly do you mean in your last question?

RE: Firmware on custom board (Application + Bootloader)

Edvin — Fri, 18 Oct 2019 07:05:41 GMT

[quote user="TimA"]What I need now is for the bootloader to load the applicaton without having to do DFU/OTA update.[/quote]

I understand, but I am trying to rule out mistakes. Maybe you have not generated the keys correctly.

Let me try another way, then.

Have you done any changes to the bootloader project? What bootloader project did you start with? the pca10056_ble_debug or pca10056_ble?

What nrfutil command did you use to generate the bootloader settings?

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

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Thu, 17 Oct 2019 14:20:13 GMT

What I need now is for the bootloader to load the applicaton without having to do DFU/OTA update.

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

So I'm guessing my device is stuck in bootloader mode.

How can I force the bootloader to load the application?

Also, I read this line in nrf_bootloader_app_start.c:

uint32_t start_addr = MBR_SIZE; // Always boot from end of MBR. If a SoftDevice is present, it will boot the app.

"if a softdevice is present, it will boot the app." How do we ensure that either the MBR or softdevice boots the application?

Thanks

Tim

RE: Firmware on custom board (Application + Bootloader)

Edvin — Thu, 17 Oct 2019 12:52:18 GMT

[quote user="TimA"]It says the sSoftDevice size is 0 bytes! I find that a bit odd. What do you think?[/quote]

That should be fine. It says when I generate the bl_settings here as well.

Does the application start if you flash only the bootloader + SD, and then you upload the application via DFU using nRF Connect?

BR,

Edvin

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Thu, 17 Oct 2019 11:58:53 GMT

Well I think I almost figured it out. This tutorial was super helpful:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/adjustment-of-ram-and-flash-memory

I had to change the start address of the application and integrate the softdevice into my application.

I managed to merge all files successfully, but the application still does not start. I used nRF Connect to watch my new image like you illustrated above and it looks as expected, based on the memory map described here: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.2.0/lib_bootloader.html

devzone.nordicsemi.com/.../app_5F00_production_5F00_image.hex

(See the attached hex file).

Right now the softdevice is integrated in the application, but not initialized (as I mentioned in the beginning, we are not implementing any BLE features for now).

Any ideas on why the application still does not start?

Here are the contents of the bootloader settings:

Bootloader DFU Settings:
* File:                     ns_bootloader_setting.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0x48172AA9
* Settings Version:         0x00000001 (1)
* App Version:              0x00000000 (0)
* Bootloader Version:       0x00000000 (0)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x0001F688 (128648 bytes)
* Application CRC:          0x05F5197F
* 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)

It says the sSoftDevice size is 0 bytes! I find that a bit odd. What do you think?

Thanks

Tim

RE: Firmware on custom board (Application + Bootloader)

Edvin — Wed, 16 Oct 2019 08:03:26 GMT

Hello Tim,

Your app.hex looks a bit strange.

Does your app use the softdevice?

The app.hex, does that come from when you compiled the application, or did you do a flash dump after programming it? The reason I ask is that when I watch your app.hex with nRF Connect -> Programmer it looks like this:

So the application has not put aside any space for the softdevice, which should be on the bottom/start. In addition, there is something in the top/end of the flash. what is that?

Does your application work if you program only app.hex and softdevice? It probably will not, because it doesn't have space for the flash, but what I mean is that it will not work to merge them if you can't flash both simultaneously.

So basically, you need to make your application work while you set aside space for the softdevice. Please refer to one of the ble_peripheral examples and the flash settings. If you are unsure on how to do that, please let me know what IDE you use, and I can give you some pointers.

BR,

Edvin

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Tue, 15 Oct 2019 12:38:06 GMT

Alright, so I tried merging in this order:

Bootloader and bootloader settings => OK
Merged bootloader and Application => OK
Application (+Bootloader +Settings) and Softdevice => FAIL

1. Do I have to change the start address of any of the components, or is this handled by the mergehex utility?

2. Is the merge order relevant?

3. My application currently doesn't include the SoftDevice. For now it's a completely "bluetooth-less" application. Could this be an issue?

Here are my hex files:

devzone.nordicsemi.com/.../app.hex

devzone.nordicsemi.com/.../7043.bootloader_5F00_settings.hex

devzone.nordicsemi.com/.../secure_5F00_ble_5F00_s140_5F00_bootloader.hex

devzone.nordicsemi.com/.../s140_5F00_nrf52_5F00_6.1.0_5F00_softdevice.hex

Thanks

Tim

RE: Firmware on custom board (Application + Bootloader)

Edvin — Mon, 14 Oct 2019 14:51:00 GMT

The conflicts are probably because you try to merge MBR and the softdevice. The MBR is already included in the Softdevice, so you don't need both.

Try to merge the softdevice, application and bootloader (+Settings). There shouldn't be any conflicting areas there.

BR,

Edvin

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Mon, 14 Oct 2019 11:13:29 GMT

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

Could I also just merge the MBR with the image and flash the output image as a single hex file?
Do these hex images need to be merged in any particular order?
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 🙂
Thanks

Tim

RE: Firmware on custom board (Application + Bootloader)

Edvin — Fri, 20 Sep 2019 13:32:51 GMT

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.

[quote user="TimA"]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)[/quote]

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.

[quote user="TimA"]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?[/quote]

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

RE: Firmware on custom board (Application + Bootloader)

mrono — Fri, 20 Sep 2019 13:03:49 GMT

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.

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Fri, 20 Sep 2019 11:21:14 GMT

Hello Edvin,

I've been able to do the following

Build a debug image of my application, flashed the custom board and works as expected.
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):

Generate private key
Compile the uecc library
Build the bootloader
Generate the bootloader settings hex
Merge the built bootloader and settings using nrfutil (lets call the output device_bl.hex)
Merged device_bl.hex and my application hex (release version)
Flashed the device using nrfjprog. Nothing happens.
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

RE: Firmware on custom board (Application + Bootloader)

Edvin — Wed, 28 Aug 2019 11:57:59 GMT

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

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Wed, 28 Aug 2019 08:10:41 GMT

I had assumed that a custom board could be flashed with the final image (application + bootloader) using Segger Flasher, a 10 pin needle adapter, and the nrfjprog utility - this setup facilitates batch programming at the factory.
I just discovered the mergehex utility.

would this be fine to combine the application and bootloader, and then program a device using the setup above?
Can you confirm that this is not possible? If this is the case, can you suggest a way (if possible) to use the DFU utility to batch program devices?
This guide mentions that the bootloader can be flashed directly. Where exactly in the SDK is the bootloader image located (I'm using SDK 15.2.0)?

Thanks

Tim

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Tue, 27 Aug 2019 08:38:06 GMT

Great! Thanks. I'll get back to you in a few days.

RE: Firmware on custom board (Application + Bootloader)

Edvin — Tue, 27 Aug 2019 08:33:09 GMT

The difference between the serial and ble bootloader is that the serial bootloader uses UART instead of BLE to transfer the images.

Serial bootloader is located in: SDK15.2.0\examples\dfu\secure_bootloader\pca10056_uart

BLE bootloader is located in: SDK15.2.0\examples\dfu\secure_bootloader\pca10056_ble

I would still recommend to test the ble bootloader, which you can do on a DK in the meantime while you work on the antenna.

However, if you want to test the serial bootloader, you can do that as well. In that case, it is a quite similar approach.

You can start off by using nrfutil (which is also linked in the getting started guide) to create the images and perform the serial DFU.

The nrfutil tool has a "guide" you can access by typing "nrfutil --help" after you have installed it and added it to your environment path. There is also a list over useful commands here, such as how to perform the serial DFU.

Best regards,

Edvin

RE: Firmware on custom board (Application + Bootloader)

Tim Adu — Tue, 27 Aug 2019 08:18:33 GMT

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

RE: Firmware on custom board (Application + Bootloader)

Edvin — Tue, 27 Aug 2019 08:05:52 GMT

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