ESC Protocol in rt-fc-offloader: How We Switch from DShot to ESC Boot

Why this matters

ESC flashing is timing-sensitive. In rt-fc-offloader, we switch motor IO in hardware so Linux scheduling jitter does not break bootloader entry.

DShot → ESC boot protocol switch sequence (exact timing)

1. Steer pin mux to serial mode
   Write 0x40000400 ← 0x00000004 (serial mode, selected motor channel, force_low=0).
2. Assert break (force line LOW)
   Write 0x40000400 ← 0x00000014 (force_low=1).
3. Hold LOW for bootloader entry window
   Hold for ≥ 20 ms (project guidance uses time.sleep(0.020) minimum; many tools use longer for margin).
4. Release line to idle HIGH
   Write 0x40000400 ← 0x00000004 (force_low=0). ESC bootloader is now listening.
5. Run ESC serial traffic over FCSP
   Send/receive bytes on FCSP channel 0x05 (ESC_SERIAL).
6. Restore flight mode
   Write 0x40000400 ← 0x00000001 (DShot mode).

Half-duplex behavior (handled in RTL)

The ESC line is one-wire half-duplex. wb_esc_uart transmits, then automatically returns to receive after the TX stop bit and guard period. During TX, RX is gated to avoid self-capture.

Host FCSP CH0x05 --> ESC UART TX --> Motor pin --> ESC bootloader
                                      ^         |
                                      |         v
Host FCSP CH0x05 <-- packetizer <-- ESC UART RX <- ESC response

Where this is documented in the repo

• docs/DESIGN.md — canonical register map, full switch sequence, exact addresses/values.
• docs/BLHELI_PASSTHROUGH.md — Python-facing handshake and passthrough flow.
• docs/BLHELI_QUICKSTART.md — operator quickstart and wiring steps.
• docs/TOP_LEVEL_BLOCK_DIAGRAM.md — top-level architecture view.
• docs/FCSP_PROTOCOL.md — FCSP framing/channels.
• docs/FCSP_COMMAND_TRANSLATION.md — legacy command to FCSP intent mapping.

Short version: channel 0x01 controls the hardware switch; channel 0x05 carries ESC bytes; RTL handles half-duplex timing; then we switch back to DShot.