few questions about bootloader settings

[ziv123]

hello Nordic

i am working with nrf52832 soc with SDK 16.0, S132 V7.0.1

following this path:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

and this : https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrfutil%2FUG%2Fnrfutil%2Fnrfutil_settings_generate_display.html

1. when trying to read current setting of existing bootloader in the examples i get this:

C:\Nordik SDK\examples\dfu\secure_bootloader>nrfutil settings display pca10040_uart\ses\Output\Release\Exe\secure_bootloader_uart_mbr_pca10040.hex
Bad access at 0x7F000: not enough data to read 4 contiguous bytes
Usage: nrfutil settings display [OPTIONS] HEX_FILE

Error: Failed to parse .hex file: Bad access at 0xFF000: not enough data to read 4 contiguous bytes

why is that ?

2. if i generate a setting for the bootloader and i include the softdevice in the "nrf settings generate command (like so:  --softdevice FILE s132_nrf52_7.0.1_softdevice.hex)

do i still need to mergehex the bootloader with the s132 hex file ? considering that when i flash my application (using SEGGER) after erasing the nrf52832 i do not need to flash the softdevice separately

3. the settings generate command refers to application version, do i need to change the setting each time i change application version or it's name (considering the version is in the name) ?

4. if i mergehex the bootloader settings hex file with the bootloader hex file and i flash the bootloader without having an application flashed on the device, what will happen ? would i be able to flash the application via SEGGER normally or must i have the application hex flashed before the flashing of the bootloader or mergehex with the bootloader ?

that it for now

p.s. 5. in the dfu examples, what's the difference between pca10040_uart to pca10040_uart_debug can both be used for production also can they be used for a PCB not an nrf52832DK ? 

hope to read from you soon

best regards

Ziv

 

[Einar Thorsrud]

Hi Ziv,

1. when trying to read current setting of existing bootloader in the examples i get this:

The bootloader settings page is not part of the hex file you get when you build the bootloader. This is why parsing it with nrfutil fails (as expected).

2. if i generate a setting for the bootloader and i include the softdevice in the "nrf settings generate command (like so:  --softdevice FILE s132_nrf52_7.0.1_softdevice.hex)

do i still need to mergehex the bootloader with the s132 hex file ? considering that when i flash my application (using SEGGER) after erasing the nrf52832 i do not need to flash the softdevice separately

Yes you still need to merge all hex files you want to program, including the bootloader settings page.

3. the settings generate command refers to application version, do i need to change the setting each time i change application version or it's name (considering the version is in the name) ?

The application version and bootloader version needs to be incremented each time you make a new version. This is because the bootloader prevents downgrades and (optionally) also prevents upgrading to the same version. It is the number (integer) that matters here, the string is more for user-friendliness.

4. if i mergehex the bootloader settings hex file with the bootloader hex file and i flash the bootloader without having an application flashed on the device, what will happen ? would i be able to flash the application via SEGGER normally or must i have the application hex flashed before the flashing of the bootloader or mergehex with the bootloader ?

If the application is not present, the bootloader will enter DFU mode. If you subsequently flash the application and this is the exact application hex that was used to generate the hex file, the app will be started. If the application has changes in any way, the bootloader will not be able to validate the application (as the CRC has changed), and the bootloader will enter DFU mode.

p.s. 5. in the dfu examples, what's the difference between pca10040_uart to pca10040_uart_debug can both be used for production also can they be used for a PCB not an nrf52832DK ? 

Both can be used for custom HW as well as for the DK. The debug version includes RTT logging, which increases the size of the bootloader. It is only usable from a debugger.

Regarding using it for release you can do it, though it often does not make sense as you will typically not have RTT access in the field anyway. If you do it, you should do some adaptations. For instance, the error handler behaves differently depending on the build type:

