I can’t read or write to a UART in Torizon 6.7.0 with a Colibri iMX6DL, I feel I must be making a basic error. I am using the UART connected to pins 19 and 21 of the Colibri iMX6DL which I believe is UART_C and should correspond to /dev/colibri-uartc.
The board which I am using has LEDs connected to the RXD and TXD lines for that UART which allows me to see the LEDs flash when any data is sent or received. I swapped the module for another Colibri iMX6DL which is running WinCE. With that module I can send and receive data through UART_C and the LEDs on the board flash with each byte, so I know the hardware, the cable to the PC, and the terminal app on the PC are all working.
When using Torizon I tried the command echo -n "Hello!" > /dev/colibri-uartc from both the torizon user account in TorizonCore, and from inside a container which I shared that device too. I get no error message from the command, but no data is sent, and the LED does not flash. I also tried cat /dev/colibri-uartc and then sent data from the PC, but no data was received.
I also tried using open() and write() in C, with the same result.
Is there a configuration step that I am missing to enable the UART? Or to disable hardware handshaking perhaps? Do I need to modify the device tree to enable access to this UART?
The torizon user is a member of the dialout group, does that user account also need to be a member of the tty group?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello!
It sounds like you’re encountering some challenges with UART communication on your Colibri iMX6DL running Torizon 6.7.0. Let’s go through some steps to help resolve this issue:
Device Tree Configuration: Ensure that the device tree is correctly set up to enable UART_C. This involves verifying that the correct pin multiplexing is specified and that the UART interface is enabled. You might need to modify the device tree to ensure UART_C is not disabled or misconfigured.
Hardware Handshaking: Check if hardware handshaking is enabled by default. If your application doesn’t require it, you can disable it either in your application settings or through the device tree configuration.
User Permissions: Confirm that the user account has the necessary permissions to access /dev/colibri-uartc. Typically, being a member of the dialout group is sufficient. However, adding the user to the tty group can ensure full access.
Testing with Basic Commands: After verifying the above configurations, test the UART communication using basic commands like echo and cat to ensure data can be sent and received. This will help confirm that the UART is functioning correctly at a basic level.
Application Code: If you’re using C or another programming language, ensure your code correctly opens the device file and sets the appropriate parameters (such as baud rate and parity). Double-check that file descriptors are handled correctly and that write operations are properly executed.
By following these steps, you should be able to diagnose and fix the issue with UART_C on your Torizon setup. If problems persist, consider reviewing the specific configurations and code used to interact with the UART to identify any overlooked details.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
One other detail that might be relevant. This post is focused on UART_C but my board also has LEDs connected to UART_B on pins 36 and 38. I can drive data out of UART_B and flash those LEDs from a Colibri iMX6DL when running WinCE, but I can’t do it from Torizon when writing to dev/colibri-uartb.
Hi @alex.tx, I mentioned that I’m using Torizon 6.7.0 in the title of the topic, have I maybe misunderstood which version information it is you need? The full reply to uname -r is: 6.1.96-6.7.0+git.99e6a620de00
I have some notes from a few years ago where I used the UARTs on the Colibri iMX7 with Torizon 5.3.0 and it worked as expected. This does make me wonder if perhaps there is a problem with Torizon 6.7.0.
@alex.tx here’s another curious detail. I moved my Colibri iMX6DL to another board which routes UART_A and UART_C through RS232 transceivers to external connectors (With LEDs to indicate RS232 activity). When the module boots I can see the debug output from UART_A on the PC as expected. If I then SSH into TorizonCore and use this command: echo "Hello Alex!" > /dev/colibri-uarta
then I do see that text appear on my RS232 terminal as shown below. This is a bit surprising as the OS is using that same port as a terminal, and I thought I had to disable the terminal in order to access the port myself. This does prove that my cable and terminal app on the PC are actually working.
This seems to suggest that UART_A works as expected on the Colibri iMX6DL with Torizon 6.7.0 while UART_B and UART_C don’t seem to work. In our own board designs we use UART_C for communicating with the customer so that the customer isn’t exposed to the text which is sent out of UART_A while booting. So it’s UART_C that I need help with to get working.
I hadn’t noticed the messages about “invalid function pinctrl” before as I don’t usually monitor the output of UART_A. Are those messages normal, or an indication of a problem with the device tree which could be related to my problem?
Hi @alex.tx, I was testing this as you wrote your last comment. Those pinctrl error messages made me suspect the device tree too. I had a simple device tree overlay installed to allow pin 190 to be used as a GPIO. I performed a fresh install of Torizon to reset the device tree and now I can access the UARTs normally. I’ll try to reapply my simple device tree overlay next to see if that breaks the UARTs again.
@alex.tx I’ve done some experiments with Torizon 6.7.0, 6.8.0 and 7.0.0. After a clean install of each version of Torizon UART_B and UART_C work as expected and SODIMM_190 is not available as a GPIO pin. After I install my device tree overlay on each version of Torizon UART_B and UART_C stop working while SODIMM_190 does become available as a GPIO. There must be something wrong with either my device tree overlay, or the way I am building and deploying it. As that is quite a different issue than the one I started in this topic I think we should close this topic as being solved, and I’ll create a new question about my device tree overlay.
