fix(uart): hal_uart_init() doesn't force a reset edge or configure RX/TX pull state #120

New issue

Closed

opened 2026-07-23 21:20:11 +00:00 by hoogv · 0 comments

hoogv commented

2026-07-23 21:20:11 +00:00

Owner

Found while debugging a real-hardware "UART doesn't work" report on a downstream consumer project (awr6843_mss_barebones_example), by diffing hal_uart_init() against a hardware-confirmed sibling driver (AWR6xxx_Toolchain's Universal_hal, uart_iwr68xx.c, itself ported from the mmWave SDK's UartSci_open()).

Two gaps:

No explicit reset-then-release. hal_uart_init() writes SCIGCR0.RESET = 1 directly. If the module was already out of reset (RESET already 1), this write is a no-op -- no 0->1 edge, so the module's internal state machines/shift registers/stale GCR1/BAUD config from before this call are never actually cleared. This matters concretely on this hardware: the SCI instance this example uses (MSS_SCIA) is the same "Application/User UART" the board's own SBL/flash tool (UniFlash) uses to receive the flashed image before ever jumping to the application -- so RESET may well already be 1, with the bootloader's own stale config in place, when this driver's hal_uart_init() runs. The reference driver explicitly does SCIGCR0 = 0 then SCIGCR0 = 1.
RX/TX pull state left at whatever the pad's default happens to be. SCIPIO7/SCIPIO8 (pull-disable / pull-select) are never written. Per this project's own register header comments, both registers' reset values are documented as "pin/pad default-dependent... not a guaranteed reset value" -- i.e. genuinely unknown without explicit configuration, not just "defaults to 0". The reference driver explicitly enables pull control and selects pull-up on both RX and TX (idle-high, the correct idle state for UART).

Fix: reset-then-release SCIGCR0, and explicitly write SCIPIO7/SCIPIO8 for pull-enable + pull-up on RX/TX, matching the SDK reference driver.

Found while debugging a real-hardware "UART doesn't work" report on a downstream consumer project (`awr6843_mss_barebones_example`), by diffing `hal_uart_init()` against a hardware-confirmed sibling driver (`AWR6xxx_Toolchain`'s `Universal_hal`, `uart_iwr68xx.c`, itself ported from the mmWave SDK's `UartSci_open()`). Two gaps: 1. **No explicit reset-then-release.** `hal_uart_init()` writes `SCIGCR0.RESET = 1` directly. If the module was already out of reset (RESET already 1), this write is a no-op -- no 0->1 edge, so the module's internal state machines/shift registers/stale GCR1/BAUD config from before this call are never actually cleared. This matters concretely on this hardware: the SCI instance this example uses (`MSS_SCIA`) is the same "Application/User UART" the board's own SBL/flash tool (UniFlash) uses to receive the flashed image before ever jumping to the application -- so `RESET` may well already be 1, with the bootloader's own stale config in place, when this driver's `hal_uart_init()` runs. The reference driver explicitly does `SCIGCR0 = 0` then `SCIGCR0 = 1`. 2. **RX/TX pull state left at whatever the pad's default happens to be.** `SCIPIO7`/`SCIPIO8` (pull-disable / pull-select) are never written. Per this project's own register header comments, both registers' reset values are documented as "pin/pad default-dependent... not a guaranteed reset value" -- i.e. genuinely unknown without explicit configuration, not just "defaults to 0". The reference driver explicitly enables pull control and selects pull-up on both RX and TX (idle-high, the correct idle state for UART). Fix: reset-then-release `SCIGCR0`, and explicitly write `SCIPIO7`/`SCIPIO8` for pull-enable + pull-up on RX/TX, matching the SDK reference driver.

hoogv referenced this issue from a commit

2026-07-23 21:20:31 +00:00

fix(uart): force a reset edge and configure RX/TX pull state in hal_uart_init()

hoogv referenced this issue from a pull request that will close it,

2026-07-23 21:20:37 +00:00

fix(uart): force a reset edge and configure RX/TX pull state in hal_uart_init() #121

hoogv closed this issue

2026-07-23 21:20:55 +00:00