This repository was archived by the owner on Feb 21, 2025. It is now read-only.
Pulling in upstream changes#2
Draft
Ralim wants to merge 95 commits intoeDesignOSS:masterfrom
Draft
Conversation
This might make some future debugging easier.
Update circle.yml to the new format .circleci/config.yml Update install-toolchain.sh to the more robust version from dap42
Fixes issue #13. Delay reading the button.
Issue #14 Fix a miserable typo.
Fix issue #15, add attribute to avoid a warning by GCC
…m to be overridden by make.
Fixes issue #17 Guard on all defines in config.h
Using WINUSB_MS_VENDOR_CODE in extra string
Don't compile all of libopencm3, only required target
The bluepill board has a dip-switch connected to BOOT1 (PB2) via a 100k resistor. Enter the bootloader when connecting this to "1".
Using gcc-arm-none-eabi-9-2019-q4-major this gives a bootloader binary about 900 bytes smaller.
Use BOOT1 as bootloader enter button in bluepill board.
Use link-time-optimization in the build.
Adds a compilation define `BOOTLOADER_HIGH` that compiles a high-memory version of the bootloader. The high-memory bootloader lives at the high end of flash, allowing an non- bootloader-aware application to run without modifications. The bootloader modifies the application's vector table to point to the bootloader's reset stub. The actual reset vector is stored in unused entries in the application's vector table. Based on ideas from: http://stm32duino.com/viewtopic.php?t=687 This is based on code from commit cf21dc3 fixing DFU upload and rebasing on current master branch. Co-authored-by: Devan Lai <devan.lai@gmail.com>
Merge @dmsc's support for building the high-memory bootloader as a new optional target in 64k/128k flavors, together with size optimizations and a bugfix for the firmware upload readback patching.
Otherwise the sub-make will use the unmodified toolchain
No need to force the in-between flash to zero when we can leave them at their default erased state (all ones)
The BigTreeTech SKR MINI E3 V2.0 is a 3D printer motherboard based on the STM32F103RC with 256 KiB of flash. Out of the box it has a MOSFET controlling the USB pullup wired to the SWCLK pin, which makes attaching a debugger very difficult. The USBMOD target variant has pullup control disabled for people that feel adventurous enough to desolder some components from their board to fix this issue, there is a more in-depth explanation in the USBMOD config.h. Both targets have a high memory variant which has been tested and confirmed working with the Klipper firmware by specifying "no bootloader" in its memory offset configuration menu.
Add a new target for the GigaDevice variant of the BluePill Plus.
…o to USB_DFU_ALTN Assesses review feedback. I could initially not get the macros to work in usb_conf.c, but they seem to work now even though the changes from pull #38 have been present in the development tree from the start.
This is behavior is more akin to what most STM32F103xx applications wanting to enter the bootloader are accustomed to. Should retain backwards compatibility with existing applications writing to both registers, the higher one just won't be checked by the bootloader anymore.
…y default Enabling DFU_WILL_DETACH will set bitManifestationTolerant = 0 and bitWillDetach = 1, disabling it will set the opposite. If DFU_WILL_DETACH is set, the target will automatically detach and reset following a successful reprogramming, and if it's not set, the target will enter the dfuIDLE state. Both of these behaviors are described in the DFU 1.1 spec. DFU_WILL_DETACH is enabled by default for WebUSB compatibility, as some platforms will apparently not instruct the target to reset after flashing.
# Conflicts: # src/targets.mk
Always enter dfuMANIFEST-SYNC, but subsequently reset to manifest if the firmware is valid. Call the target manifest callback if provided, but reset in case the callback is absent or fails to reset the device.
Per the DFU spec, a USB reset should cause the device to either reenumerate as the application or enter an error state if invalid. Register a USB reset callback to detect and handle USB resets, taking care not to trigger the first time the bootloader is enumerated. Run the manifest callback if present when manifesting via USB reset.
If the firmware has been written to at least once, treat a detach/USB reset as an implicit manifestation request and run the manifest request callback. Otherwise treat it as a detach request and simply reset.
Allow configuration of the backup register and command word used to trigger the bootloader. Change STM32F103 RTC backup to use native 16-bit backup register size. On STM32F103 targets, only look for "BO" in BKP1 instead of both "BO" in BKP1 and "OT" in BKP2
Enable specifying the alternate setting for the DFU interface per-target
The initial behavior of entering dfuMANIFEST-SYNC was incorrect, sorry about that. I've now thoroughly read the DFU spec, which actually states that dfuMANIFEST-SYNC shall be entered *twice* after a download operation if bitMainfestationTolerant = 1 (i.e. DFU_WILL_DETACH == 0), once after the download completes, which begins manifestation by transitioning to dfuMANIFEST, and again after manifestation has completed successfully, and only after that should the transition to dfuIDLE be made. This means that there should be *two* DFU_GETSTATUS calls from the host, and indeed dfu-util does exactly this (verified using Wireshark). Manifesting on USB reset or on detach is not according to spec. It should only happen right after a download operation has finished. For this I've overhauled the dfu_on_manifest_request() function to work as it should with both DFU_WILL_DETACH == 1 and DFU_WILL_DETACH == 0. Validation should actually be part of manifestation, and I've now added it as the manifestation callback (since there is no other manifestation work to be done). The scb_reset_system() call in the USB reset callback is what you need to perform detach-by-USB-reset, but to avoid having random reset calls in multiple places it makes much more sense to call the actual dfu_on_detach_complete() callback which will then perform the reset. The USB reset callback should also not validate, e.g. a blank flash with just the bootloader should not trigger a firmware error status, so I've removed that logic.
Overhaul manifest/detach handling to more closely match the spec. The new DFU_WILL_DETACH option (default enabled) controls whether the bootloader will automatically detach after manifestation completes or if it will return to the IDLE state. Detect USB bus resets and trigger detach/re-enumeration as if receiving a DFU detach command.
Add support for the BigTreeTech SKR MINI E3 V2.0 board and STM32F103RC
Provide a target-specific hook to run just before detaching/rebooting. The manifested parameter can be used to distinguish between resetting to run existing vs new firmware.
Document new STM32F103 bootloader backup register changes and version changeover Document DFU_WILL_DETACH behavioral differences
Finalize version changeover at v1.20 Use RTC backup register numbers consistent with RM0008
custom initialization
Add a new 'target_post_setup' hook that targets can use for their own custom initialization
For the past two years I've had only occasional issues with a BTTSKRMINIE3V2_USBMOD build my the SKR MINI, but after upgrading to a faster Pi (64-bit OS) for Klipper, some major problems with this mod became evident. Hard-wiring the USB D+ pullup to 3V3 causes the host to enumerate it as soon as a soft reset is issued, whereby the firmware (and this bootloader) have not had time to properly initialize and get USB ready. This stalls USB hubs, times out the Ethernet controller on Raspberry Pis, and causes all kinds of other issues, thus, I'm discouraging its use and removing the target. Regarding the debugging difficulties motivating BTTSKRMINIE3V2_USBMOD, they can be solved with a proper debugging setup. I'm able to successfully debug the MCU even with the USB pullup MOSFET and the STATUS LED attached to SWDCLK and SWDIO respectively using a FT232H. As such, the BTTSKRMINIE3V2 target should be used instead, and I've also re-added control of the STATUS LED to indicate bootloader presence.
The bootloader doesn't fit into the advertised 6.5 kB anymore, resulting in linker errors for all high-memory targets: ``` /usr/lib/gcc/arm-none-eabi/8.3.1/../../../arm-none-eabi/bin/ld: dapboot.elf section `.text' will not fit in region `rom' /usr/lib/gcc/arm-none-eabi/8.3.1/../../../arm-none-eabi/bin/ld: region `rom' overflowed by 276 bytes ``` Increase the reserved high-memory area from 0x1A00 to 0x1C00 (7 KiB), with 236 bytes to spare.
For example, the BTTSKRMINIE3V2 pinout uses SWDIO (PA13) and SWDCLK (PA14) for the STATUS LED and USB pullup respectively. Addressing those pins as GPIO requires disabling SWD. See https://github.com/Klipper3d/klipper/blob/6d48adf9ef5d17632acf53a7e3a07964f6cfd642/src/stm32/stm32f1.c#L152 for a similar application-side implementation.
Fix build for high memory targets
Disable SWD if PA13/PA14 are used for another purpose
Remove BTTSKRMINIE3V2_USBMOD, use BTTSKRMINIE3V2 instead
The old version requires python2, which is no longer readily available
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
10 participants
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.