Hi,
On the QBlissA9r2 (quad core) I get Overruns while on the QBlissA9 I have no problems using the same software.
So I enabled DMA as in your post about UART performance.
Is there an indication in the log to check if it is enabled? The overruns persists even with DMA registry setting and I know on the r2 there is a different UART numbering (so I tried both UART settings in registry)
At startup the device reads several 4k messages from serial port at 460k baud
Hello, do you use your custom kernel or any standard?
Additionally to enabel DMA you may try to set thread priorities for driver and inside application were you handle UART communication.
For driver use e.g.
reg open \drivers\builtin\qblissa9r2\<your uart>
reg set value Priority256 dword 101
reg save
reboot
Inside application use for communication thread "CeSetThreadPriority(..., 102)".
Hope this helps.
PS:
>> different UART numbering (so I tried both UART settings in registry)
<< You can identify UART in Registry by check if Registry value "index" you use in application by COM<index> is the same as under HKLM\drivers\builtin\qblissa9r2\<your uart>.
This is the custom kernel.
I tried again this but still overruns on the second 4k datablock received with DMA and prio set.
The OpenNetCF library serial port is used. It sets threadpriority.Highest.
Seems that r2 has problem, but I really like to know if DMA is enabled on the non-r2 we use in production. Do I check by seeing till which baud rate I can go?
Like to get r2 board working
Hello
>> It sets threadpriority.Highest.
<< This does not work. It uses SetThreadPriority and support only Priorities from 248 to 255.
You have to "dll import" CeSetThreadPriorty.
>> Seems that r2 has problem
<< Maybe, but i don't believe HW and SW for UART are very very similar.
May WLAN driver or dependencies may have higher prio that may cause the issue or similay config differencies between A9 and A9R2(?) Below prio 103 only few drivers active.
>> but I really like to know if DMA is enabled on the non-r2 we use in production
<< We can only check registry no other API avail.
Reg open \drivers\builtin\<boardname>\UART<myone>
Reg set value UseDMA dword 1
Reg save
Reboot
>> till which baud rate I can go?
Under c++ i test up to 921600Baud under .Net there may be a limitation by framework SW.
ok, regardless of these settings (I tried them in every way) I have still Overrun errors on the r2 board.
Under which conditions does the r2 produce this Overrun error? The r1 board does not produce it, I have never seen it when I run the exact same software.
We are not using this r2 in production but I am curious about this error and why it happens on r2 and not on r1. Have we hit a limitation?
According documentation I can't do anything about such an error. It comes from the UART driver itself.
BTW is the DMA setting 'RXDMAEnable' or 'UseDMA' ?
Hello,
- the Registry setting on IMX6 is "UseDMA" on Vybrid we have separat DMA for RX and TX only here we have the prefix RX and TX.
- Which UART you are using on armStoneA9 and armStoneA9R2, and do you use RTS/CTS. Maybe i found some issues in the code.
- >>Under which conditions does the r2 produce this Overrun error?
<< Which OS function do you use to detect it, "ClearCommError"?
We're on QBlissA9.
I've used both UseDMA and RXDMAEnable so we can disregard it.
Yes it the normal Windows API. CLearCommError and WaitCommEvent. It is actually the code from OpenNETCF.IO.Serial.Port
Ok sorry, but what's about:
- which UART<x> you are using on QBlissA9 and QBlissA9R2, and do you use RTS/CTS. Maybe i found some issues in the code.
Forgot to mention we're not using RTS/CTS
Using COM2 which I believe is mapped to UART2 on A9 and UART3 on A9r2 (if this wasn't the case it wouldn't work at all)
And just had an Overrun on the r1 also at first (second time running it was not produced)
Is there an update on this? Can you confirm it is a driver problem?
No sorry, no update.
Expected next week I can test it.
>> Can you confirm it is a driver problem?
<< Think this is a matter of definition. In genernal neigther HW nor SW buffer has a size of 4k. So if you got 4k at once you have to clear the buffers fast enough from you application.
'Overrun' error is sporadically shown on the r1 board that we use. On r2 error is always thrown.
This overrun has to do with the HW buffer or OS driver buffer. Not the application SW buffer.
Have you done these test?
Sorry I did not test it. I am still busy in other projects. But I await to get the same results as you uing .NET. So wilI trust your statements.
All UARTs on imx6 use the same size for HW buffer (32 bytes) also I see no other property which may cause this issue on HW side.
The SW buffer is 2048 bytes. This is much lower than one of your data junks. I attach you a driver with 10kB SW buffer size. Does it work better? You should see the message "Rx Buffer Length %d Bytes" while this driver is loaded.
Nevertheless, I still assume it is a priority issue - but you did allready a lot of tests without success ... so I am a bit perplexed. Is there a limit for the data junks so that it starts working without overflows? You may also test by redirect "ndcucfg" to this port.
Thanks for the csp file with the increased buffer, however we don't make the OS image ourselves. Can I somehow use this file and load it on the system? Or can you build the image with the increased buffer so I can test it?
Hello,
just copy the file to ffsdisk and change Registry value for DLL under HKLM/drivers/builtin/QBissA9r2/UART<x>. Ffsdisk is a search path but if you would like to use the default name "csp_serial.dll" (this file is still under \windows) you have to include the path too.
You should see the serial boot message "Rx Buffer Length %d Bytes" while this driver is loaded.
ok, this works and I see improvement in the serial comms of the application. The application gets sent 16x 4k chunks without any Ack/Nak of individual packets.
Previously it occasionally missed packets and either the retry was correct or I got an overrun reported in the .net stack.
I guess we reached some critical point with the packet size of 4k. With the driver having a buffer of 2k it meant the application at 460kBaud had to clear this buffer in about 40ms. The application uses the OpenNet serial port which is not highly efficient but at least it uses a dedicated receive thread. I guess the differences (QBliss vs QBlissR2) in observed behavior in this can be explained because of time spent in thread context switch (which might be different in both versions).
With the 10k buffer it has more time taking in the data sent in quick succession. I would be happy to run with this.
Can you replace the original csp_serial.dll in our custom OS image with this 10k version?
Ok, I can implement this driver into your image.
Think i can provide it next week - if not come back;).
Hello,
you can download and test the new kernel. Please check if it fulfills your requirements. I did register the "new" driver on QBlissA9/A9r2 for COM2: only.
