This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

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

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

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

  • 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

  • Hi Liam,

    Liam said:
    Is it expected the CRC should only be checked immediately after a DFU not every power up (as appears to be the case here)?

    The bootloader will check CRC after reboot.  

    Liam said:
    is it possible to stop the CRC checking of the soft device using this command?

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

    -Amanda H.

  • 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
Reply Children
No Data
Related