UART CTS signal not recovering from deasserted state on iMX7 running Linux

[AdrianEggenberger]

Hi

We are working on a project that uses an NXP iMX7 chip (MCIMX7D7DVM10SD). The system is run by Linux.

Connected to the UART6 we have a bluetooth module that communicates with UART @ 921200Baud with hardware flow control enabled.

While the communication normally is stable we have seen problems with the flow control recently. When the flow control asserts (caused e.g. by plugin of an USB drive to the system) we see that the CTS signal is asserted after reception of the 17th byte. The bluetooth module than stops sending data as expected. The problem is that the CTS signal is now asserted forever and doesn't release anymore. The system is still running but read of incoming data gives no new data as the flow control remains asserted.

I've attached images from a recorded issue where we see that the flow control remains set.

We thought that the CTS in this setup is asserted and deasserted by the iMX7 chip, right? The configuration of the trigger level is set to 16. What can cause the CTS line from beeing stuck at asserted state? Is there a known bug that matches this behavior?

Regards Adrian

[AdrianEggenberger]

Actually I'm not sure how I can find out what BSP we are using. I'm not very familiar with the way the image was built by Yocto. What should I look for when searching the version of the BSP?

Meanwhile we have some positiv tests with a new image built on kernel 5.15.32. With this new image the issue seems to be gone. The final tests need to be made, but it looks promising so far.
Our latest firmware is based on the receipe (is that the right word for it?) for the kernel as the latest image from embedded artists:
=> https://github.com/embeddedartists/ea-yocto-base/blob/ea-5.15.32/default.xml

On a development board for the "iMX7 Dual uCOM" from embedded artists we where able to reproduce the issue with there built images. They have different prepuilt images for this module. We tested a few of them with following results:
5.15.32    => Bug did NOT occur
5.10.72    => Bug did NOT occur
5.10.35    => Bug reproduced
5.4.47      => Bug reproduced

So it seems that between there releases 5.10.35 and 5.10.72 the issue was fixed.

It would be the best case if we could pinpoint to an explicit fix for this, but I assume it can also be the case that it has been fixed by other changes in the driver layer.
 

[Rita_Wang]

@AdrianEggenberger I see that for the 5.10.35 and 5.10.72 version BSP work well, so here recommend you to use the newer version BSP.

Wish you have a nice day and weekend

[Rita_Wang]

Which version BSP are you using?