Hello,
We have a huge problem with the COM1 on our devices running CE7 2.4 on T20 V1.2B, that is halting our production right now.
Our main board features a TMS320F28335 micro, and our software communicates with it through the COM1.
When the T20 V1.2B has been introduced, we were told that the CE7 OS needed to be at least up to image 2.2 to support the new hw, and since we used 2.1, we decided to move to the latest available at the time, 2.4.
The “firmware” running on the micro and the “software” running on the CE use the serial port at baud rate 921600, but only some features make the firmware send back data at such high rates.
We only recently discovered that, while the other features work fine, when these features are used and the firmware is sending back a lot of data, the software apparently can’t keep up, and is slower to read, causing issues.
We have tested several releases of our software on both the T20 V1.2A (with CE 2.1) and 1.2B (with CE 2.4) hw versions and we can confirm this simply does not happen on the previous module.
Could it be somehow related to what I can read here, about the BaudRateAccuracy of 2%?
In the tegra uart baudrates excel file linked there, I read the PLLP clock actual baudrate would be lower than more than 2%, but the few mentions of this in the T20 Datasheet is at page 41, on how to set SODIMM Pin 75.
I checked this pin with the GPIOConfig tool on the T20 V1.2B I’m testing, and it is set to PLLC_OUT1 (“general purpose PLL frequency lower or equal 600 MHz”).
How can I even find out which clock the uart is choosing, and at which frequency is working? is it something I have to ask to my colleagues that can understand our board design? How does it work?
Please help!
Thank you.
Colibri T20 256MB V1.2B (Previously V1.2A)
Custom Board
WEC7 Image 2.4 (Previously 2.1)
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello!
I understand you’re experiencing UART timing issues with the T20 V1.2B module. While specific details about this module’s UART implementation might not be readily available, I can offer some general guidance that could help you troubleshoot the issue.
The maximum UART baud rate supported by similar modules is typically up to 921,600 bps. At these high baud rates, maintaining timing accuracy is crucial for reliable communication.
Here are some general features and configurations to consider for UART:
- Programmable Baud-Rate Generator: Ensure that the baud rate is set correctly and matches the expected rate for your application.
- Independent Transmit and Receive Control: Verify that both transmit and receive settings are configured properly.
- 64-Byte Transmit/Receive FIFO Buffers: Check if the FIFO buffers are enabled and configured to handle the data flow efficiently.
- Programmable Receive FIFO Trigger Threshold: Adjust the trigger threshold to optimize data handling.
For your specific situation with the T20 V1.2B and WEC7 Image 2.4, I suggest:
- Reviewing the UART FIFO buffer settings to ensure they are optimized for your data rate.
- Verifying the configuration of the baud rate generator to ensure it aligns with your communication requirements.
If you need further assistance, I can provide more general information on UART communication concepts that might be useful.
Best regards,
Toradex AI Assistant.
I want to add additional information:
- I don’t think my original hypothesis about the baud rate accuracy is relevant anymore, as I didn’t mention that what is read from the COM1 gets read slower than expected but there is no malformed data;
- I have compared the config blocks settings with the ConfigBlockEditor tool, the GPIO and SODIMM pins settings with the GPIOConfig tool, and partially compared the registry. The Pin settings are identical, there is no relevant change between the two config blocks, and by myself I was unable to find anything relevant in the registry, which I attached.
- The only new registry setting I found that was not present in the previous OS image, that I can think could be relevant, is the “LoadAsync” key. I tried disabling it, to no avail;
T20V 1.2B new keys in Drivers BuiltIn Serial1.reg (2.6 KB)
T20V1.2A.reg (1.0 MB)
T20V1.2B.reg (1.1 MB)
I tried different approaches and workarounds to the issue, I’d like to report my findings:
- I recreated a custom image starting from a CE7 2.2 image this time, to minimize the distance between this and our previous custom image. The issue is still present, so it seems not to be caused by changes made in newer versions (CE7 2.3 and 2.4). This should help narrow your research down.
- I recreated a custom image starting from a CE7 2.1 on board of an old T20 V1.2A, the same version we had in our previous custom image. In this image, the issue is not present. I was trying to check if I missed a few configurations when drafting our image customization guide. I was hoping this was the case, but it’s not, as both our historical and (this) new 2.1 custom images don’t have the issue, while new custom images (the 2.2 and 2.4 I tried) both have the issue.
- During all of these and previous tests against this issue, our software always featured Toradex CE libraries 2.1. I tried updating them to the latest (2.6), recompiling our software, and running it on the T20 V1.2B with CE7 2.4 custom image on board, to no avail: the issue is still present!
- I never tried a CE7 custom image 2.1 on a T20 V1.2B, there would be no point, and issues are expected, as on images >=2.2 can handle the new FlashDisk hw.
- Did you happen to change anything in the FFUART driver, or similar parts of the new CE7 images?
We haven’t made any changes or fixes related to UART since version 2.1, as you can see here.
Could you please clarify how you determined that the UART communication is slow? Are you observing buffer overruns, or is something else happening?
If possible, could you provide a minimal, reproducible test case that we can use to investigate the issue using two Colibri modules?
The fact that the issue we experienced showed up after we started using the T20 V1.2B, and is nor present on the V1.2A, have driven us off the road, to the point we even opened this ticket.
We have recently found older releases of our software where the issue is not present, not even on the V1.2B.
We have investigated more in order to find the latest software version free of this bug and the older version with the bug released after that, and to compare the two.
We found a small change there: at first apparently unrelated, reverting it made the bug disappear.
The same UI we used to repeatedly test the presence/absence of this bug, hosts a periodic task (managed with the help of CWnd::SetTImer and alike), that access the i2c bus to check if an accessory is connected.
It used to do so every 200ms, and the frequency got changed to 100ms.
I don’t know the reason for this cause-effect relationship yet, I’m assuming one of the following:
- 10 times per second is too much, adding overload to the overall workload of the T20, and the result is that the COM1 port reading thread falls behind, accumulating data to read and slowing down our software;
- some other yet unexplained weird behaviour, perhaps related to a flaw in our custom board design;
Now, the fact remains that, even though this change was present in our software since a few releases back, the issue remained dormant until we started using it on V1.2B.
But ultimately, we were able to apply a fix that resides only on our software, without having to change anything on the CE7 OS 2.4 image we previously prepared.
We can close this ticket (at least for now, finger crossed).
