uart stuck in while

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi All,

I am using UART for sending at commands.

example as below:-

UART_DEB_UartPutString("AT+UHTTP=0\r\n");

sometimes its working but sometimes its getting stuck in a function UART_DEB_SpiUartWriteTxData and never comes out of it

stuck in below while loop:-

{

            /* Wait until TX FIFO has space to put data element */

            while (UART_DEB_SPI_UART_FIFO_SIZE == UART_DEB_GET_TX_FIFO_ENTRIES)

            {

            }

            UART_DEB_TX_FIFO_WR_REG = txData;

        }

Did anyone faced similar issue?please suggest.

Thanks.

0 Likes
10 Replies
NoriTan
Employee
Employee
25 sign-ins 5 questions asked 10 sign-ins

This happens when the TX FIFO buffer is FULL and the TX cannot send any character.  I assumes three possible reasons.

1) CTS input is negated.

If  you uses the CTS input and the input is negated, the TX cannot send any character.

2) UART is disabled.

If UART is accidentally disabled, SpiUartWriteTxData() can accept characters but no characters are sent.

3) UART clock is disabled.

If the UART clock internal or external is disabled, no characters are sent.

If possible, please attach a snapshot of the UART's configuration dialogue.

Regards,

Noriaki

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi Noriaki,

Thanks for the reply.

PFA the PSOC Creator Configuration for UART.

Regards,

sagar

0 Likes

Can you attach your project?

Thanks,

Hima

0 Likes
Anonymous
Not applicable

I'm having the same problem in my project.  Actually talking to a spi device with an SCB peripheral in "spi mode".   Attached are my configurations.   Exact same functionality: it almost always works,  seems to have a problem when I increase the amount of data on the bus/interact with the SPI input device.  Locks up at the same line as sagard waiting for an opening in the tx fifo.

Thanks,

Nick

psoc_1.PNGpsoc_2.PNG

0 Likes
lock attach
Attachments are accessible only for community members.
NoriTan
Employee
Employee
25 sign-ins 5 questions asked 10 sign-ins

I have confirmed the issue with following source code.

#include "project.h"

uint8 txData[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};

int main(void)

{

    CyGlobalIntEnable; /* Enable global interrupts. */

    /* Place your initialization/startup code here (e.g. MyInst_Start()) */

    SPIM_Start();

    SPIM_SpiUartPutArray(txData, sizeof txData);

    for(;;)

    {

        /* Place your application code here. */

        CyDelay(1000);

    }

}

In this program, 16 bytes of data is going to be sent via SPI master.  The data is written by the method _SpiUartPutArray() at once.

The execution is stuck at following line.

GS003340.png

It was found that the program stops when the 10th byte "10" is to be sent.  The 1st byte is already sent to the slave.  The  2nd to 9th bytes (total eight bytes) are stored in the TX FIFO.  But these bytes in the FIFO are not sent to SPI.  I don't know the reason why FIFO does not consumed.

When the TX buffer size is larger than 8 to use the software FIFO driven by the interrupt requests, all data is accepted by the SPI.

GS003341.png

Could this be a workaround?

Regards,

Noriaki

Anonymous
Not applicable

If you don't have interrupts enabled to transmit the bytes from FIFO, then it will not be consuming the bytes.

If you don't have the clock for the SPIM ticking, then it also won't be clocking the TX bytes out of the FIFO.

If you are current IN an interrupt while waiting for the TX bytes to send out, that could be the cause of the issue.

Anonymous
Not applicable

That code on line 309 is only built if you do not have a software TX buffer enabled:

SPIM_CHECK_TX_SW_BUFFER

But I'm seeing something else.   This macro uses a mask:

#define SPIM_GET_TX_FIFO_ENTRIES    (SPIM_TX_FIFO_STATUS_REG & \

                                                 SPIM_TX_FIFO_STATUS_USED_MASK)

Here's the definition of the mask.

#define SPIM_RX_FIFO_STATUS_USED_MASK   ((uint32) SPIM_FF_DATA_NR_LOG2_PLUS1_MASK)

Here's a description of the bits used by the status reg:

/* SPIM_TX_FIFO_STATUS_REG */

#define SPIM_TX_FIFO_STATUS_USED_POS    (0u)  /* [3:0]   Amount of entries in TX FIFO */

So you might think the mask is going to be 0x0F. 

It isnt:

#define SPIM_FF_DATA_NR_LOG2_PLUS1_MASK (0x1Fu) /* Number of bits to represent #bytes in FIFO. */

Possibly we have another problem here with bit 4 generating a bad result?

0 Likes
Anonymous
Not applicable

That macro sounds like it is a binary count of the FIFO buffer byte size. Having a large available "count" shouldn't be the cause of the issue imo.

Nice work digging into the discrepancy though.

0 Likes
Anonymous
Not applicable

Hi Nick,

I think that not having interrupts enabled is the source of your problem.  You are also writing directly to the transmit hardware register like so:

pastedImage_0.png

So the first byte written (0x01) starts shifting out of the pin and subsequent writes of the other values to txData are just lost.  They aren't getting buffered.  You need to enable an internal interrupt and that has a service routine that gathers bytes from a buffer and writes them into the write register after each one is done transmitting.

See subsequent answers (on following questions) to make this more clear.

Anonymous
Not applicable

The SPI write function I use is this:

uint8 empty[] = {0,0,0};

SPI_SpiUartPutArray(empty,3);

However, I have the buffer sizes set to 80 using a software buffer. I am also polling the FIFO buffer instead of using the interrupt, but I don't remember if it was due to the interrupts not working for me, if I had no ability to use the interrupts with my setup, or if I was just lazy

0 Likes