Latency receive on serial link wec2013

Hi everyone,
I test latency for receive datas on serial link.

You can see on this picture we have 2ms delay for read value on Wec2013 !

On wec6 we have 400µs.
I join my source code.
ConsoleApplication1.cpp (3.4 KB)

Can you help me please,

Colibri Imx6
Boot version 1.6
OS: 1.6
Uart 2

What are the Ch1 and the Ch2?

CH1 = rx wire colibri
CH2 = tx wire colibri

To have
According to Microsoft documentation, to make ReadFile return after first byte received you shouold
" sets ReadIntervalTimeout and ReadTotalTimeoutMultiplier to MAXDWORD and sets ReadTotalTimeoutConstant to a value greater than zero and less than MAXDWORD"
But in you app you have only ReadIntervalTimeout set to MAXDWORD. All other timeouts are zero

	COMMTIMEOUTS newTimeouts = { MAXDWORD,0,0,0,0 };

	if (!SetCommTimeouts(*serialHandle, &newTimeouts))

Hi alex,
Thank your help.
I tried with the following instruction COMMTIMEOUTS newTimeouts = { MAXDWORD,MAXDWORD,1,0,0 };
unfortunatly, result is the same, I still have to 2ms delay on read.

@alex.tx have you more information about this subject ?

Thank you?

Hi @alex.tx

We performed more test on this issue and I want to inform you about where we are.

We executed exactly the same appliaction on our legacy hardware, IMX27 and wince6 (home made BSP), delay mesured is arround 470µs (see attached snapshot).

So this is showing an issue with this application executed on Colibri IMX6 (Solo and Dual) with WEC2013.

Toradex help will be appreciated.

Could you try to set a higher thread priority (lower than 248) using CeSetThreadPriority() ?

Range Description
zero through 96 Reserved for real-time drivers.
97 through 152 Used by default device drivers.
153 through 247 Reserved for real-time below drivers.
248 through 255 Maps to non-real-time priorities for applications.

Hi, we made some test with different thread priority. We got the same result for all configuration. Thread priority changes does not reduce the latensy

Could you share a source code?


I attach my source code on this reply

ConsoleApplication1.cpp (4.9 KB)

Hi @jcy ,

I just now tested with your code on Col iMX6S with CE7 and found the same latency (2ms) as observed by you on WCE2013.

For Col iMX6, we don’t have CE6 image available so , the CE6 you are talking about is your own built image that you tested on some different hardware (IMX27) ?

Hi @alex.tx ,

Yes I’m talking about a bone we made ourselves and on different hardware imx27.

The CE_THREAD_PRIO_256_ABOVE_NORMAL priority you are using has value 250.

Please try setting the priority to 153 first. Then, if that helps, start increasing the value until the latency becomes too ршпр.

Hi @sahil.tx and @alex.tx

Good to see you are able to reproduce the issue, jcy mentioned a test we made on wince6/IMX27, he was talking about a legacy product we have where BSP was made internally.

Related to Alex.tx suggestion, we made tests with different priorities (from 153 to 255) unfortunately results were the same each time, we had 2ms delay on read.

Thanks for your help

Hi @mblac7 ,

Referring to the iMX6 reference manual for UART Control registers.
For UART2, Modifying the following register helped in reducing the response time.

UART2_UFCR ( Absolute Address : 0x021e8090 ).
RXTL (5-0) <— Set this to 1
You can modify the register value using our RegAccessTool or can use MapMem library to modify the register value in your source code.


DWORD UART2_UFCR;      // address : 0x021e8090
DWORD *reg;

reg = (DWORD *)Map_MapMemory((DWORD)0x021e8090, 4);
UART2_UFCR = *reg;

// read the register value
wprintf(L"UART2_UFCR =\r\n\t0x%08X\r\n", Map_MemoryRead(reg,32));  // It came out to be 0x000022C8

//write to the register (RXTL = 0x01)
Map_MemoryWrite(reg, (DWORD)0x000022C1, 32);

// rest is your code for rx/tx

The following output I got after making the above mentioned changes. Its around 0.1ms

Let me know if this solves the issue.

1 Like

Hi Sahil.tx

Thanks a lot for your comment, first test I made decreased delay to something around 170µs so it is ok for us.
Thanks again for your help.