static void on_error(void)
{
    NRF_LOG_FINAL_FLUSH();

#if NRF_MODULE_ENABLED(NRF_LOG_BACKEND_RTT)
    // To allow the buffer to be flushed by the host.
    nrf_delay_ms(100);
#endif
#ifdef NRF_DFU_DEBUG_VERSION
    NRF_BREAKPOINT_COND;
#endif
    NVIC_SystemReset();
}

Einar

[ziv123]

Einar Thorsrud said:

The application version and bootloader version needs to be incremented each time you make a new version. This is because the bootloader prevents downgrades and (optionally) also prevents upgrading to the same version. It is the number (integer) that matters here, the string is more for user-friendliness.

i think i am missing something.. one of the reasons as i see it to create a bootloader setting file is so i can have a bootloader on my board and still be able to flash some changes to the application via SEGGER. since i am still on development stage it will take to long to do a whole DFU procedure every time i want to check a motor speed or any other small change.

if i understood you correct then i will have to create a new bootloader setting file, merge it with bootloader, softdevice and application each time i want to make even a small change. so how does it save me time and effort 

1. is there is some other simpler way to achieve that? or is there a way to do this automatically with SEGGER 

2. when some products our out on the market, what if i want to return to a previous version if i found some problem with the new release, but the bootloader wont allow downgrading ?

hope to read from you soon

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

ziv123 said:

1. is there is some other simpler way to achieve that? or is there a way to do this automatically with SEGGER 

There are several ways to handle this while developing. One is to always generate and flash the bootlaoder settings page when progaramming, but that is tedious even if you could script it. Easier (and better imho) options are to either develop without a bootlaoder present, or modify the bootloader slightly to ignore the CRC and use this bootloader while developing. The latter can be done for instance by making app_is_valid() always return true in components\libraries\bootloader\nrf_bootloader.c.

ziv123 said:

2. when some products our out on the market, what if i want to return to a previous version if i found some problem with the new release, but the bootloader wont allow downgrading ?

In most cases you want to prevent downgrading because of security reasons (for instance you push a update to fix a security issue, and then you do not want an attacker to be able to first downgrade and then exploits the issue). If you really want to support a specific downgrade, you can issue a new upgrade package with the old firmware, but where you use a higher revision number when you generate the zip package using nrfutil. If you do not want downgrade protection at all this can be disabled by setting NRF_DFU_APP_DOWNGRADE_PREVENTION to 0 in the bootloader's sdk_config.h.

Einar

[ziv123]

Hey Einar

few more questions

1. if i merge bootloader hex with bl settings hex, with softdevice hex and application hex all together on one mergehex command (if it is possible ?), then if i flash the final merged hex to a pre-erased device, the app should work correct ?  

is there something more to it ?

