This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to clean primaryServiceUUID cache?

Other Parts Discussed in Thread: CC2541

Hi everyone,

    I'm debugging cc2541 with Nexus5 (andriod 5.0).

    I find the andriod system will cache device's primaryServiceUUID.(same mac device)

    For example, cc2541 demo have a primaryServiceUUID=0xFFF0, and after I change it to 0xFEE7,

    the app (BLE reader, BLE Explorer, etc.) still display 0xFFF0.

    Restart Bluetooth, restart phone, reinstall app, even wipe cache partition is not work.

    And my workmate's andriod phone's app  detect the right primaryServiceUUID as it's the first time he connect to this device(no cache).

    How to clean primaryServiceUUID cache? Otherwise I have to replace phone or cc2541 moudle... 

  • Hi,

    We're not really suited to give support on the Android platform, but I've successfully gone into the app manager and deleted the application data/cache for the 'Bluetooth sharing' app. Not sure if this is applicable for you Android device.

    BR,
    Aslak
  • well, it seems not work.
    It is because Andriod system cached the information, and it's no use to clean the app's cache.
    I replace a new cc2541 to continue to work...
  • Ah, too bad.

    Keep in mind that you can change the MAC address of the device, you don't have to switch out the device.

    Use SmartRF Flash Programmer (not 2.0) to set the 'Secondary' address, and if it's != 0xFF's then it will be used instead of the address assigned during production. When re-programming/erasing, this secondary address is lost as it resides in the last flash page.

    You can also use HCI_EXT_SetBDADDRCmd(..) (hci.h) to set the device address programatically. This should be done in the init part of the user task before the GAP machinery is initiated.

    BR,
    Aslak
  • It's a good idea!
    thanks very much!
    And would you please look at this problem?
    I have no idea to generate "accurate" 50ms event, as RF_ISR takes too much time:
    e2e.ti.com/.../440786