CC2340R5: About OAD update address mode

Hi Masaki,

Thank you for reaching out. Can you specify how the OAD is failing? Are you getting an error on the basic ble side or the SimpleLink Connect side? Can you share the error? As a quick test, could you grab a second board, flash host_test, and try to perform OAD using btool?

Best Regards,

Jan

Hi Jan

Thank you for your help on another matter.

I'm still confirming things, but I'll share what I know for now.

①About error status
When this happens, the OAD update will not proceed. At this time, the PC has moved to the persistent app and is in a sleep state (advertisement state).

In other words, the persistent app is running without any problems, but it cannot connect to the smartphone.

Although I think RPA requires bonding to hold IRK

I think that the SDK's default on-chip and persistent do not perform bonding, so the address cannot be tracked by IRK and is failing.

So I enabled bonding, but the following error occurred.

This occurs not only on reference boards but also on devices under development.

Is there anything you know about this error?

Regards,

Masaki

Hi Jan.

Although the number of trials was small due to the connection of the reference board, I confirmed that it works with Btool.

On-chip and persistent RPA with public ID failed to update.

The on-chip and persistent public addresses were successfully updated.

Since the number of trials is too small, I would like to borrow another equipment and test it. Have you found out anything at this point?

Best Regards.

Masaki

Hi Masaki,

Jan is out of the office until next week.

Please bear with us,

Best regards,

Hi Clément

Thank you for contacting me.

Best Regards

Masaki

Hello Masaki,

Could you please confirm what is working with BTool? Is it only OAD using PA or RPA as well?

In the meantime, do you have a ble sniffer that we could use to see why it is failing?

BR,

David

Hi, David

When on-chip and persistent were in PA, I was able to successfully update Btool. When both are RPA, Btool update always fails.

When RPA fails, Btool displays a message that the update failed. Also, Persistent apps are advertising.

This issue where the Persistent app is advertising even though this update has failed is also confirmed by SimpleLinkConnect.

The issues so far are as follows. both addresses are RPA. Also, for ① and ③, only PA⇒RPA is changed from on-chip and persistent syscfg.
In ②, in addition to PA⇒RPA, the pairing mode is changed from "Wait for a pairing request" to "initiate a paring request".

①SimpleLinkConnect fails to update and Persistent app is advertising.

②SimpleLinkConnect fails to update. At this time, an Alert will be displayed indicating that OAD Service was not found, as shown in the image below. Also, 　unlike ①, Persistent app is not advertising.

③Btool fails to update. And Persistent app is advertising.

I noticed that ① and ③ occur when bonding information is not saved on the OS side.

If the bonding information can be confirmed from the OS settings as shown in the image, it will not be reproduced.

Since the bonding information is not saved on the OS side, I think the IRK key is not saved correctly and central is not able to track the address of the peripheral (persistent app). And since peripheral cannot be tracked, persistent apps continue to advertise.

Unlike ①, in ② I can confirm that the bonding information was registered on the smartphone during pairing before the OAD update. Then,② is reproduced instead of the ①

I want to register bonding information with Btool, but I don't know how. After connecting, I tried saving the LTK and disconnecting and reconnecting, but the bonding information is not displayed in the Windows bluetooth settings.
Is it possible to display bonding information on Windows with Btool? By doing so, I will see the following issue for Btool.

For sniffing I can use wireshark.

Best Regards,

Masaki

Hello Masaki,

Thanks for the helpful details. Please allow us until Monday to go through them and try to inspect the issue using a ble sniffer.

To confirm both devices are paired and bonded, a ble sniffer can also be a good reference point, instead of displaying that information on Windows.

BR,

David.

Hi David

Understood. confirm.

I have some other work to do, so the confirmation itself will likely be this Wednesday.

please wait a moment.

Best Regards,

Masaki

Hi Masaki,

No problem! Let us know when you have had time to test this on your side.

Best Regards,

Jan

Hi Jan,

Sorry I made you wait.

Attach the sniffed file.

sniffing files.zip

I am using a virtual sniffer called Bluetooth Virtual Sniffer (btvs.exe), and it may not be possible to collect the packets that Jan needs.

