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.

CC2640R2F: ANCS data received with garbage

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2540

Tool/software: Code Composer Studio

SDK --> simplelink_cc2640r2_sdk_4_10_00_10

I am working on "Simple peripheral" project.

BLEstack -> Simple peripheral

-----------------------------------------------------------------------

Hi, 

Below is the ANCS implementation I have used and running on my development board.

https://github.com/ti-simplelink/ble_examples/tree/simplelink_cc2640r2_sdk-2.20/examples/rtos/CC2640R2_LAUNCHXL/bleapps/ancs/src/app

Problems:

# WhatsApp Calling

  1. App name is coming but 3 garbage characters are there in front of it.
  2. Phone no. is also not coming correctly.

            

            

# WhatsApp Message

When the name is saved then the name is coming with 3 garbage values in front of it.

 

I have checked that the "dataBuf" is receiving the wrong value in both cases.

No changes are done on top of the ANCS example project from the link.

How to resolve this particular issue will critical in further implementation.

Regards,

Saurav

  • Hello Saurav,

    I have assigned an expert to comment.

    Regards,

    Jan

  • Saurav,

    Unfortunately I don't have an Apple phone to test any of this but, since you are seeing corruption in the data buffer, I imagine the large number of memcpy and memcmp calls may be getting corrupt data due to preemption.

    My first attempt would be to test all the return conditions of these calls (currently set to VOID) and see if any fails or a specific byte count is incorrect. Apart from this, I would also go through the BLE migration guides and see if anything else in the code stands out. I perused the documents and could not spot any major critical aspects, but it is worth a try.

    https://dev.ti.com/tirex/explore/node?node=AAafBKylj8ra01461K-lnQ__krol.2c__LATEST

    (keep in mind the BLE Staci version is different than the SDK itself - the one used in the SDK 2.20 of the original project is 3.02)

    Hope this helps,

    Rafael

  • Hi  ,

    I have used "simplelink_cc2640r2_sdk_2_20_00_49" this SDK also to check the ANCS example code, then also the same garbage is observed.

    I didn't understand a lot from your comments, can you please guide me on what should I do in a simpler language/way.

    .

    It will be very helpful if someone from your team can try to reproduce the issue at your end too.

    .

    Regards,

    Saurav

  • Saurav,

    I asked for help from colleagues that have Apple devices to test this, but at first glance I suspect that something may have changed on the Apple device side itself, since your report of building this project with the original SDK still fails.

    Regarding my suggestions, they are simply a way to monitor the return value of the various memory allocation function calls of the example, which could have been reporting back errors but they were being simply ignored by the keyword VOID. However, given the example is not working even with the original SDK, this is probably not the root cause.

    I will report back any additional insights.

    Regards,

    Rafael

  • Saurav,

    I heard from a colleague that my suspicion above seems to be confirmed: Apple seems to have changed something on their side and the example broke.

    Are you able to capture a Bluetooth sniffer log with the debug keys enabled, so the data can be analyzed?

    Best regards,

    Rafael

  • Hi ,

    I am trying to get the logs and will post it here soon.

    Sniffer we have: "CC2540 USB evaluation kit" 

    Will it be enough for getting the desired logs you are asking for?

    Regards,

    Saurav

  • Saurav,

    I am not entirely sure if the simpler sniffer will be able to capture everything of interest, but it is worth trying. Please give it a try and make sure you are enabling the debug keys in case you are using bonded/encrypted connections.

    Regards,

    Rafael

  • Hi Saurav,

    The CC2540 USB Sniffer will not be able to parse BLE 4.2 packets. To parse BLE 4.2 packets please look to use our Packet Sniffer 2 or look to leverage a 3rd party sniffer. You can find more information about Packet Sniffer 2 documentation here:

    dev.ti.com/.../debugging-index.html

  • Hi Desouza,

    We tried taking the sniffer logs but not able to see the TITLE attribute over there.

    Hence cannot confirm if the garbage value is coming from ANCS or not.

    Regards,

    Saurav