Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

[FDS] PeerManager error -> try to find record which recently has been invalidated

Hi,

I am using SDK13 and  have noticed some critical issue with peer manager while bonding. The problem is that after performing dfu of my device (which was bonded with two phones before update) when I try to connect to device with first bonded device everything goes ok, but when I try to connect with the second phone device reset due to catching error inside pm_evt_handler

pm_evt_handler(...)
{
 ...
 
    case PM_EVT_PEER_DATA_UPDATE_FAILED:
    {
        APP_ERROR_CHECK(p_evt->params.peer_data_update_failed.error);
    }
...
}

This error is caused by fds which try to find record with function:

 

peer_data_find(...)
{
...
    ret = fds_record_find(file_id, record_key, p_desc, &ftok);

    if (ret != FDS_SUCCESS)
    {
        return NRF_ERROR_NOT_FOUND; <--- CALLED ERROR
    }
    
...
}

After my analysis error is caused by trying to find record which was recently invalidated (fds record keys overwritten with 0x0000). This error reproduce each time following steps below:

  1. Program device with FW (bootloader + application) over JLink
  2. In application perform bonding procedure for 2 phones (1st one HUAWEI HONOR 5X, 2nd Xiaomi Redmi Note 4)
  3. Enter bootloader and perform application dfu (same application as in 1st step)
  4. After DFU in application perform connection of 1st phone -> works perfectly
  5. Perform connection with 2nd phone -> cause error in code shown abowe.

After spending some time with that problem I suggest that it is caused by some race condition in updating peer manager bonding records.

What shall I do to prevent situation because it cause brick of all of my production devices?

  • Hello,

    I tried to perform the test that you described, but I couldn't reproduce it. It was one phone and one DK using nRF Connect for Desktop. Can you try to reproduce it using the example:

    SDK\examples\ble_peripheral\experimental_ble_app_buttonless_dfu. 

    Does it happen if you use a "clean" SDK (That is just unzipped, and not modified in any way). Maybe you changed something in another project that affected some common files?

    Best regards,

    Edvin

  • I can try, but what "application" have you use? You mention about bootloader but additionaly you need some application perform bonding (Bootloader + SD + App) and perform bonding in Application and then go back to new (fresh) application and try to connect.

  • I used the ble_app_buttonless_dfu application to perform the bonding.

    Edvin said:
    SDK\examples\ble_peripheral\experimental_ble_app_buttonless_dfu. 

     

    It also has the possibility to trigger DFU mode in nRF Connect. Not sure exactly how the Android version of nRF Connect works, but some phones needs a characteristic that is locked by a pairing requirement to trigger the pairing request. 

    I changed:

    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.write_perm);

    to

    BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&cccd_md.write_perm);

    on line 144 in ble_dfu.c to trigger this. It means that the connected device needs to be paired to enable notifications or indications (indications in this example). This requirement will trigger the phone to request pairing. 

    Best regards,

    Edvin

  • You are right but it is not the flow I mention. Once again, you need:

    1. bootloader programmed into device
    2. using flashed bootloader perform DFU process and send to device Application (eg. ble_app_multirole_lesc)
    3. Bond in ble_app_multirole_lesc (with 2 separate devices)
    4. enter bootloader and once again perform dfu with the same lesc application
    5. When device enter application (after dfu) mention recently bug should appear when you try to connect with phones
  • I did now, and it works here (again, one phone and one DK using nRF Connect).

    I flashed the bootloader on one DK, updated to the LESC application via DFU, bonded with 1: my phone, and 2: the DK that I used with nRF Connect to update the firmware. 

    Then updated the firmware again with DFU, to the same application with a higher application version. Then checked with both devices. They were still bonded. 

    The reason I asked you to test the experimental_ble_app_buttonless_dfu example is that it doesn't use LESC. I wanted to check if the issue was related to the actual bonding procedure or FDS. Not all phones support LESC. None of the phones that you listed are particularly new. Are you sure they both support LESC?

    Can you please try either with a new unzip of the SDK that is not modified, and if it still doesn't work, can you test with the ble_app_buttonless example? Remember to change the line that I mentioned in the previous reply to trigger bonding.

    In case you find it helpful, here is the script that I used to generate the images and flash the bootloader and the first DFU to get the LESC or buttonless application up and running with a bootloader. You need to adapt it to use your serial number (instead of 123456789) and the correct private.key and COM port for nrfutil.

    :: compile the bootloader
    make -j9
    
    :: flash softdevice and bootloader 
    nrfjprog -e --snr 123456789
    nrfjprog --program ..\..\..\..\..\components\softdevice\s132\hex\s132_nrf52_4.0.2_softdevice.hex --verify --snr 123456789
    nrfjprog --program _build\nrf52832_xxaa_s132.hex --verify --snr 123456789
    nrfjprog --reset --snr 123456789
    
    :: compile the buttonless example
    make -j9 -C ..\..\..\..\ble_peripheral\experimental_ble_app_buttonless_dfu\pca10040\s132\armgcc
    del files\buttonless_bonding.hex
    copy ..\..\..\..\ble_peripheral\experimental_ble_app_buttonless_dfu\pca10040\s132\armgcc\_build\nrf52832_xxaa.hex files
    ren files\nrf52832_xxaa.hex buttonless_bonding.hex
    
    :: compile the LESC example
    make -j9 -C ..\..\..\..\ble_central_and_peripheral\experimental\ble_app_multirole_lesc\pca10040\s132\armgcc
    del files\lesc.hex
    copy ..\..\..\..\ble_central_and_peripheral\experimental\ble_app_multirole_lesc\pca10040\s132\armgcc\_build\nrf52832_xxaa.hex files
    ren files\nrf52832_xxaa.hex lesc.hex
    
    :: generate buttonless images with 3 different application-versions
    nrfutil pkg generate --application files\buttonless_bonding.hex --application-version 1 --hw-version 52 --sd-req 0x98 --key-file files\private.key files\buttonless_1.zip
    nrfutil pkg generate --application files\buttonless_bonding.hex --application-version 2 --hw-version 52 --sd-req 0x98 --key-file files\private.key files\buttonless_2.zip
    nrfutil pkg generate --application files\buttonless_bonding.hex --application-version 3 --hw-version 52 --sd-req 0x98 --key-file files\private.key files\buttonless_3.zip
    
    :: generate lesc images with 3 different application-versions
    nrfutil pkg generate --application files\lesc.hex --application-version 1 --hw-version 52 --sd-req 0x98 --key-file files\private.key files\lesc_1.zip
    nrfutil pkg generate --application files\lesc.hex --application-version 2 --hw-version 52 --sd-req 0x98 --key-file files\private.key files\lesc_2.zip
    nrfutil pkg generate --application files\lesc.hex --application-version 3 --hw-version 52 --sd-req 0x98 --key-file files\private.key files\lesc_3.zip
    
    :: Perform the DFU to first application.
    ::nrfutil dfu ble -pkg files\buttonless_1.zip -ic NRF52 -p COM9 -n "Dfu_Targ" -f
    nrfutil dfu ble -pkg files\lesc_1.zip -ic NRF52 -p COM9 -n "Dfu_Targ" -f
    
    

    EDIT: This .bat script is placed in the armgcc folder of the bootloader project. The private.key is located in a folder called "files" inside this folder.

    Best regards,

    Edvin

Related