This adds a few more boards (all variants of the same board, with different USB product strings) and also adds triggering the bootloader only when VBUS is connected (when routed to a GPIO pin).
The VBUS thing is for these new boards - the bootloader only wants to run when they're connected to USB, so VBUS is mirrored to a GPIO pin for monitoring (the pin next to the VBUS pin usually). If that input is HIGH (with the internal pull-down enabled - the code currently only works on newer chips like the MX2xx) the bootloader code runs. If it's LOW it doesn't, and the application executes.
It is possible to get the VBUS status from the USB module - however that entails first enabling the USB module which, in this case, must not happen if the board is not connected to USB (the D+/D- pins are shared with other functions and connected to a multi-drop bus).
It can't be done using the existing program button code (even though the functionality is on the face of it the same) since time is needed for the VBUS to stabilize at powerup, otherwise the input never sees it as HIGH, so a very short delay and retry time is implemented.
This adds a few more boards (all variants of the same board, with different USB product strings) and also adds triggering the bootloader only when VBUS is connected (when routed to a GPIO pin).
The VBUS thing is for these new boards - the bootloader only wants to run when they're connected to USB, so VBUS is mirrored to a GPIO pin for monitoring (the pin next to the VBUS pin usually). If that input is HIGH (with the internal pull-down enabled - the code currently only works on newer chips like the MX2xx) the bootloader code runs. If it's LOW it doesn't, and the application executes.
It is possible to get the VBUS status from the USB module - however that entails first enabling the USB module which, in this case, must not happen if the board is not connected to USB (the D+/D- pins are shared with other functions and connected to a multi-drop bus).
It can't be done using the existing program button code (even though the functionality is on the face of it the same) since time is needed for the VBUS to stabilize at powerup, otherwise the input never sees it as HIGH, so a very short delay and retry time is implemented.