[Beta] Jump to system memory boot from user application #710

Signed-off-by: Frederic Pillon <[email protected]>

Fixes stm32duino#706 Signed-off-by: Frederic Pillon <[email protected]>

The upload.use_1200bps_touch key tells the IDE to open the user-selected serial port at 1200 baud, and then close it, before attempting an upload. This allow to jump in BL mode. Signed-off-by: Frederic Pillon <[email protected]>

Instead, use a .noinit variable, which survives across reboots. Note: This file uses the bool type, so needs to include stdbool.h. It seems that for the F4, this was indirectly included elsewhere, but for e.g. F0, this did not seem to be the case, causing the build to fail.

This now runs in early startup, so the normal delay will not work (systick is not running yet). Note: Seems that on F0, inline assembler is compiled using the classic rather than unified syntax (which *is* used on F4 it seems). This explicitly selects the unified syntax in the inline assembly block, to fix building for F0. TODO: There is a variant which also overrides the enumeration.

Since the bootloader does not touch these flags, but can start the sketch if instructed by the programmer (without a reset), clearing is needed to prevent a start from the bootloader looking like a software-reset. Otherwise, the startup code would be looking at the BootIntoBootloaderAfterReset variable to decide whether to jump to the bootloader. This variable should have been cleared before jumping to the bootloader the last time, but the bootloader might have overwritten it (or a sketch was uploaded with a different address for that variable). Additionally, clearing the reset flags allows a sketch to see that the they are started through the bootloader, when all reset flags are cleared.

On most CPUs, detecting the system flash address is not needed, since they can remap the system flash onto adress 0x0 and the bootloader reset vector can be read from there. This approach also more closely mimics a bootloader start using the BOOTx pins. For CPUs that cannot remap flash, this hardcodes the address of system flash and jumps there instead. For H7 and F7, this is also how it works when using the BOOT pins. For F1, remapping can be done using the BOOT pins, but not from software, resulting in a difference with a BOOT-activated bootloader. This puts the code that figures out where the bootloader lives back in a separate function. This makes the code easier to read, and makes it easier to jump to custom bootloaders (e.g. in normal flash instead of in system flash). TODO: Check value for H7, AN2606 and reference manual disagree

This ensures that the SP is not modified after loading it and ensures a jump instruction is used. The assembly code was based on micropython and another STM32 core: https://github.com/micropython/micropython/blob/f6375ac3ebac28656a0a757952d32c265b1ba7aa/ports/stm32/powerctrl.c#L71-L78 https://github.com/GrumpyOldPizza/arduino-STM32L4/blob/bacc184288a4644b2ee6a97672334983f3e788ab/system/STM32L4xx/Source/boot_stm32l4xx.c#L159-L166

This waits for 250ms, just like the Arduino SAM and SAMD cores do (AVR waits only 120ms), to allow the USB host and application a bit more time to close the port and clean up.

This function calls HAL_Delay, which relies on the systick timer to be running, so this results in an infinite loop. This should probably be fixed in HAL_Delay, but for now just remove the calls to USB_DevDisconnect and USB_DevConnect and replace it with the bit twiddles needed for some chip families (e.g. the F4), breaking compilation and/or functionality for others.

This adds support for the DFU runtime protocol, which allows resetting into the bootloader using a DFU command. This allows e.g. dfu-util to handle the complete firmware upload, including the needed reset. This consists of a number of changes: - An extra interface is added to the USB configuration descriptor. This descriptor has two parts (interface descriptor and functional descriptor) which together indicate to a host that this device supports DFU. - Control packets to this new interface are detected by the CDC code an forwarded to a new USBD_DFU_Runtime_Control() function. - This new function handles the DFU GET_STATE, GET_STATUS and DFU_DETACH commands. The former are optional, but simple enough, the latter is mandatory and handles resetting into the bootloader. - The CDC device descriptor is changed to become a composite device (CDC and DFU). This allows operating systems (in particular Windows, Linux did not really need this) to identify two different subdevices, and install different drivers for each (on Windows, this is serusb for the CDC part and WinUSB/libusb for the DFU part). Without this, dfu-util on Windows could not access the DFU commands when the serial driver was loaded. Because the CDC functionality already exposes two interfaces (which together form a single serial port), an IAD (Interface Association Descriptor) is inserted before these interfaces to group them together in a single subdevice. No IAD is needed for the DFU interface, since it is just a single interface. To become a composite device, the device class must be changed from CDC to a composite device class. This was originally class 0/0/0, but together with the IAD, a new EF/2/1 deviceclass was also introduced, which is used now. Note that this only adds descriptors and a command handler on the default control endpoint, so no extra (scarce) endpoints are used by this, just a bit of memory. This commit is still a bit rough, because: - The DFU descriptors and code are now pulled in directly by the CDC code (and HID is not supported yet). Ideally, there should be some kind of pluggable USB library where different interfaces can be registered independent of each other (see also stm32duino#687). - The interface number is hardcoded in the DFU descriptor. - The reset to bootloader happens immediately, while it might be better to wait a short while to allow the current USB transaction to complete. - DFU support is unconditionally advertised, while not all boards might support DFU.

Bootloader management is not applicable for this serie. Signed-off-by: Frederic Pillon <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Beta] Jump to system memory boot from user application #710

[Beta] Jump to system memory boot from user application #710

Commits on Sep 18, 2020

[Beta] Jump to system memory boot from user application #710

Are you sure you want to change the base?

[Beta] Jump to system memory boot from user application #710

Commits on Sep 18, 2020