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

[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 ?

[Einar Thorsrud]

Hi,

ziv123 said:

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 ?

Let me explain in more detail what the bootloader settings hex file is. The bootloader has a settings page, which is the last page in flash. That is used for storing the state of the system in a wide sense. Most importantly for this discussion, bootloader settings include a flag that indicates if an application is present or not and a checksum (or cryptographic hash or signature depending on configuration) of the application so that the bootloader can check it's integrity.

When the bootloader runs at every boot it checks if it should enter DFU mode, based on a number of factors. One of these is that it will always enter DFU mode instead of try to start the application if there is no flag indicating that an application is present and/or the checksum of the application does not match the checksum in the settings page. So if you do not program a valid bootloader settings page the bootloader will always enter DFU mode instead of starting the application.

Note that when upgrading via DFU, the bootloader will update the bootloader settings page, as it gets the required information from the DFU process. So the bootloader settings is only needed when you do initial programing from a debugger and not when you program via DFU. It is also not needed if you do not program the application but only bootloader and SoftDevice, and intend to DFU in the application later. In that case the settings page will be updated for you by the bootloader.

ziv123 said:

 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 ?

No. The bootloader will enter DFU mod then. You also need to flash the bootloader settings if you want the bootloader to start the application. (Note that tit is irrelevant if you merge the files or not when you program via a debugger).

ziv123 said:

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

No. You also need to program the bootloader settings so that the bootloader can know that there is a valid app present and start it.

ziv123 said:

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 ?

You do not need to change the BL settings if you upgrade via DFU as then the bootloader updated the bootloader settings for you as part of the process.. If you flash a different application form a debugger  you need to update the bootloader settings page and program that again. You can modify the bootloader to skip this check if you like though, by for instance making crc_on_valid_app_required() in <SDK>\components\libraries\bootloader\nrf_bootloader.c always return false.

ziv123 said:

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 ?

The example SES projects we provide include the SoftDevice as an additional load file, so it is programmed together with the application when you program from SES:

SES will program the SoftDevice and application without any problem when you have a bootloader. But the bootloader cannot start the app so you will not be able to run it unless you program a valid settings page for every time you change the app, or alternatively modify the bootloader as I mentioned earlier in this post.

ziv123 said:

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 

No, you cannot provide a softdevice with the --application option. There is a separate option for providing a SoftDevice (--softdevice). Please see "nrfutil pkg generate --help" for more details about this. I recommend you also go though this tutorial if you have not done so allready.

ziv123 said:

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

It means that UART communication is not working, which could have a number of explanations. It could be an issue with the physical connection, or it could be a mismatch of parameters (baud rate, flow control, etc.)

[ziv123]

ok

going back to basic since things don't work i i don't get why

flashed the softdevice hex and the bootloader from this example

\examples\dfu\secure_bootloader\pca10040_uart\ses

(untouched, beside the micro ecc issue) 

then generated a pkg and dfu it and all is well .. so far

in my app when i get a dfu command i do this:

case SYS_OP_MODE_DFU_INIT:
{
    NRF_POWER->GPREGRET = 0xB1;
    NVIC_SystemReset();
    break;
}

then i try to dfu with a second generated pkg of the same app with only minor change (version change)

it takes some time and then i get 

File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\dfu\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

and after i get that the old app loads (i see it by the version in the sttus message from the app)

what am i missing ? 

[Einar Thorsrud]

Hi,

It seems the UART communication between the PC (nrfutil) and nRF is not working properly for some reason, so we need to digg into that.

• Are you using a DK or custom board?
  • If DK, which DK?
  • If custom board, which pins do you use for UART and have you configured the bootloader to use the correct pins? Do you use flow control?
• Have you used a logic analyzer to check the data on the UART lines? Is there any data exchange at all?

[ziv123]

i don't think its the uart 

look at that:

D:\Ziv\projects\Redent-Nova-FW>nrfutil dfu serial -pkg Redent_0.zip -p COM12 
  [####################################]  100%
Device programmed.

D:\Ziv\projects\Redent-Nova-FW>nrfutil dfu serial -pkg Redent_1.zip -p COM12 

Traceback (most recent call last):
  File "C:\Program Files (x86)\Python383\Scripts\nrfutil-script.py", line 11, in <module>
    load_entry_point('nrfutil==6.1.0', 'console_scripts', 'nrfutil')()
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 782, in main
    rv = self.invoke(ctx)
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "c:\program files (x86)\python383\lib\site-packages\click\core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\__main__.py", line 1055, in serial
    do_serial(package, port, connect_delay, flow_control, packet_receipt_notification, baud_rate, serial_number, True,
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\__main__.py", line 970, in do_serial
    dfu.dfu_send_images()
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\dfu\dfu.py", line 127, in dfu_send_images
    self._dfu_send_image(self.manifest.application)
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\dfu\dfu.py", line 88, in _dfu_send_image
    self.dfu_transport.open()
  File "c:\program files (x86)\python383\lib\site-packages\nordicsemi\dfu\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

D:\Ziv\projects\Redent-Nova-FW>

you can see that when there is no application yet, just softdevice and bootloader then the dfu on serial works and i check the application it is working and i am communicating with the application on the same serial.. next i give the application this command 

NRF_POWER->GPREGRET = 0xB1;
NVIC_SystemReset();

and then i close the comm on which i was communicating with the app so it will be free to preform the dfu

and then i go to the terminal and try to dfu as can be seen above

the generate pkg commands:

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


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_0.zip
Zip created at Redent_0.zip

[Einar Thorsrud]

Hi,

I see you use the _debug bootloader, so it would be very interesting to see the RTT log. That way we could see if the device enters DFU mode after  you write to GPREGRET and reset or not. Does it? If not, what state is the bootloader in, seen from the log?

By the way, please provide full logs and contexts going forward so I get the full picture when trying to understand what is going on.