Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Communication stuck if connecting to one UART only #20

Open
alessandrodn opened this issue Feb 4, 2024 · 9 comments
Open

Communication stuck if connecting to one UART only #20

alessandrodn opened this issue Feb 4, 2024 · 9 comments

Comments

@alessandrodn
Copy link

alessandrodn commented Feb 4, 2024

First of all, kudos for the project.

I have a device exposing two UARTS and I connect both the serials to the PICO.
I noticed that if I open a serial session (I use screen on macOS) to one UART only (either one of the two), the communication stuck after few bytes exchanged.
If I open the connection to the second UART, while the first one is frozen, the connection is resumed on both.

Please see attached screen recording.

Screen.Recording.2024-02-04.at.15.50.09.mov
@alessandrodn alessandrodn changed the title Communication stuck if connecting to UART1 only Communication stuck if connecting to one UART only Feb 4, 2024
@xxxajk
Copy link

xxxajk commented Mar 1, 2024

Did you try updating the pico SDK to HEAD? It includes lots of fixes, probably might fix it for you.
It's one of the first things I do when I run into problems.

@xxxajk
Copy link

xxxajk commented Mar 1, 2024

I was also able to recreate the same problem here on Linux, but there's specific conditions to trip the problem.

The communication packets have actually started, then stopped from the PC side...
...while there is a data flood on either or both channels from the UARTs.

This is caused by two bugs.

Basically the code spins waiting to unblock, which will never happen until the host catches up, it never will. Basically it gets stuck because...
...the silly read ISRs that end up in an endless loop.
This is because the data incoming from the UART is not discarded if the buffer is full, thus, the IRQ is never cleared.

The fix is to remove the infinite loop by dropping the UART data on the floor.

@xxxajk
Copy link

xxxajk commented Mar 1, 2024

Try this version and let me know if it works.
My changes are as follows:

UART0_TX 0
UART0_RX 1
UART0_LED_TX 19
UART0_LED_RX 18
   
UART1_TX 4
UART1_RX 5
UART1_LED_TX 17
UART1_LED_RX 16

It is also possible to send breaks with this firmware.

uart_bridge.uf2.zip

@Noltari
Copy link
Owner

Noltari commented Apr 11, 2024

Try this version and let me know if it works. My changes are as follows:

UART0_TX 0
UART0_RX 1
UART0_LED_TX 19
UART0_LED_RX 18
   
UART1_TX 4
UART1_RX 5
UART1_LED_TX 17
UART1_LED_RX 16

It is also possible to send breaks with this firmware.

uart_bridge.uf2.zip

@xxxajk it would help a lot if you could provide the modified source code with the fixes.

@xxxajk
Copy link

xxxajk commented Apr 14, 2024

Done.
https://github.com/xxxajk/pico-uart-bridge
If it is a fix for enough people, I'll do a pull request to here, although there's not a lot of activity here...

@Noltari
Copy link
Owner

Noltari commented Apr 15, 2024

Done.

https://github.com/xxxajk/pico-uart-bridge

Thanks!

If it is a fix for enough people, I'll do a pull request to here, although there's not a lot of activity here...

Yes, please, open a new PR with this

@xxxajk
Copy link

xxxajk commented Apr 15, 2024

Are you OK with the different pin setup?

This was referenced Apr 19, 2024
@alessandrodn
Copy link
Author

I can confirm that #25 fixes the issue 🎊

@xxxajk
Copy link

xxxajk commented Sep 28, 2024

Glad someone cherry picked it.
Couldn't stand the formatting at all, which doesn't follow best practices.
That's all good though, and why we got forks ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants