• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 53 subscribers
  • Views 1578 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.

Lost characters when using CC2540 USART

Cameron Esfahani2
Prodigy 40 points
Other Parts Discussed in Thread: CC2540

I'm trying to read data from the CC2540 USART and send it over BLE. The problem is that I'm losing characters almost immediately. The device writing to the UART is sending 6 bytes at 115200, 8N1. I've also tried 57600 without any success.

I've verified that there's never any lost characters from that side. I've also verified that if I ignore the serial data, and just write a constant incrementing byte stream from the CC2540, through BLE, I don't lose anything.

I'll see about 60 good bytes or so and then I'll lose 10-15 bytes.

I'm using BLE 1.3.

I've checked and I'm not getting any errors like HAL_UART_RX_FULL or HAL_UART_RX_ABOUT_FULL.

I've also dramatically increased the size of the RX DMA buffer to no avail.

I've disabled POWER_SAVING and am using DMA. And I've made sure to disable ClkDivOnHalt and HaltDuringRF with the following lines:

HCI_EXT_HaltDuringRfCmd( HCI_EXT_HALT_DURING_RF_DISABLE );
HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_DISABLE_CLK_DIVIDE_ON_HALT );

Here's some relevant #defines from my project.

HAL_DMA=TRUE
xPOWER_SAVING
xPLUS_BROADCASTER
HAL_LED=TRUE
HAL_UART
HAL_UART_ISR=0
HAL_UART_DMA=1
HAL_UART_USB=0
HAL_UART_RX_FLUSH=FALSE
HAL_UART_DMA_RX_MAX=512
HAL_KEY=FALSE
HAL_LCD=FALSE
HAL_ADC=FALSE
HAL_LED=FALSE
HAL_AES=FALSE
HAL_HID=FALSE

At this point I'm out of ideas...

  • 0
    Guru 22270 points

    Hello Cameron,

    Eliminate any possible physical connection problems.  Do an echo on the CC2540 side by connecting the Rx and Tx lines.  Send the data and see if any errors occur.  Then do an echo test with CC2540 and the other device by simply having it echo what the CC2540 has sent. Do the same on the other device.  The reason for the errors will be due to the line that is causing the failure.  Also, check the ground connection between them.

    If there is a problem on the CC2540 side then run the UART sample project and test again.  If it works, then you will know for sure your configuration is incorrect.  If it fails, then you have a problem with the either the Rx or Tx pins.

    Thanks,

  • 0 in reply to Greenja
    Prodigy 40 points

    Which UART sample project?

    I'm not sure if your suggestions will tell me anything new.  My source device is an Arduino board and I've hooked up an FTDI serial port to it and verified that I have no problem sending data through it as fast as possible  I've also put a scope on the TX line from the Arduino board and it looks fine.  And, as I mentioned in my initial post, I've also modified the CC2540 firmware to read the serial data, but send a known byte stream through BLE.

    If the Arduino was dropping the characters, or if the CC2540 was having problems sending the data, I'd be able to see those cases.  I'm not, so that's why I believe the issue to be somewhere in the UART RX side.

    While I was googling around, I saw this interesting piece of information from https://github.com/RedBearLab/Biscuit:

    "TI CC254x SDK version 1.2.1 - Due to the UART issue, currently not support SDK 1.3, we are trying to fix it with TI support"

    I wonder what this UART issue is?

  • 0 in reply to Cameron Esfahani2
    TI__Expert 6840 points

    1.2.1 had an issue with dma not always transmitting last byte. This was addressed on 1.3 with tx on Isr and rx on dma. Maybe check the Hal code to make sure this hybrid version is being used.

    I'm not aware of any rx issues with dma though.

    It's possible data can be lost after successful transmission ota if the receiver is too busy to pass it up through the stack. You would have to be at low intervals though for this to be a problem though.

    Also try with hw flow control if possible.

    greg

  • 0 in reply to GregS
    Prodigy 40 points

    I'm not defining HAL_UART_TX_BY_ISR, so TX should be via ISR.  Which doesn't really matter for me since I'm not doing any transmitting over the UART.

    I'm not in a position to be able to use HW flow control since those pins aren't wired up.

    I'm tempted to download SDK 1.2.1 to try and use that based on the RedBear comments about UART issues with SDK 1.3...

  • 0 in reply to Cameron Esfahani2
    Prodigy 40 points

    Hmm, where can I get SDK 1.2.1?

  • 0 in reply to GregS
    Prodigy 90 points

    Is there a workaround for 1.2.1?  I'm currently working with the BLE Mini from RedBearLab and their current source version only supports 1.2.1.  I have noticed quite a few missing bytes in my transmissions and have messed with the settings as much as I can.  I'm fairly new to developing for chips like this so pardon my ignorance.  Hardware flow control is not possible btw in this instance.