• State Answer Suggested
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 1920 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.

Data corruption in BLE transfer (180 bytes)

Rahul Shingrani
Prodigy 60 points
Other Parts Discussed in Thread: CC2541

Dear all,

We are using the CC2541 on the 1.4.1 BLE stack for an embedded project. We are facing a persistent issue and hope we can get some support here.

The CC2541 is interfaced with an external MCU (ARM7) on an SPI line. We are sending 180 bytes of data from the MCU on the SPI line and then transferring it using BLE to a smartphone (viewing data using the LightBlue app on the iPhone). We have enabled overlapped packet processing and are able to view the 180 bytes in the structure of 20 bytes x 9 packets. 

However, the received data has repeated and consistent corruption. For example, we sent all '1s' and this is what we receive for every 180 byte burst:

1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
1,1,1,1,1,1,1,1,1,1,1,1,1,30,128,34,12,24,0,98
1,1,1,1,1,1,1,1,1,1,1,1,1,30,128,64,12,24,0,128
1,1,1,1,1,1,1,1,1,1,1,1,1,30,128,94,12,24,0,158
1,1,1,1,1,1,1,1,1,1,1,1,1,30,128,124,12,24,0,188
1,1,1,1,1,1,1,1,1,1,1,1,1,30,128,154,12,24,0,0
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

Next, we checked the Rx_Data_Buffer and noted that it contains all '1s'. There is no corruption of the data here. 

Next, we made a local array of '1s' on the BLE and sent this array (instead of generating data on the MCU). We get the same result. The pattern of the corruption is identical every time. 

We are not sure why the data seems to be corrupted between the Rx_data_buffer and the wireless transfer. Any help would be appreciated. 

  • 0
    TI__Guru** 105180 points
    Hello,

    To rule in/out a wireless issue, I would suggest taking a BLE air sniff trace, for example with the TI BLE Packet Sniffer.

    Also, if you could elaborate on how you are sending the data to the BLE stack, that may be useful in finding root cause. For example, provide a code snippet that shows how you send the array of 1's.

    Best wishes
  • 0 in reply to JXS
    Prodigy 60 points
    Thanks for your suggestion JXS. We are setting up the packet sniffer and will report back to you about the outcome in the next 2-3 days. I will also share the code for sending the array of 1s then.

    Meanwhile, can you please shed some light on a related query: With our current setup, we are able to reliably send 180 bytes of data every 100ms from the MCU to the BLE and further to the BLE client device (iPhone). However, when we make any changes / efficiency improvements to the Micon->BLE data send routine, we are unable to connect to the BLE. These improvements are intended to reduce the time it takes to make the data transfer on the SPI line from the Micon to BLE.

    We are using the HeartRate Sensor protocol. When we try to connect to the BLE peripheral on the phone, the HeartRate Sensor device flashes and then disappears. If we reset the peripheral, it again flashes and disappears.

    We have tried to gradually reduce the data packet transfer but as soon as it goes below 180 bytes, we are unable to make the connection between peripheral and client (iPhone). Occasionally, the HeartRate sensor shows in the available devices, but when we try to connect, the connection times out. It seems like any reduction in the data size causes the BLE peripheral to go to sleep and therefore the connection is not established. Any hints to resolve this behaviour? We would like to make efficiency improvements to our code, but cannot seem to maintain connection with any improvements.

    Thanks much for your help!
  • 0 in reply to Rahul Shingrani
    Prodigy 60 points

    We were able to fix this issue by increasing the memory allocation for over-the-air payloads. There is a variable called HR_MEAS_LEN that needed to be set to 20 bytes (from 9). This is a new feature introduced in stack 1.4.1. 

    When we ran the code with the previous stack (1.4.0), we got no data corruption. Then we were able to find the porting notes for 1.4.0 to 1.4.1, which stated the allocation of over-the-air memory allocation. 

    Issue resolved. Thanks for your support.