In post 8 the trace is showing that the analyzer is detecting a framing error being generated by the transmitter when it sends the ']' and disables TXEN.DISABLE transmitter causes a FRAMING ERROR on 1st PIC, but not on Ack message on 2nd PIC
The TX data line should never idle low... that looks like a serial BREAK condition to the receiving side and will likely generate framing and overrun errors on that end.
A framing error by itself doesn't really cause any issues, but an overrun error will stop everything in its tracks until you clear the error. I see you have 'DEFINE HSER_CLROERR 1', so hopefully that's trying to take care of it, but maybe not. The way you have the receive arranged if things get out of sync then it might lock up waiting for something that's not going to happen.
As I said, if setting TXEN=0 causes the TX data line to go low that you need to change the TRIS/LAT register settings in your setup to stop that from happening.
Try initializing the pins with LATC6 = 1 and TRISC6 = 1. That should set the default state of the TX pin to high, which is the proper idle state.
You'll have to rethink all of this later when you try to add more devices since you can't just tie multiple TX outputs together, even if they're "disabled".
They would need to be tri-state/open-drain in the idle state, not driven high or low.
Bookmarks