Repository navigation
fix: keep the ROM DFU loader off USART1 so a bare-metal update restarts - #155
Merged
Merged
Conversation
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
added a commit
that referenced
this pull request
Oct 15, 2026
…-line fix: reapply the ROM DFU USART1 line fix (#155)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
license-manifestchange process (and board approval for anything leaving the core). Link the approval.Checklist
git commit -sSPDX-License-Identifierfor their layerCODEOWNERSreview requestedNotes for reviewers