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.
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.