LPUART1 TX FIFO Failed Hi all, I'm working with an S32K311 and a custom bare-metal driver for two LPUART instances configured identically (115200 8N1, TX/RX FIFO enabled, same init sequence). LPUART0 works perfectly with both TX and RX FIFOs enabled. LPUART1 does not: TX: a single write to DATA (or a single push while FIFO[TXFE]=1) results in the same byte being physically transmitted 3 times on the TX pin. This is not garbage/noise — it's the exact byte I wrote, repeated 3 times back-to-back. Verified with an oscilloscope/logic analyzer on the TX pin (GPIO71). RX: reception does not behave correctly while the RX FIFO is enabled on this instance either (no usable data comes back), unlike LPUART0. What I've already ruled out / verified: Baud rate / clock is correct: I do not see corrupted or misaligned characters, only the correct byte value duplicated 3 times, which points away from an oversampling/BAUD (OSR/SBR) miscalculation. Clock gating is enabled for both instances: the MC_ME peripheral clock request is enabled for LPUART0 and LPUART1 in the same way (same partition, sequential request IDs), and LPUART0 with the identical code path works fine. Workarounds found by trial and error: Disabling the TX FIFO (FIFO[TXFE]=0) on LPUART1 fixes the transmit issue (single frame per write, using STAT[TDRE] instead of WATER[TXCOUNT] for flow control). Leaving the RX FIFO enabled (FIFO[RXFE]=1) is required for RX to work on LPUART1 at all. So the only configuration that works on LPUART1 is: TX FIFO disabled, RX FIFO enabled — which is the opposite of LPUART0 (where both FIFOs enabled work fine), and obviously reduces TX throughput/burst capability. Questions: Is there a known erratum for the S32K311 LPUART1 instance (or a specific LPUART instance limitation) related to the TX FIFO causing duplicated frames? Is there any additional register/bit (beyond FIFO[TXFE], WATER, BAUD[TDMAE]) that needs different handling specifically for LPUART1 vs LPUART0 on this device? Has anyone else observed this same "byte transmitted 3 times when TX FIFO is enabled" behavior on a specific LPUART instance rather than all instances uniformly? Any pointers to the errata sheet, silicon revision notes, or a known workaround explanation would be greatly appreciated. Re: LPUART1 TX FIFO Failed Hi @ijm1,
I have seen unpredictable behavior in hardware modules when the ratios between clock domain frequencies do not match any of the supported clock options. The system clock must always be configured according to one of the valid clocking options listed in the RM.
The key requirement is that the ratios between the clocks remain exactly as defined.
As stated under Table 151 (For S32K312, S32K311, and S32K310) in the RM:
"…any clock frequency selected must adhere to the same clock divider ratios shown in System clocking configurations."
Could you please verify this first?
Regards, Daniel
View full article