Repository navigation
fix: register the four firmware error codes the table was missing - #21
Merged
Merged
Conversation
Parsing the firmware headers turned up four codes the SDK cannot name and one entry that describes behaviour the firmware has already changed: (0x21, 0x02) speed percent out of range usb_cmd.c:637 (0x31, 0x01) preset payload too short usb_cmd.c:908 (0x39, 0x02) q contains NaN/Inf usb_cmd.c:1034 (0x02, 0x06) a move_p late terminal reply kin_runner.c:173 (0x31, 0x02) said "preset invalid **or** payload too short". The firmware split those apart on 2026-09-24, so the "or" now makes a caller read a length error as a preset error. (0x02, 0x06) also contradicted an assertion here that MOVE_P has no drop_hold gate. That claim only covers the dispatch path; the reply path (kin_runner_flush_move -> ctrl_accept_move_j) does have the gate and does return 0x06, so a caller could misread a drop-hold latch. The negative assertion is replaced by a positive one. The symbolic-site manifest counted usb_cmd.c only while the parser walks the whole firmware tree, so the kin_runner.c site was never seen at all. Manifest 14 -> 15. Found by running the two protocol-sync suites against a real litearm-stm32 checkout; they skip silently without one.
|
🎉 This PR is included in version 1.1.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.
Summary
Parsing the firmware headers turned up four error codes this SDK cannot name, and one
entry that describes behaviour the firmware changed on 2026-09-24. The two protocol-sync
suites read a real
litearm-stm32checkout and skip silently without one, so none ofthis was visible until a checkout was placed next to the repo.
Same firmware tree as #19; this is the error-table half rather than the cartesian half.
Changes
errors.py— register four codes the firmware emits:(0x21, 0x02)speed percent out of range (usb_cmd.c:637)(0x31, 0x01)preset payload too short (usb_cmd.c:908)(0x39, 0x02)q contains NaN/Inf (usb_cmd.c:1034)(0x02, 0x06)amove_plate terminal reply (kin_runner.c:173)errors.py—(0x31, 0x02)read "preset invalid or payload too short". Thefirmware split those apart on 2026-09-24, so the "or" makes a caller read a length
error as a preset error.
tests/test_error_codes.py— the symbolic-site manifest countedusb_cmd.conly,while the parser walks the whole firmware tree, so the
kin_runner.csite had neverbeen seen. Manifest 14 -> 15.
tests/test_error_codes.py— an assertion claimed MOVE_P has no drop_hold gate. Thatcovers the dispatch path only: the reply path (
kin_runner_flush_move->ctrl_accept_move_j) does have the gate and does return0x06, so a caller couldmisread a drop-hold latch. Replaced by a positive assertion.
tests/test_protocol_sync.py—test_bench_model_axis_matches_sdk_constantused#if\s+LITEARM_BENCH_1J(.*?)#elsewithre.S, which hits the literal#ifand#elseinside the file's own comment, so it reported "bench branch not found" for thewrong reason. It now matches the
#defineline. The firmware removed bench mode on2026-09-28 and left an
#errorguard, so the test asserts the guard is present andthat the constant is still carried for 1J firmware.
_protocol.py— markBENCH_MODEL_AXISLEGACY with the removal rationale.Testing
Before this branch, same firmware checkout, from
main:The three failures are exactly the ones this fixes:
test_every_firmware_literal_err_code_is_registered,test_symbolic_site_manifest_matches_firmware,test_bench_model_axis_matches_sdk_constant.The 2 skips are expected offline: the protocol-sync suites call
pytest.skipwhen nofirmware checkout is present, by design.
Issues
Refs #19