Application firmware is around 200ms slower to start after a bluetooth DFU

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Amanda Hsieh — Thu, 06 May 2021 08:31:32 GMT

That's correct.

-Amanda H.

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Liam — Wed, 05 May 2021 13:44:12 GMT

If I set --sd-boot-validation NO_VALIDATION will the softdevice still get CRC checked after a DFU update that includes a softdevice? But once its passed that it won't be checked again?

regards

Liam

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Amanda Hsieh — Wed, 05 May 2021 08:17:14 GMT

Hi Liam,

[quote user="hazeman"]Is it expected the CRC should only be checked immediately after a DFU not every power up (as appears to be the case here)?[/quote]

The bootloader will check CRC after reboot.

[quote user="hazeman"]is it possible to stop the CRC checking of the soft device using this command?[/quote]

Yes, you can generate the setting with the config --sd-boot-validation NO_VALIDATION.

-Amanda H.

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Liam — Tue, 04 May 2021 13:44:05 GMT

Hi Amanda,

It appears to me when the softdevice is updated over the DFU the range of addresses checked is extended to include it.

I don't know why NRF_POWER_RESETREAS_OFF_MASK is not being returned - the device is definitely being powered up from off. Is it expected the CRC should only be checked immediately after a DFU not every power up (as appears to be the case here)?

These are my settings

nrfutil settings display SimRDS200_V2_01.hex

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

Bootloader DFU Settings:

* File:                     SimRDS200_V2_01.hex

* Family:                   NRF52840

* Start Address:            0x00000000

* CRC:                      0x3CAB1BC1

* Settings Version:         0x00000001 (1)

* App Version:              0x00000001 (1)

* Bootloader Version:       0x00000001 (1)

* Bank Layout:              0x00000000

* Current Bank:             0x00000000

* Application Size:         0x00014C0C (85004 bytes)

* Application CRC:          0x79B2BCC7

* 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)

Generated by

nrfutil settings generate --family NRF52840 --application %APPLICATION_HEX_PATH% --application-version 1 --bootloader-version 1 --bl-settings-version 1 %SETTINGS_HEX% >nul 2>nul

So is it possible to stop the CRC checking of the soft device using this command? and is it desirable in a production setting?

regards

Liam

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Amanda Hsieh — Mon, 03 May 2021 11:05:48 GMT

Hi Liam,

The CRC check will depend on the length of the application firmware. If your application is large, the time sounds plausible.

[quote user="hazeman"]So crc_on_valid_app_required() is returning true even though NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET and NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 are set true.[/quote]

crc_on_valid_app_required() return true when the chip is reset by a wake from System OFF (config NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET), or when GPREGRET2 register is set (config NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2).

[quote user="hazeman"]It looks like nrf_power_resetreas_get is not returning with NRF_POWER_RESETREAS_OFF_MASK set?[/quote]

Maybe the device is not reset by a wake from System OFF.

There is also an option to select no boot validation when you generate the settings page. So another easier option could be to create a settings page to use during development which has boot validation of the application disabled. This settings page can be loaded automatically like we do with the Softdevice.

[quote user="hazeman"]what would be the risks of disabling the CRC check in the bootloader?[/quote]

At the start of the DFU process, the CRC inside the initpacket is stored in the bootloader settings page. The CRC check is done at the end of the DFU process, where we calculate the CRC of the received FW image, and compare it to the CRC stored in the bootloader settings page at the beginning of the DFU process. This is to ensure the integrity of the image. It might be easier in development, but I think this is dangerous and should not be used in an end product.

-Amanda H.

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Liam — Fri, 30 Apr 2021 09:57:42 GMT

Also what would be the risks of disabling the CRC check in the bootloader?

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Liam — Fri, 30 Apr 2021 09:51:31 GMT

That was already enabled. Disabling made no difference.

However waggling pins either side of crc32_compute in nrf_dfu_validation_boot_validate() shows this where the time is being taken up. 100ms before DFU, 330ms afterwards.

So crc_on_valid_app_required() is returning true even though NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET and NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 are set true.

It looks like nrf_power_resetreas_get is not returning with NRF_POWER_RESETREAS_OFF_MASK set?

Liam

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Amanda Hsieh — Fri, 30 Apr 2021 07:01:00 GMT

Hi Liam,

It might be cause of some CRC calculation of the image in the bootloader. If so, could enable NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET to skip CRC calculation in the bootloader sdk_config.h.

-Amanda H.

RE: Application firmware is around 200ms slower to start after a bluetooth DFU

Liam — Thu, 29 Apr 2021 09:48:24 GMT

As I said we include the softdevice in the update package using the following

nrfutil pkg generate --application %APPLICATION_HEX_PATH% --application-version 1 --application-version-string "1.0.0" --hw-version 52 --sd-req 0xB6 --sd-id 0xB6 --softdevice %SOFT_DEVICE_PATH_HEX% --key-file %PRIVATE_KEY_PATH% %UPGRADE_FW_PATH%

When I removed the softdevice from the upgrade package everything was OK and as you would expect the process was quicker.

I'm happy to do this as a fix but would like to understand how this will affect us if we need to update the SD in future ( we are currently using s140_nrf52_6.1.1_softdevice.hex) ?