p.s. i am using secured bootloader and my dfu is via serial (don't think it matters though, but again correct me if i am wrong)

2. can i copy the uECC compiled file to a different library of nrf5_sdk/external... (i copy sdk libraries for each project for git comfort) or must i recompile it in the new location ?

3. i generate a pkg this way

nrfutil pkg generate --application Output\Pca10040_Debug\Exe\Redent_Nova.hex --application-version 0 --hw-version 52 --sd-req 0xCB --key-file bootloader\src\private.key Redent_00.zip

and i get this error (this is before creating a bootloader setting file and merging it with the bootloader but just using the bootloader as is in the example given at:

examples\dfu\secure_bootloader\pca10040_uart\ses )

and i get this error when trying to preform dfu:

raise NordicSemiException('Extended Error 0x{:02X}: {}'.format(resp[3], data))
pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x07: The array of supported SoftDevices for the update does not contain the FWID of the current SoftDevice.

why is that, what am i doing wrong ? 

4. if i use the pkg generat command which specify the softdevice do i still need to merge the softdevice hex with the application hex and give the merged hex to the pkg generate command ?, or does the nrfutil pkg generate command does it for me ?

hope to read from you soon

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

ziv123 said:

1. if i merge bootloader hex with bl settings hex, with softdevice hex and application hex all together on one mergehex command (if it is possible ?), then if i flash the final merged hex to a pre-erased device, the app should work correct ?  

Yes, this is possible and is typically how you do this. (Note that you can also merge in several steps without any issues, and that was required as older mergehex versions did not support merging many files in one go. The end result will be the same.)

ziv123 said:

p.s. i am using secured bootloader and my dfu is via serial (don't think it matters though, but again correct me if i am wrong)

This is the same regardless for all nRF5 SDK bootloader variants.

ziv123 said:

2. can i copy the uECC compiled file to a different library of nrf5_sdk/external... (i copy sdk libraries for each project for git comfort) or must i recompile it in the new location ?

You can move the binary library as you like. It does not matter where it is as long as you update your project with the new location.

ziv123 said:

why is that, what am i doing wrong ? 

 The error "The array of supported SoftDevices for the update does not contain the FWID of the current SoftDevice." means that the SoftDevice currently programmed on the device does not match the ID you specified with --sd-req (0xCB which is S132 7.0.1). Have you flashed the SoftDevice to the device before this point?

Einar

[ziv123]

Einar Thorsrud said:

Have you flashed the SoftDevice to the device before this point?

usually i erase the device before start, hence my question :

ziv123 said:

if i use the pkg generat command which specify the softdevice do i still need to merge the softdevice hex with the application hex and give the merged hex to the pkg generate command ?, or does the nrfutil pkg generate command does it for me ?

to continue with this question, should i merge the softdevice hex with the bootloader hex in that case and flash the merged hex and then use the nrfutil dfu with the generated pkg zip ?

and one more thing, creating a bootloader setting hex is essential only when i want to flash the whole bl, sofdevice and app in one hex correct ?

[Einar Thorsrud]

Ah, I missed the last question.

No. You can never provided merged hex files to nrfutil when generating a zip package for DFU upgrades. So the bootloader, application and SoftDevice must be provided as separate hex files with separate options associated with them. If you only want to upgrade the application via DFU, you only provide the application, etc.

However, in order to support serial DFU of the application, you must at the very least have programmed the MBR and bootloader. In practice you will program both the SoftDevice (which includes the MBR), bootloader, application and BL settings hex initially, and can then update anything you need via DFU after that.

ziv123 said:

and one more thing, creating a bootloader setting hex is essential only when i want to flash the whole bl, sofdevice and app in one hex correct ?

It is primarily needed when you program the application via a debugger and not DFU. If you do via a debugger, there is no way for the bootloader to know about the application and it's checksum without you generating and programming the settings page.

[ziv123]

not sure i understood it all 

1. if i understand correctly, i don't always have to use the bl settings hex, but just when i want to flash it all together? or i can flash the bootloader, softdevice and app in one merged hex file without bl setting at all and it should work as well, correct ?

 2. if i am not doing it in one file, then when i take an erased device, i first flash the softdevice hex, then the bootloader hex and then i can flash the app and it should work ?

or the app at this stage (without bl setting) can only be given via dfu  ? 

3. if first i flash the softdevice and the app and then flash the bootloader then the app should work correct ?

4. having a bootloader with bl setting and softdevice on the device enables me to flash the application via segger ide, or i need to change the bl setting with every change that i make to the app ?

5. when using segger ide to flash an app on an erased device, there is no need to flash the softdevice separately, so i guess it is doing it by itself, how does it work when wanting to use segger to flash app when a bootloader is on the device ?

6. if i want to update only the softdevice (though i guess app will also require an update in that case) via dfu then in the packet generate command i put write: 

" ... --application softdevice.hex --application-version 7.01 (in case of s132 v7.01) ... " ??

sorry for being a little tidies but i am trying to understand it fully and be able to repeat and understand when things don't work as expected 

one more thing: when trying to dfu i get this error:

\dfu_transport_serial.py", line 214, in open
    raise NordicSemiException("No ping response after opening COM port")
pc_ble_driver_py.exceptions.NordicSemiException: No ping response after opening COM port

does it mean something with the bootloader is not working as it should or is it something to do with the physical connection ?