FIFO Transmit works only with delay after putting data into FIFO

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

cross mob
Not applicable
Hello community,


see the title for the Problem: FIFO Transmit works only with delay after putting data into FIFO.
I send out data vis SPI to be display on a TFT display.

This means, when I set a delay of about 100 cycles (I am using an XMC4800), everything shows up nicely on my display.
However if i skip this delay, nothing can be seen on the screen.
What am I doing wrong with my FIFO Settings?

See the sending function:

void disp_vSPI_TransmitWord(USIC_CH_TypeDef* USICX_CHX, const UINT16 data)
{
UINT16 u16WaitCtr = 0;
if ((USICX_CHX->TRBSR & USIC_CH_TRBSR_TFULL_Msk) == TRUE) //CCM__O_TX_FIFO_FULL)
{
return ;
}
//Push Data in FIFO Buffer
USICX_CHX->IN[DISP_SPI_USICCH_MODE] = data;
// Wait until Data is transfered to FIFO
while ( ((USICX_CHX->TRBSR & USIC_CH_TRBSR_TEMPTY_Msk) == 0))
{

u16WaitCtr++;
}
// IF I UNCOMMENT THIS WAITING ROUTINE, NOTHING HAPPENS
for ( u16WaitCtr=0; u16WaitCtr < 230;u16WaitCtr++)
{
doNothing();
}

}

The advantage of the FIFO should be, that I donnot need this kind of delays, right? (I mean otherwise I could also use the TSIF Flag, but this is very time expensive...)
See the image for the FIFO and BRGconfiguration.
2467.attach
0 Likes
13 Replies
Not applicable
Seems that you and I have the same problem. The difference is that I am using the USIC for UART and not SPI.

Have you had any progress?
I've scoped this and I notice that it goes out on the bus, but the data is wrong. I've been trying to figure out the difference between all the entries for the
TBCTR register.

What are yours set to? Maybe we can compare and try to figure something out.
0 Likes
Not applicable
No not at all unfortunately.
For the TBCTR Register, see my attachements, I donnot know what could be wrong.... (sorry .. :rolleyes:)
0 Likes
Not applicable
Hi PeterMai,

just another question:
which software do you use as shown in your attachements?
thanks!
0 Likes
Not applicable
It is TRACE32 from LAUTERBACH Software.
0 Likes
Not applicable
yes it is,
so nobody has an idea? this means that everybody using a FIFO needs a delay ? ;(
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

The waits after the insertion of data in the FIFO are not needed.
I think the problem is that once the FIFO is full you are returning from the function without any error and the data is not sent.
With the wait you are actually making place in the FIFO before returning.

BTW: Have you look to the XMCLib examples?

Regards,
Jesus
0 Likes
Not applicable
the return without error is a good point. But unfortunately I never enter this case, so this is not the mistake.

Same error (no valid data without delay) within the following code. Now a full FIFO results in a while() loop

	
void disp_vSPI_TransmitWord(USIC_CH_TypeDef* USICX_CHX, const UINT8 data)
{
/* Flush the Transmit FIFO */
USICX_CHX->TRBSCR |= USIC_CH_TRBSCR_FLUSHTB_Msk;
while ((USICX_CHX->TRBSR & USIC_CH_TRBSR_TFULL_Msk) == TRUE)//CCM__O_TX_FIFO_FULL)
{
/* Wait until FIFO is having space for next entry */
}
USICX_CHX->IN[DISP_SPI_USICCH_MODE] = data;
//Without this delay, sending is not working
for ( UINT16 u16WaitCtr=0; u16WaitCtr < 230;u16WaitCtr++)
{

doNothing();
}
}
0 Likes
Not applicable
Jesus,

I have the same problem and I am using the XMCLib's. We opened our threads at almost the same time.

There has to be something, not-so-obvious, that we are both doing. On my thread, I gave Deni some of my code as an example.

-stv
0 Likes
Not applicable
Hi,

and did you get any smarter in the meantime?
0 Likes
Not applicable
I have not.. I had someone tell me to change my compiler flags to see if that changed anything. 🙂
0 Likes
User12775
Level 5
Level 5
First solution authored First like received
I also have the same problem for the FIFO. Now I am settled on the delay and hope to figure out the issue later.
0 Likes
Not applicable
Hello, guys.
The same problem with the USIC as the UART. I am using DAVE's UART app v.4.1.8.
Sometimes (not every time) UART sends wrong data, like in attached file (captured phisically by external UART-USB-VCP devices).

I'm blocking next transition by the binary semaphore and adding FreeRTOS delays betwen messages.
So, this is very unlikely FIFO overflow. Despite this, the device is not working properly.
It is curious that the error had never seen when sending short messages.


My UART app's settings:
Operation mode: Full Duplex
Desired speed [baud]: tryed 1200 and 9600
Data bits: 8, Stop bit: 1 stop bit, Parity selection: no parity

Advanced Settings:
Transmit mode: Interrupt
Receive mode: Interrupt
FIFO Settings
v Enable transmit FIFO Size: 32 ( does it mean 32*4 bytes?)
v Enable receive FIFO Size: 32
Interrupt Settings:
Priority and callbacks are fine.


My transmit function is as follows:

void ModemSendAT( const uint8_t* command, uint32_t length )
{
xSemaphoreTake(ModemUARTTransmitSemphr, portMAX_DELAY);
UART_Transmit(&MODEM_UART, (uint8_t*)command, length);
}



My end of transmit interrupt routing is as follows:

void ModemUARTEndOfTransmit( void )
{
BaseType_t xHigherPriorityTaskWoken;
xSemaphoreGiveFromISR(ModemUARTTransmitSemphr, &xHigherPriorityTaskWoken);
portEND_SWITCHING_ISR(xHigherPriorityTaskWoken);
}


Any ideas?
0 Likes
lock attach
Attachments are accessible only for community members.
Not applicable
I've forgot to add uart log.

Wrong data is at lines 57 and 136. Interesting, that they looks the same.
I'm actually trying to send "AT+CNMI=2,2,0,0,0" once again.
Previously, corrupted data appears on the first attempt, so I've added three attempts.
0 Likes