Quantcast
Channel: Forum - Recent Threads
Viewing all articles
Browse latest Browse all 5781

Problem with Uart FIFO at 921600 Baud

$
0
0

Hello,

 

I have a problem to get a serial communication at 921 kBd to work.

My setup is:

- Synergy S7 working at ICLK 120 MHz and PCLKA 120 MHz

- Synergy SSP 1.20

- Uart with 921600 baud 8 databits 1 stopbit parity none, DTC disabled

- Interrupt of the uart is 5 which is the highest priority in my system

  (except ThreadX uses some higher internal which I don't know)

- Uart interrupt get's fired after 15 bytes in the hardware FIFO

  (default configuration in the driver)

- Communication Framework above the Uart Driver is used

  (read Input queue is 1024 Bytes)

- Compiler Optimization is -Og because I need to debug

 

The number of bytes that I have to receive is of an arbitrary length.

 

This is an example of an bunch of Bytes the synergy Controller has to receive.

Line 4 an 5 are test pins i toggle in the Driver routine r_sci_uart.c

Line 4 is set at the beginning of sci_uart_rxi_isr and cleared at the end.

Line 5 is set before and after the macro HW_SCI_RDFClear(p_sci_reg) in the

routine r_sci_uart_rxi_read_no_Transfer.

 

Here the problem in detail:

Right after the Byte with value '38' the Interrupt gets fired and begins to store

the received 15 Bytes in the software read input queue provided by the SSP.

Meanwhile another 3 Bytes with the values '36', '39' and '04' are comming in.

Byte with value '04' is the last one and so after a period of 1.5 * byte time

the DR Flag in the SSR_FIFO Register get 's set.

 

Explanation from HW Manual:

DR flag (Receive Data Ready Flag)

The DR flag indicates that the amount of data stored in the Receive FIFO Data Register (FRDRHL) falls below the

specified receive triggering number, and that no next data is received after 15 ETU from the last stop bit in asynchronous

mode. This flag is only valid in asynchronous mode, including multi-processor mode, and when the FIFO is selected.

In clock synchronous mode, this flag is not set to 1.

[Setting condition]

When FRDRHL contains less data than the specified receive triggering number, and no next data was received after

15 ETU*1 from the last stop bit, and the SSR_FIFO.FER and SSR_FIFO.PER flags are 0.

[Clearing conditions]

When 1 is read from DR, then 0 is written to DR after all received data is read

When the FCR.FM bit is switched from 0 to 1.

Note 1. ETU: elementary time unit. This is equivalent to 1.5 frames in the 8-bit format with one stop bit.

The DR flag only is set to 1 when FIFO is selected in asynchronous mode, including multi-processor mode. It

does not set to 1 in other operation modes.

 

 

But at the end of the Interrupt the flags  SSR_FIFO.DR and SSR_FIFO.RDF

both get cleared:

 

 

So after the interrupt no further interrupt for the bytes '36', '39' and '04'

is triggered and the bytes are lost!!

 

I tried several combinations for the clearing of RDF and DR flag, for

example clearing the DR flag at the beginning of the ISR or just

clearing the flags if they are set and so on but nothing worked reliable

and some combinations even work at all.

 

It seems that the ISR has to be finished before a DR flag Interrupt

could shine up. At 921kBd this means 2.5 * 10.85µs (byte time)

1 for a last single byte to reecive at the end and 1.5 for triggering the DR flag.

 

Did I really need to speed up the processor to 240 MHz (!!) and also set the

trigger level of the  FIFO to 3, which reduces the processing time for the

bytes received, to get this critical timing working ?

 

For me it seems that this hardware FIFO and his flags are buggy !

 

Is there any solution/workaround for this problem ?

 

Best regards

Heinz

 

 

 

 

 

 


Viewing all articles
Browse latest Browse all 5781

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>