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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

693 Views
AdrianEggenberger
Contributor I

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

Labels (2)
0 Kudos
3 Replies

644 Views
AdrianEggenberger
Contributor I

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.
 

0 Kudos

641 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

@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

0 Kudos

647 Views
Rita_Wang
NXP TechSupport
NXP TechSupport

Which version BSP are you using?

0 Kudos