Wohlwollende Mecker:
- Wenn Du so etwas herausgibst, tue dem Leser zumindest den Gefallen und schreibe bei Verwendung mehrerer UARTS, welche denn überhaupt das Problem ist (es scheint UART_C1 zu sein, hat mich 5 min. gekostet)
- Man kann auch mehrere Codemodule verwenden. Ein einzelnes Modul bietet sich für so eine PeerToPeer-Kommunikation an. Ich habe gerade wieder drei mal durch den gesamten Sermon gescrollt, bis ich endlich irgendwo mittendrin die Ini-Routine der UART gefunden habe.
- Du hast zwischen den eingehenden Zeichen (128kBaud) bei 32MHz ca. 2500 Befehlszyklen. Mit etwas Nebenbeschäftigung (andere Interrupts) wird eine Auswertung/ Statemachine in der RxD-ISR schnell eng. Nutze also entweder den DMA oder schreibe Deine eingehenden Daten in der RxD-ISR einfach nur in einen Fifo (einen Ringpuffer mit Lese- und Schreibindex), den Du mit einem langsamen (10..50ms) Low_Prio-Timer-Interrupt auswertest. Damit der RxD-Interrupt diese längerdauernde zyklische Poll-Auswertung unterbrechen kann, setzt Du ihn auf High_Prio.

Letztlich lässt sich die Sache bei solchen Protokollen ohne die Abhängigkeit auf eine ISR besser und komfortabler im Debugger/Simulator testen. Ich z.B. habe den Sensor nicht und könnte Deinen Fehler maximal anhand eines Hexdumps Deiner Daten analysieren.

Alte Programmiererweisheit: Länger als eine halbe Stunde auf Code zu starren, bringt nix. Meist hat man in der Zeit den passenden Test dazu bereits geschrieben.