Platform: i.MX 7Dual Applications Processor
Topic: Technical Support for 2nd generation of a product required (due to unclear or even contradictive UART/tty behaviour on embedded Linux)
I've been given the legacy of the preceeding and no longer existing/accessible developer team of my customer XXXX XXXXXXX XXXX XXXX, located in XXXXXXXX/Germany. Everything seems to work fine with the second generation of their product (XXXX) running under Embedded Linux on the hardware platform as described in the subject - except one of the tty devices / UARTS. I've been searching already for some days all through the files of the complete yocto folder tree with all possible search patterns I could think of being correct or related to our issue but unfortunately I was unable to find out why the problem as obeyed occurs. Further on, the software is documented in a really poor manner (just some source code comments - no external docs) what makes it even harder to find the root cause for a total newbie to the project as I am...
Here's the content of a mail of one of the developers of the customer themselves (translated from German - he's the developer of the Modbus Router as mentioned in his mail) that describes the issue quite clear:
"... the wrong baud rate is set for the Modbus interface at the lower terminals of the unit (device /dev/ttymxc4 or UART5, respective). That's why this Modbus interface does not work (whereas ttymxc3/UART4 used for the upper terminals of the unit works properly). As a temporary workaround we could use the upper terminals all through the development time but for the final product series we need both serial devices running fine.
When 115200 baud is set, 125000 baud is measured with the oscilloscope. If you set 1200 ... 57600 baud, you measure 70900 baud. The Modbus router (i.e. a piece of software running on the Linux OS) controls both interfaces (ttymxc3 and ttymxc4) in the same way and sets the baud rate at startup (as specified on the command line during the boot sequence). But this only works correctly with device /dev/ttymxc3. I checked the parameter transfer to the kernel in libmodbus with tcsetattr() again. It looks like a kernel-related hardware issue. Strangely enough, the baud rate becomes correct after exiting the Modbus router (this means: the affected device gets closed). If you send some data afterwards via some shell command, then the measured baud rate is correct."
As additional information I have to mention that the serial interface in question is driven in raw mode (not cooked mode). By means of multiplexing (i.e. changing to the corresponding operation mode), we are using the board's audio port as a UART to provide this additional sio on kernel/OS level.
Here's the output of uname -r:
Could anyone here think of any possible mistake/reason that could cause such a different behaviour on two almost equal devices? To me, it looks as if some register(s) has/have been set to some wrong value(s)... i.e. the wrong mode was selected or a wrong divisor has been programmed. Another possibility would be an unintended concurrent and interfering usage of the port in question and the corresponding registers... Thank you very much for your help and answer in advance - and sorry for my just mean English. ;-) Please don't hesitate and send me back your questions if you need further and more detailed information or my/our support.
Thank you and best regards,