Please let me know if the information in the packet is missing.

The collection timing starts after pairing and before update.

The end of the collection timing is when the update starts and an error occurs or the update continues and the progress bar moves.

The attached file is a capture of the original Waireshark and a file with the unnecessary processing performed multiple times filtered out.

Files written as public have basic and persistent address types as public.
The file written as rpa has basic and persistent address types as rpa.
The file written as wait has the pairing mode of basic and persistent as "wait for a pairing request".
The file written as initiate sets the basic and persistent pairing mode to "initiate a pairing request".

As far as I have checked, both SimpleLink and Btools always fail in an RPA environment.

◆env
windows 10 pro
CCS12.4
simplelink_lowpower_f3_sdk_7_20_01_10 and Btool

iPhone13 mini iOS17.1.2
SimpleLinkConnect 1.3.3

Best Regards,

Masaki

Hi Masaki,

Understood. Thank you for the logs. Can you specify if any modification (besides changing the addressing mode) has been made to the project? I would like to try to reproduce this on my end if possible. Could you also share if the behavior occurs with an Android device as well?

Best Regards,

Jan

Hi, Jan
yes. In other than address mode, flash_map_backend.h is changed.
All changes are listed below.

◆mcuboot_LP_EM_CC2340R5_nortos_ticlang

Change flash_map_backend.h to below

#elif defined DeviceFamily_CC23X0R5
    #define BOOTLOADER_BASE_ADDRESS             0x00000000
    #define BOOT_BOOTLOADER_SIZE                0x00006000

//    #define BOOT_PRIMARY_1_BASE_ADDRESS         0x00006000
//    #define BOOT_PRIMARY_1_SIZE                 0x0003d000

//    #define BOOT_SECONDARY_1_BASE_ADDRESS       0x00043000
//    #define BOOT_SECONDARY_1_SIZE               0x0003d000

    #define BOOT_PRIMARY_1_BASE_ADDRESS         0x00006000
    #define BOOT_PRIMARY_1_SIZE                 0x0002c000

    #define BOOT_SECONDARY_1_BASE_ADDRESS       0x00032000
    #define BOOT_SECONDARY_1_SIZE               0x0004a000
#else

◆basic_ble_oad_onchip_LP_EM_CC2340R5_freertos_ticlang

Change address mode and pairing mode from syscfg of basic_ble_oad.

◆basic_persistent_LP_EM_CC2340R5_freertos_ticlang

Similarly, change the persistent app according to the conditions.

I will also attach Hex.
Changed flash_map_backend.
Set basic app to "RPA with Public ID" and "Initiate a pairing requeset"
This is the hex with persistent app set to "RPA with Public ID" and "Initiate a pairing requeset".

Hex.zip

As for Android, I don't have it, so I'm asking other members to confirm.

Best Regards,

Masaki

Hi Masaki,

Understood. Could you clarify why you have modified the flash_map_backend? I don't expect this to have an impact on the behavior, but to be safe do you still see the issue with the original flash_map_backend? Also, please let me know if the Android version has the same behavior.

Best Regards,

Jan

Hi, Jan

I only know how to change flash_map_backend, so I would like to know the steps to take if I don't change it.

I think that the change in flash_map_backend may have an effect.

Should I just build the SDK without changing anything and get the hex?

What address should I enter in Uniflash in that case?

Please wait a moment for Android.

Best Regards,

Masaki

Hi, Jan

I asked another member to try the previously attached Hex.zip on Android.

It is said that the update was successful 3 out of 3 times using SimpleLinkConnect.

So I tried it again with iPhone 13 mini,

As expected, the update fails and progress does not proceed.

Best Regards,

Masaki

Hi Masaki,

Understood. Based on the test, it seems that the issue seems localized on the iOS version of the application. Can you share which specific version of the SimpleLink Connect application you are using on the iOS side?

Best Regards,

Jan

Hi, Jan

SimpleLinkConnect version is 1.3.3

iOS version is 17.1.2.

Best Regards,

Masaki

Hi, Jan

Understood. I hope it gets fixed and works.

Thank you for your cooperation.

Best Regards,

Masaki