• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 336 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.

AM2634-Q1: UART stops transmit when receives data in SPI

karthi keyan
Prodigy 20 points

Part Number: AM2634-Q1

Hi TI Forum, 

we are using all 6 UART pheriperals in non-blocking mode with DMA in our project, we do have 4 SPI channels also. When integration we encountered with an issue that, when UART TX will be happens normally untill SPI receives the data from other source. If reception happen then the TX of the UART channel stopped due to " Tx buffer is not NULL". We are using UART dma lld for the development. 

we tried with 'transactionInit(&trans); '  before call the UART_write(); function. still facing the issue. Is any cases found before or if any known solutions available then kindly revert back to the message. 

image.png

Image Ref: Failing as UART_TRANSFER_STATUS_ERROR_INUSE, but there is no actual TX is pending. 

  • 0
    TI__Genius 13629 points

    Hi Karthi, I have a few initial suggestions:

    1. Check that you're not accidentally sharing DMA channels between UART and SPI, and that DMA channel priorities are appropriately set.
    2. Review interrupt priorities for both UART and SPI peripherals

    Once these are checked/confirmed, please let me know and we can proceed further with the debug.

    Regards,

    Brennan

  • 0 in reply to Brennan Hartigan
    Prodigy 20 points

    Hi Brennan Hartigan, 

    Thanks for your reply.

    1. we have used different channels for SPI and UART DMA.

    DMA channels for SPI as below,

    DMA channels for UART as below,

    2. When talks about priority,

    all UART peripherals are selected priority number 4 and no specific priority set for SPI.

    These are the details.

    pls suggest what else can be check.

      

  • 0 in reply to karthi keyan
    TI__Genius 13629 points

    Karthi,

    Can you check the UART TX line using a logic analyzer or oscilloscope to monitor that signal when the error occurs? I am curious if the UART TX line stops toggling or if this is software reporting an error.

    Regards,

    Brennan

  • 0 in reply to Brennan Hartigan
    Prodigy 20 points

    hi brennan, we have checked the TX line, no toggling. Till SPI start receives the TX of UART is fine. once received then immediately getting into TX OFF

  • 0 in reply to karthi keyan
    Prodigy 20 points

    hi brennan, often it hits the error as below image,

    image.png

    can find anything as per below observations,

    it is keep showing the 'write size remaining' as 12.

    below one is EDMA of the UART channel,

    Today we have found one more thing that the RTI timer is stopped after this error happens.

    expression values as above after stopping TX and RX of UART.

    can you pls suggest anything to address this issue.

  • 0 in reply to karthi keyan
    Prodigy 20 points

    hi, the issue with UART and SPI has resolved with using different priority and some code modification due to buffer filling error. Now we are facing only one issue that, 

    1. if i received more that expected bytes in RX part of DMA getting hang / stop which is Stopping the TX and RX. 

    For example, i am setting the expected RX count as 150 from my source. My source (foreign item) can send 150 or 300 or 450. It depends on the speed of moving over the sensor. 

    if i receive 150 exactly then no issue. If i receive more than getting into error. I kept my RX DMA size is 150 as of now. 

    kindly suggest how it can be rectified. 

    Thanks and regards,

    S.Karthikeyan

  • 0 in reply to karthi keyan
    TI__Intellectual 2080 points

    Hey Karthi, 

    Glad to know that the previous issue got resolved. Regarding the varying RX size, when using DMA its always required to know the amount of data being sent or received before hand. If the RX DMA count is 150, it can can only receive 150 bytes. The RX DMA cant be expected to handle additional data it is not prepared for. To accommodate more data, its advised to either adjust the value before hand or trigger a different DMA transaction to receive more data. Hope this clarifies the issue. 

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    Prodigy 20 points

    hi pranav,

    we understood the operation of DMA and it is unavoidable that provide the exact expecting RX count since the source is not in our control. As of now reading the DMA buffer periodically and not depends on the callback interrupt. as soon as we received the required data (i.e. we know the start and end byte) we copied into the local buffer and clear the DMA. Kept DMA size as 1024 and expecting Count as 1024. Before it fills and create the callback interrupt, we receive and copies the data and initialize the DMA.  As of now it is working. Shall observe for several criteria. 

    Thanks and regards,

    S.Karthikeyan

  • 0 in reply to karthi keyan
    TI__Intellectual 2080 points

    Hi Karthi, 

    Are there any updates on this issue? Does the DMA size of 1024 satisfy all your criteria?

    Regards, 
    Pranav Siddappa