• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 6075 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2564: same stack cc2564 pairing issue with multiple HW

florent NS
Expert 1080 points
Part Number: CC2564


When we burn the same SPP stack into different MCUs (even if we setup the appname differently), windows recognize the device as already paired, but it is in fact another device.

So for example:

- board 1 burnt with SPP stack, then pairing done successfully on windows

- board 2 never paired before, same SPP stack, different hardware; windows recognize it as paired already.

How to make windows seeing the 2nd board not paired already? (the cc2564 should have a unique ID/mac address to forbid this?)

Thanks/F

  • 0
    TI__Mastermind 35795 points
    Hi , Your query has been assigned to BT expert. We will get back to you shortly .

    Thanks
    Saurabh
  • 0 in reply to S
    Expert 1080 points
    Hi Saurabh. Please assign another 'BT expert' for this other enquiry on TI support which is way more urgent; It was supposed to be answered by another 'BT expert' call DMZ: e2e.ti.com/.../2243948
    I can forward you our 'private' Email exchange as a proof: no flexible library updates from him. VERY bad support from this guy, overall just un-configurable not-flexible-at-all libraries as promised on the paper. Please let me know. Rgds/F
  • 0
    TI__Expert 5285 points
    Hello Florent,

    When running the CC2564C in this case it might be that the devices are using the same BDADDR therefore the device thinks they are already paired.

    Can you please read the BDADDR of each one of the devices and see if that's the case?

    I will guide you to the next step once this is confirmed/not confirmed.

    BR,
    Chen Loewy
  • 0 in reply to Chen Loewy
    Expert 1080 points

    Hello, we are using the latest SPP+LE stack on STM32F MCU and we have not modified any routines concerning the BDADDR.

    We run 2 boards, we get:

    OpenStack().
    Bluetooth Stack ID: 1
    Device Chipset: 4.1
    BTPS Version  : 4.0.2.1
    Project Type  : 6
    FW Version    : 7.26
    App Name      : test
    App Version   : 0.5

    LOCAL BD_ADDR: 0xA0E6F8FC5EB0

    and the second board:

    LOCAL BD_ADDR: 0xCC78AB87C3EE

    So it seems different from the . As said we didn't change anything related to the BD_ADDR.

    B.Rgds/F

  • 0 in reply to florent NS
    Expert 1080 points

    Hello, what is the next step?

    Rgds/F

  • 0 in reply to florent NS
    Expert 1080 points

    Hello, next steps is what?

    Rgds/F

  • 0 in reply to florent NS
    TI__Expert 5285 points

    Hello Florent,

    I apologize for the slow response.

    I will conduct a local test here and get back to you asap what needs to be done.

    BR,

    Chen Loewy

  • 0 in reply to florent NS
    TI__Expert 6335 points
    F,

    I’ve been unable to recreate this issue, using the following steps:

    1. Load SPPDemo into CC2564C w/STM32 host
    2. Add device from windows, successful connection
    3. Load SPPDemo into different CC2564C w/STM32 host
    4. Able to find new SPPDemo, and successfully connect through Windows (if Windows recognizes a device as previously connected, it does not show up when attempting to add new device)

    This test was conducted using stack version 4.2.1.0 and windows 7. I see you are using 4.0.2.1 for the stack, which version of windows are you using?
  • 0 in reply to dale
    Expert 1080 points

    Hello,

    We are using the latest windows 10 home edition, version 1703, OS build 15063.502

    Where can we download the latest stack? On TI web site it is mentioned v4.0.2.2.

    Thanks/F

  • 0 in reply to florent NS
    TI__Expert 6335 points

     

    is the latest release (4.2). I will find a Windows 10 machine and retry the experiment, and get back to you.

  • 0 in reply to florent NS
    TI__Expert 5285 points

    Hello Florent,

    I've been conducting the test over here and got the right response.each board responds with the right 

    However i'm doing it on FW level and not full stack as you are.

    So the issue seems to be part of the stack.

    We are in the process of trying to recreate the exact scenario you have and see where exactly is the issue - upper protocol stack or application layer.

    BR,

    Chen Loewy

  • 0 in reply to Chen Loewy
    Expert 1080 points

    Dear Chen,

    Ok noted & thanks a lot.

    B.Rgds/F

  • 0 in reply to florent NS
    TI__Expert 6335 points
    Florent,

    The issue seems to be in the way Windows 10 handles new BT connections. What worked for me is programming each board being tested with a different app name. One implementation of this is to append the last few bytes of the BD_ADDR onto APP_DEMO_NAME upon initialization. An example of how to do this can be found in our A3DPDemo_SRC project.

    This project defines APP_DEMO_NAME as a format string, and then later appends the last 3 bytes of the BD_ADDR on so that each device has a unique local name.

    Let me know if you need more assistance with implementing this system.