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

[Liam]

Hi,

 I found that after a DFU my application is slower to start up by about 200ms. However when programmed initially (via a physical connection) its fine. Its only after the DFU (with the same firmware there is a problem).

 I toggled some lines to find out where the delay appears to be. The bootloader is starting immediately after power up but the program start is delayed.

 I've tried it with the LF RC in case and it made no difference.

 BTW my firmware image contains the applcation and softdevice.

 This 200ms delay is causing me issues so I need to find a solution.

kind regards

Liam

[Liam]

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

[Amanda Hsieh]

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.

[Liam]

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

[Liam]

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

[Amanda Hsieh]

Hi Liam,

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

Liam said:

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.

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

 

Liam said:

It looks like nrf_power_resetreas_get is not returning with NRF_POWER_RESETREAS_OFF_MASK set?

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.

 

 

Liam said:

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

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.