Heinrichs Weikamp: Fix Firmware Upload when the OSTC4 is in the Bootloader. #79
Conversation
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
Bootloader. Fix the firmware upload sequence in the case of the OSTC4 being in the Bootloader (e.g. no firmware installed, recovery from failed firmware upload). The command 0x60 (HARDWARE2) results is buggy in the bootloader, so we resort to trying 0x69 (HARDWARE) first. Signed-off-by: Michael Keller <[email protected]>
mikeller
force-pushed
the
fix_hw_ostc4_bootloader_firmware_upload
branch
from
d0128ce to
7aabd4b
Compare
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR fixes the firmware upload sequence for the OSTC4 bootloader situation by trying the HARDWARE command first and conditionally falling back to HARDWARE2 if the initial response indicates a non-OSTC4 device.
- Prioritize sending the HARDWARE command to avoid a Bluetooth disconnect in bootloader mode.
- Add logic to re-request HARDWARE2 data when the first two bytes do not match OSTC4 and adjust device initialization accordingly.
Comments suppressed due to low confidence (2)
src/hw_ostc3.c:491
- Transferring the HARDWARE command response into 'hardware + 1' may leave the first byte uninitialized, which affects the subsequent call to array_uint16_be(hardware). Consider writing to the complete 'hardware' buffer if the protocol expects a full response.
status = hw_ostc3_transfer(device, NULL, HARDWARE, NULL, 0, hardware + 1, SZ_HARDWARE, NULL, NODELAY);
src/hw_ostc3.c:495
- Since the HARDWARE command writes its response starting from hardware+1, the comparison using array_uint16_be(hardware) may not correctly reflect the intended hardware identifier. Verify that the correct offset is used when checking against OSTC4.
if (size == SZ_HARDWARE2 && array_uint16_be(hardware) != OSTC4) {
theCarlG
pushed a commit
to theCarlG/libdc
that referenced
this pull request
Jul 16, 2025
…r_firmware_upload
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Fix the firmware upload sequence in the case of the OSTC4 being in the
Bootloader (e.g. no firmware installed, recovery from failed firmware
upload). The command 0x60 (HARDWARE2) results is buggy in the
bootloader, so we resort to trying 0x69 (HARDWARE) first.