RTOS/LP-CC2652R: Launchpad CC2652R Host Test app - SDK 2.40 was working and SDK 3.10 is failing

Hi Ian,
Is it correct that you are using an LP-CC2652RB or do you use CC2652R1 Launchpad ? Which chip revision are using? (Ref e2e.ti.com/.../767769)

Hi Joakim,

I've no idea where the RB tag came from in the post title. It is a Launchpad R1 with rev E silicon I am using. It is marked "HW rev: B, FW SDK 2.40 1851".

Iain

Hi Iain,

Is the data sent as one or more packets over the air?

Do you have a sniffer capture of this happening?

Hi Iain,

Did you figure it out?

I will close this thread due to inactivity.

Hi Marie,
Not yet had time to take logs with failing SDK3.10. My priority was getting the system working which it did by going back to SDK 2.40. I plan to take some captures when I get time.
Iain

Hi Marie,

I have narrowed down the problem as I have tags based on both CC2650 (BLE 2.2.1) and CC2652RB (SDK 3.1).

The only failure case I see is a CC2650 tag (peripheral, SDK 2.2.1) sending large quantities of data to CC2652LP (central, SDK 3.10, Host_Test application with baud at 921k).

TAG CC2650 (BLE 2.2.1) to CC2652R1LP (SDK 3.10) - FAIL

TAG CC2652RB (SDK3.10RB) to CC2652R1LP (SDK 3.10) - OK

TAG CC2650 (BLE 2.2.1) to CC2652R1LP (SDK 2.40) - OK

TAG CC2652RB (SDK3.10RB) to CC2652R1LP (SDK 2.40) - OK

sniffer logs for these 4 cases are attached.

The data of interest from the CC2650 STK is notified on handle 3E and from the CC2652RB on handle 47.

In the failure case the area of interest starts at packet 610.

Iain

sniffer-logs.zip

Hi Iain,

I am not very familiar with Nordic sniffer, but from what I can see on the fail case trace the master device stops sending connection event packets?

Last successful packet seems to be packet 603, the slave sends noti packet. I would expect the master device to respond immediately with another connection event packet since the slave indicates that is has more data in the Data Header.

However it seems like the master drops the connection without indicating it over the air.

Do you get an error message on the master device when this happens?

Hi Marie,

I get a connection timeout event reported by the Host_Test app. That is the only event I receive. This happens after I get a corrupted data packet over the UART. 

The data is in the format of the audio profile. 5 x 20 byte packets consisting of 4 bytes meta data and 96 bytes of data.

Iain

Hi Iain,

Can you check the data going over UART before the BLE transmission? (I.e. the data going from CC2650STK to CC2652R before CC262R transmits it over the air.) You should be able to use a logic analyzer to monitor the UART line directly.

And possibly compare to a success case to see if there is any difference.

Hi Marie,

There seems to be some confusion about the system architecture as there is no UART between CC265x STK and CC2652R1. The R1 is connected by UART to a BeagleBone Black running the gateway application. I have already captured UART traffic out of R1 (received by R1) and it matches the corrupted data I see in the gateway application.

Note that if the tag is a CC2652RB + SDK 3.10 then there is no problem. The only problem is a BLE2.2.1 stack transmitting to a 3.10 host test application.

architecture.pdf

Iain

Hi Iain,

Thanks for the figure. So the data originates on the sensor, is transmitted to the CC2650STK then by BLE to the CC2652R and over UART to the BeagleBone Black.

You have tested and know that the data is correct when going over the air (BLE) but becomes corrupted on the CC2652R device before going over UART to the linux gateway.

Did you check the 3.10 application at lower baud rates?

Did you check the memory on the CCC2652R when this happens? (Task stack, ICall heap, UART buffer)

Hi Marie,

If I reduce baud rate between CC2652R1 and BBB then I lose data as I am generating more than 115k in sensor data.

As I have a working solution on SDK 2.40 and have no compelling need to move to 3.10 I propose to stick with what is working rather than invest money in debugging 3.10 further. My end customer is one of your CAT 2 accounts so if they want to revisit this I will get them to discuss with their FAE.

Iain