Feature/boot loader support#40
Open
georgevigelette wants to merge 22 commits into
Open
Conversation
Add a runtime debug-flag command (OW_CMD_DEBUG_FLAGS, 0x0C) and a DEBUG_FLAG_USB_PRINTF flag that mirrors firmware printf() to the USB CDC host link, matching openmotion-sensor-fw. printf still goes to the UART4 debug console; when the flag is set its bytes are also buffered into a dedicated ring and flushed from the main loop as framed OW_DATA/OW_CMD_ECHO (id=0) packets over the same USB CDC endpoint that carries command responses. The redirector is kept off the command path: _write only buffers (no transmit, no block, ISR-safe), all transmits happen in logging_pump() from the main loop with re-entry and tx-in-flight guards and a dedicated TX buffer, and ring writes run under a short critical section. RAM-only; default off. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…dropped comms_process re-armed CDC reception (CDC_ReceiveToIdle) only AFTER sending the response, but the CDC RX path discards bytes while unarmed — so a command that arrived during processing/response was silently dropped. Rapid back-to-back commands lost every other one, which forced the host SDK to pace commands ~10 ms apart. Snapshot the received frame into procBuffer and re-arm reception up front (before parse/process/respond), so the next command lands in rxBuffer while this one is handled. rx_flag is cleared before re-arming so the next command's flag can't be lost. Verified on hardware: 40/40 back-to-back pings at zero gap (was ~50%), and the host SDK pacing workaround removed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…flags feat: console printf over USB CDC + CDC-RX back-to-back fix
…lth/openmotion-console-fw into feature/boot-loader-support
The bootloader (openmotion-bl) now uses flash sector 6 / bank 2 (0x081C0000) as its persistent anti-rollback version floor and protects it from the DFU update path. Mark it in the memory map so the (EEPROM-backed, currently unused) FLASH_ODOMETER_START_ADDR reservation is not repurposed for flash storage that would collide with the floor. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
In the bipolar straight-binary branch of volts_to_code() (ad5761r.c, TEC control DAC), the upper full-scale clamp was nested inside the lower-bound check, making it unreachable. Out-of-range high setpoints therefore wrapped in the (uint16_t) cast instead of saturating at 0xFFFF (e.g. code 70122 -> 4586, near zero-scale). Restructure to the if / else-if pattern already used by the unipolar branch so both bounds saturate. Fixes #38 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
fix: TEC DAC full-scale clamp misnested in ad5761r.c (wraps instead of saturating)
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.
No description provided.