AM2432: AM2432: UART register access time

Hello Johannes,

The subject matter expert is currently out of office for this week. Please expect a delayed response. Thanks for your patience.

Regards,

Anil.

Hi Anil,

are there any updates on the issue?

Best regards

Johannes

Hi Johannes,

Johannes von Löwis said:

We have the following code in one of our ISRs on core R5_1_0 that takes quite long to execute:

What else is running in the ISR? What is the priority of the ISR? Is the FIFO empty when you are trying to read the character?

How are sending data to the UART?

The code running on F280021 is also executed from ISR context?

Regards,

Tushar

Tushar Thakur said:

What else is running in the ISR?

Before we read from RX FIFO we write 8 bytes to TX FIFO register T_HR.  After reading from RX FIFO there is some control code of which I don't see how it could be relevant to the register read timing my question was about.

Tushar Thakur said:

What is the priority of the ISR?

It is an EPWM initiated FIQ with priority 5. When the quoted code is interrupted by another ISR I see times > 2000*1.25ns.

Tushar Thakur said:

Is the FIFO empty when you are trying to read the character?

The quoted code is actually part of a loop where we typically read 12 bytes from the FIFO (as long as the FIFO isn't empty according to register LSR bit FIFO_E).

Tushar Thakur said:

How are sending data to the UART?

What do you mean by that?

Tushar Thakur said:

The code running on F280021 is also executed from ISR context?

Yes.

Best regards

Johannes

Hi Johannes,

Johannes von Löwis said:

When the quoted code is interrupted by another ISR I see times > 2000*1.25ns.

Sorry, I don't understand the above statement. Can you please elaborate?

The code currently is in ISR or another ISR is preempting it?

Johannes von Löwis said:

What do you mean by that?

I was asking how the data is sent to the UART terminal/port?

Regards,

Tushar

Hi Johannes,

Also can you please confirm are the above results observed when the project is build in release profile?

If not, please build it for release profile and share the results?

Regards,

Tushar

Example_demonstrating_long_UART_register_access_times.zip

I have modified the uart_echo_polling_lld_am243x-evm_r5fss0-0_nortos_ti-arm-clang example from mcu-plus-sdk to demonstrate the problem.

It essentially does the following:

1. Wait for the user to enter 8 characters (it waits until they have arrived in UART RX FIFO).
2. Read the data using the API function UART_lld_read() and measure the time it takes.
3. Ask the user to enter 8 more characters and wait until they have arrived in UART RX FIFO.
4. Read the data directly from UART FIFO register RHR and measure the time it takes.

This is the output I get:

This is uart echo test polling mode
Receives 2 x 8 characters then echo's back. Please input 8 characters..
12345678
Time to read 8 chars using UART_lld_read(): readTime=17221 1.25ns cycles.
Enter another 8 characters!
12345678
Time to read 8 chars directly from UART FIFO register RHR: readTime=2152 1.25ns cycles!

The 17221 cycles the API function takes to read 8 chars is insanely long!

But also reading the 8 bytes directly from FIFO register takes 2152 cycles (2.69 µs). This is much longer than we had expected!

Please tell us how to get the data quicker. We seriously hope it is only because of a misconfiguration on our side.

Best regards

Johannes

Hi Tushar,

have you been able to reproduce the issue I described?

Best regards

Johannes

Hi,

I will be taking this issue forward.

Allow me few days to reproduce this with the test code which you have sent out.

Regards,

Vaibhav

Hello Johannes,

Can you please confirm the above results are captured in debug build or release build?

If you captured results in the debug build try to capture same results in release build ?

Regards,

Anil.

Hello Anil,

I reproduced the result with Johannes' project. The time measurements were:

Debug:

Time to read 8 chars using UART_lld_read(): readTime=21942 1.25ns cycles.<\r><\n>
Time to read 8 chars directly from UART FIFO register RHR: readTime=2221 1.25ns cycles!<\r><\n>

Release:

Time to read 8 chars using UART_lld_read(): readTime=17215 1.25ns cycles.<\r><\n>
Time to read 8 chars directly from UART FIFO register RHR: readTime=2139 1.25ns cycles!<\r><\n>

Which measurements do you get?

From my point of view, the compiler settings have only very little influence here. Especially when we access the UART_RHR bare-metal.

We need information on the internal access times of the AM243x SOC and how to modify them. 

BR
Alexander

Hi,

I have been able to reproduce this on my setup on the TI EVM.

I have run this on AM64x-SK and not on AM243x-EVM as the drivers of the UART are mostly same. I have been able to get similar results.

Allow me sometime to analyze this issue.

Regards,

Vaibhav

Hello Vaibhav,

I don't think we can debug further this issue because the R5F core is taking almost ~21 usc to read 8 bytes from the FIFO in release mode with the TI API.

The UARt ICLK runs at 125MHz and can't increase the UART I CLK more than 125MHz.

We need to check with the internal team to discuss further the test results.

Regards,

Anil.

Hello Johannes/Alexander,

Can you please  keep the FIFO read code  and read buffers  on the TCM rather than MSRAM and see how much time is improved in release build ?

Regards,

Anil.

Hello Anil,

still not much of an improvement:

Release Build, Map file:

00000041  uart_echo_polling_lld   
00000740  gUartReceiveBuffer  

the result was:

Time to read 8 chars using UART_lld_read(): readTime=17191 1.25ns cycles.<\r><\n>
Time to read 8 chars directly from UART FIFO register RHR: readTime=2159 1.25ns cycles!

BR
Alexander

Hello Alexander/Future readers ,

The above results with FIFO mode reading data 8 times to the RHR register and SOC took almost 2.6usec to complete its operation.

This is acceptable and, beyond this, time can't decrease further.

The SOC can take almost 200nsec - 400nsec to read one 32bit of data.

Here, in the above example, the user is reading data to 8 bytes of data, and it will take almost 8 * 0.2usec or 8 * 0.4usec = 1.6usec or 3.2usec.

If a user wants to speed up the UART processing, then the user should go with DMA and when the user goes with DMA, then if the UART data size is fewer bytes, like 8 or 12 bytes, then there is no benefit to going with DMA as well, because to start the DMA, SOC need to control the DMA start register and which is 64bit and to complete this operation SOC may take almost 0.4usec time to 0.8usec time and along with this user should have penalty for the cache operations for write and read cycles. So, the DMA is not much improved when going with lower bytes.

Regards,

Anil.