Soft UART at 19200 baud works only when RTT logging is enabled

[Ehsan01]

Here is a properly structured issue report in professional English.

---

Project ID

SOFTUART-NRF52-19200-RTT-DEPENDENCY

---

Subject

Soft UART at 19200 baud works only when RTT logging is enabled

---

Description

During development of a software UART (bit-banging implementation using nrfx_timer) on the nRF52832 (nRF52 DK), an issue was observed where communication at 19200 baud rate operates correctly only when SEGGER RTT logging is enabled.

When RTT is disabled, the Soft UART receiver experiences frequent framing errors and unstable communication. However, at 9600 baud, communication remains stable regardless of RTT being enabled or disabled.

Observed Behavior

• 9600 baud → Stable with or without RTT

• 19200 baud + RTT enabled → Stable

• 19200 baud + RTT disabled → Frequent framing errors

• Framing error counter increases continuously when RTT is disabled

Technical Context

• MCU: nRF52832

• SDK: nRF Connect SDK v3.1.0

• Soft UART implemented using:

  • GPIO interrupt for start-bit detection

  • nrfx_timer (TIMER1) for bit sampling

• Sampling is based on calculated bit timing:

  • BIT_TIME_US ≈ 52 µs at 19200 baud

  • FIRST_SAMPLE ≈ 1.5 × bit time (with latency compensation)

Root Cause Analysis

The issue is caused by timing instability when RTT is disabled.

RTT logging keeps the CPU more active and prevents aggressive idle/sleep behavior. When RTT is disabled:

• The system enters low-power idle states more frequently.

• HFCLK behavior and interrupt latency become less deterministic.

• Timer-based sampling at 19200 baud becomes sensitive to jitter.

• Small timing shifts (even a few microseconds) cause incorrect sampling of data or stop bits.

• This results in framing errors.

At 9600 baud, the bit duration (~104 µs) provides sufficient timing margin to tolerate such jitter. At 19200 baud (~52 µs per bit), the margin is significantly reduced, making the system more sensitive to timing variation.

[Håkon Alseth]

Hi,

 

• 19200 baud + RTT disabled → Frequent framing errors

• Framing error counter increases continuously when RTT is disabled

Could you try to start the HFXO and see if this helps the stability? 

Is there a pattern? Ie. does it occur every byte or every 100th byte for instance?

Do you have anything running in your firmware that skews the timing, for instance a BLE link that has hard real-time requirements?

 

Kind regards,

Håkon

[Ehsan01]

Hi,

Thank you for the suggestions.

I performed additional checks regarding the questions you raised.

HFCLK / HFXO

I have now explicitly started the HFCLK/HFXO in the firmware using the nrfx clock driver to ensure that TIMER1 runs from a stable high-frequency clock source. This improves overall timing stability, but the behavior regarding RTT still remains noticeable.

Observed Error Pattern

The framing errors do not appear to follow a fixed periodic pattern (e.g., every Nth byte). Instead, the framing error counter increases continuously when RTT is disabled. This suggests that the issue is not related to a deterministic offset but rather to small timing variations or interrupt latency affecting the sampling point.

Firmware Timing Constraints

There is currently no BLE stack or radio activity running in the firmware, so there are no hard real-time BLE scheduling events that could interfere with timing.

The firmware primarily consists of:

• Soft UART receiver using GPIO interrupt for start-bit detection

• Bit sampling driven by nrfx_timer (TIMER1)

• Application logic processing received bytes

The Soft UART implementation is therefore highly sensitive to timing jitter.

Additional Observation

At 9600 baud, communication remains stable with or without RTT enabled.
However, at 19200 baud, the bit period (~52 µs) significantly reduces the timing margin. Even small interrupt latency or scheduling jitter can shift the sampling point enough to occasionally misread the stop bit, which leads to framing errors.

Enabling RTT appears to keep the CPU more active and reduces entry into deeper idle states, which indirectly improves timing consistency.

Please let me know if there are recommended approaches in Zephyr/NCS to ensure more deterministic timing for this use case, or if forcing HFCLK to remain active during UART reception would be the preferred solution.

Best regards,
Ehsan