Skip to content

fix: keep the ROM DFU loader off USART1 so a bare-metal update restarts - #155

Merged
georgevigelette merged 1 commit into
nextfrom
fix/rom-dfu-uart-line
Oct 15, 2026
Merged

georgevigelette merged 1 commit into
nextfrom
fix/rom-dfu-uart-line

Conversation

@georgevigelette

Copy link
Copy Markdown
Contributor

After every bare-metal (ROM DFU) update the sensor module dropped off USB and stayed off until it was power-cycled; the console, same MCU, restarts.

The STM32 ROM loader scans its UART interfaces as well as USB. On the sensor board PB15, USART1_RX for the ROM, is camera 4's UART TX line, and with camera 4 unpowered it sits low. The DFU-request reset leaves every camera rail off, so the ROM sees a low RX line, commits to its UART protocol and waits for the 0x7F auto-baud byte forever. USB DFU still works, but the DFU leave request is never acted on.

Bench evidence (right module, 2026-10-15): with no erase or download, a plain DFU enter + leave hung every time with the core in the ROM's USART1 ABRF poll, USART1 framing error latched and PB15 low. PB15 reads low with camera 4 off and high with it on (CAM_PWR_5, PD3). Powering the cameras from the host before the DFU request does not help: the reset drops the rails before the ROM starts.

CheckBootloaderFlag now switches camera 4's rail on and waits (bounded) for the line to idle high before jumping into the ROM. Registers only, since SysTick and HAL are already torn down there. With this build: 3/3 plain enter + leave restarted, and SDK bare-metal updates fix->fix, fix->fix and fix->1.8.1 all came back about 3 s after the write with no power cycle.

An update away from an image without this fix (1.8.3-rc.1 and older bare metal) still needs a power cycle, because the running image does the ROM entry. Bootloader builds are not affected: they never enter the ROM loader.

Summary

Licensing layer

  • Apache-2.0 extension (3D Slicer, wellness/veterinary module, partner SDK, language binding)
  • AGPL-3.0 core (firmware, sensing/beamforming/reconstruction/signal-processing/calibration algorithms, hardware reference design)
  • Docs / data / tooling only
  • This PR moves a file between the AGPL core and the Apache layer — if checked, this is NOT an ordinary PR: it requires the license-manifest change process (and board approval for anything leaving the core). Link the approval.

Checklist

  • Commits are signed off (DCO): git commit -s
  • New files carry the correct SPDX-License-Identifier for their layer
  • Tests and docs updated
  • No incompatible third-party code introduced
  • CI is green and CODEOWNERS review requested

Notes for reviewers

After every bare-metal (ROM DFU) update the sensor module dropped off USB
and stayed off until it was power-cycled; the console, same MCU, restarts.

The STM32 ROM loader scans its UART interfaces as well as USB. On the
sensor board PB15, USART1_RX for the ROM, is camera 4's UART TX line, and
with camera 4 unpowered it sits low. The DFU-request reset leaves every
camera rail off, so the ROM sees a low RX line, commits to its UART
protocol and waits for the 0x7F auto-baud byte forever. USB DFU still
works, but the DFU leave request is never acted on.

Bench evidence (right module, 2026-10-15): with no erase or download, a
plain DFU enter + leave hung every time with the core in the ROM's USART1
ABRF poll, USART1 framing error latched and PB15 low. PB15 reads low with
camera 4 off and high with it on (CAM_PWR_5, PD3). Powering the cameras
from the host before the DFU request does not help: the reset drops the
rails before the ROM starts.

CheckBootloaderFlag now switches camera 4's rail on and waits (bounded) for
the line to idle high before jumping into the ROM. Registers only, since
SysTick and HAL are already torn down there. With this build: 3/3 plain
enter + leave restarted, and SDK bare-metal updates fix->fix, fix->fix and
fix->1.8.1 all came back about 3 s after the write with no power cycle.

An update away from an image without this fix (1.8.3-rc.1 and older bare
metal) still needs a power cycle, because the running image does the ROM
entry. Bootloader builds are not affected: they never enter the ROM loader.

Signed-off-by: George Vigelette <george@openwater.cc>
@georgevigelette
georgevigelette merged commit a3df3f3 into next Oct 15, 2026
2 checks passed
@georgevigelette
georgevigelette deleted the fix/rom-dfu-uart-line branch October 15, 2026 22:30
georgevigelette added a commit that referenced this pull request Oct 15, 2026
…-line

fix: reapply the ROM DFU USART1 line fix (#155)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant