• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 318 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.

Original question:

CC2340R5: UART2, callback mode continuous read

CC2340R5: Uart, bytes lost during transmission and reception.

Artur Watala
Prodigy 20 points
Part Number: CC2340R5
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi. I've come back to work on this after a long time. Unfortunately the problem still exists. 

I described earlier that the problem occurs when receiving data in callback mode. The problem occurs when receiving a long frame (longer than the user buffer size, I copy received data to the larger buffer in callback). When the user buffer size is 64, sometimes one byte is lost during it and it is always byte 73 (i.e. DMA transfer size + FIFO size?) This not always happen.

During writing, I use NONBLOCKING mode and interestingly, here too, sometimes one byte is lost and it is always byte 10. I simply send every 15ms the string of characters "012345678901234567891234\n" The following is received: "01234567801234567891234\n" 

I noticed that when the problem occurs (during transmission), there is always a UART_INT_TXDMADONE interrupt at the beginning of the transmission (I don't know why, the previous transmission is long finished). In the attached image, the lower trace is the UART_INT_TXDMADONE interrupt (the GPIO pin is toggled when entering UART_INT_TXDMADONE  interrupt.)
The project is based on the "data_stream" example with a BT stack. However, I also did a test modifying the "uart2callback_LP_EM_CC2340R5_freertos_ticlang" example in the way below and the results are the same.

BR
Artur

  • 0
    TI__Guru**** 218507 points

    Hi Artur,

    I don't have any familiarity with the previous thread and callback mode, however I am aware of a race condition which will be resolved in an upcoming SDK update.  The non-block code you've provided here will also cause a race condition in which very little waking time is given to the MCU in between sleeps (UART is not active in standby), thus the bytes you are missing is likely from over-filling the TX buffer past the Ring Buffer Size provided in SysConfig.  For example, if you were to use Blocking Mode you would not experience this issue.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 20 points

    Hi Rayan,

    Thanks for your reply.
    I can't really use blocking mode because the entire application is running in a single thread. Is it possible to completely disable MCU sleep? This is not a critical application in terms of power consumption.
    Regarding the previous thread, I noticed that in callback mode one or two bytes are also lost during reception. And as I wrote, it is always a byte following DMA_BUFFER_SIZE+FIFO_SIZE. So if the DMA buffer is 64B, then sometimes byte 73 is lost. Could this also be related to MCU sleeping?

    BR,
    Artur

  • 0 in reply to Artur Watala
    TI__Guru**** 218507 points

    You can try setting PowerCC23X0_doWFI in the SysConfig -> TI DRIVERS -> Power Module?  Once again I haven't evaluated the previous thread in-depth so I cannot further comment.

    Regards,
    Ryan