• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1006 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.

RTOS/MSP432P401R: UART with flow control stalls

Alvin Junus
Prodigy 20 points

Part Number: MSP432P401R

Tool/software: TI-RTOS

Hi,

I'm having trouble running UART at baud rate 115200 with flow control to a cellular module. I'm using Simplelink 1.40.00.28 on MSP432P401R Rev C.

On a stripped-down version of my project, a thread listens for UART packets from the cellular module and then sends it to another UART port for console display, and another thread (with a lower priority) initiates procedures for connecting to the cellular network. Here, UART communication runs smoothly and network communication can be maintained.

The UART module is then integrated into the full-scale project which runs more threads (for logging, routine functions, and I2C & SPI sensors). The UART listener thread still has the highest priority among the other threads. Here I encounter two issues:

1. The thread responsible for connecting to cellular network needs to wait for a long time between each UART transmission for the data to be sent and received successfully. Basically, I had to insert usleep(200000) between each UART instruction to the cellular module. (the number 200000 was obtained through trial and error)

2. When data of larger size is expected (here it is 130 bytes), the UART seems to stall and no data could be received at all.

Referring to errata USCI44 in slaz610m, both MCLK and SMCLK (which runs my UART clock) are driven by DCO, and I have not polled UCAxTXIFG and UCAxRXIFG. I have also increased the UART ring buffer size to 1024 but to no avail. Pls help on this.

Thanks,

Alvin

  • 0
    TI__Guru 71271 points
    Alvin,
    Something similar is described here:
    e2e.ti.com/.../639111

    Chris
  • 0
    TI__Guru 71271 points
    Alvin,
    Curious to know if you are using blocking or non-blocking APIs to read the UART ring buffer. Also, any description of the program flow for receiving data and handling callbacks (if applicable) would be appreciated.

    Regards,
    Chris
  • 0 in reply to Chris Sterzik
    Prodigy 20 points

    Hi Chris,

    Thanks for your reply.

    In this case, I have increased the ring buffer size to 1024 (and have also tried 2048) but the problems still persist.
    I'm using blocking mode for the UART. I also do not use callbacks in the project.

    As for the program flow, there are 3 threads dealing with UART communication:
    1. Thread A (priority 1) initiates connection procedures to connect to the cellular network. It feeds instructions for the cellular module into a message queue and then waits for event bits to be set before feeding the next instructions.
    2. Thread B (priority 3) sends instructions in the message queue to the cellular module through UART.
    3. Thread C (priority 8) constantly listens for UART data from cellular module. Received UART messages are fed to another UART port connected to PC console and then parsed. It will then set event bits for Thread A based on parsing results.

    Hopefully the attached pictorial flow can help clarify the program flow.

    Alvin

  • 0 in reply to Alvin Junus
    TI__Guru 71271 points

    Alvin,
    I have not been able to resolve what the issue might be. I would recommend looking into why the uSleep was needed to get the system working. Specifically I would look at how different threads are suspended (through sleep or pend) to allow other threads to be serviced. Bear in mind that HWI's will take priority regardless of the task priority, so you could end up servicing several ISRs which delay the completion of a task.

    I am going to close this since I will not be able to carry the conversation.


    Chris

**Attention** This is a public forum