on our carrier board we use SODIMM 94 (RTS), 29 (RX) and 37 (TX) for RS485. They are all not the default pins.
However sending data is ok. Also receiving works but there is a unexpected behavior.
If we call ReadFile() to get data from the buffer we do not get all the data or have to call ReadFile() more than once.
The function often returns 0 in number of bytes received but thats wrong. We know that there is data in the buffer.
With the default pins on eval board everything works fine. Only the mentioned not default pins make some problems.
We use this project to send an receive.
I will try to reproduce the problem.
You mentioned that it is working fine with the default pins, therefore the problem seems to be related to pin multiplexing. Can you please provide me the details how you switch to the pins {94,29,37}?
Thanks for looking into that.
I switch the pins with the program iMX7_GPIO_V1.0_WEC2013.exe provided by Toradex.
With an oscilloscope I also see data on RX and TX pin.
Read data with function ReadFile() makes some troubles.
Changing the pin multiplexing with the GpioConfig Tool is not always sufficient.
In your case, I suspect that multiple GPIOs are configured to be the same function (e.g. UART5_RX_DATA). You might be able to resolve it manually by configuring a conflicting pin to any other alternate function.
What you should do is to modify the registry settings under
[HKLM\Drivers\Builtin\COM4\Pinout_Default]
The driver will take care of the proper multiplexing. Don’t forget to save the registry
I changed the pins in registry but the behavior is the same.
The ReadFile() function do not return all the received bytes.
Could it be a driver problem?
To point 1: We use RTS signal but we do not lose data.
To point 2: We do not use multiple senders. Just a IMX7D and a Windows PC with a terminal program.
Because the problem is difficult to describe, I uploaded a video (you can download here) and added some descriptions for better understanding.
Sending is fine, there are no problems.
I send ‘12345’ from my windows PC.
I call the ‘ReadFile’ method three times, but there is no data in the buffer.
I send again ‘12345’ and call the ‘ReadFile’ method. In my receive buffer there is some data. But data starts with ‘\0’ then ‘12345’ again ‘\0’ and then just a ‘1’. If I call again the ‘ReadFile’ method, I always get an empty buffer.
Again I send ‘12345’ and call ‘ReadFile’. Receive buffer = ‘2345 \0 123’. I know that there is missing a ‘45’ but calling ‘ReadFile’ don’t gets the data.
Again I send ‘12345’ and call ‘ReadFile’. Receive buffer = ‘45 \0 12345’. Now I received the missing ‘45’ and the rest of the data.
Conclusion: The data is sent correct and no data is lost. But with the ‘ReadFile’ function I do not get all the data respectively I have to send always data to receive everything.
I’m still investigating. So far I wasn’t able to see the problem, even though I used your test application and the same terminal program.
Pin Directions
There’s one thing I wanted to mention because you probably didn’t use it as you wanted:
NXP uses a confusing definition for the UART AltFn names: The Signal UART5_TX and uart5.RTS_Bare Inputs to the Colibri module, while uart5. UART5_RX_DATA is an output of the Colibri module!
Possible Issue
As the subject of this post is about “RS485”, I assume you connected the RTS signal to your logic to enable / disable the driver, and maybe also do flow control for the communication with the PC. As I stated above, the RTS pin you used on the Colibri is an input, and therefore floating to an undefined level. Is it possible that your hardware is now done in a way, that the PC interprets this signal as part of the hardware flow control, and delays the sending of characters?
Maybe you have the possibility of measuring the PC-to-Colibri UART5_TX signal to assure that the data is transmitted by the PC as soon as you send it from the terminal program?
Next Steps
Is there any additional configuration (except the pinout) which you made that could be important for me to reproduce the same environment as yours?
Don’t mind. From what I saw in the video, my first thought would also be a software issue as the source of the problem.
I’m glad to hear that you found the issue and can proceed with your project.
