ece950d9be
Since the very beginning, the stm32 port (first called stm, then stmhal now stm32) has had a special keyboard interrupt feature which works by using PendSV to break out of any running code. This preemptive ctrl-C was added long ago in commit01156d510c. The stm32 port still uses that code, and current does this: - If ctrl-C is received on UART or USB then `mp_sched_keyboard_interrupt()` is called (like all other ports) to set a flag for the VM to see, and then the VM (or any loop calling `mp_handle_pending(true)`) will eventually handle the `KeyboardInterrupt` exception, raising it via NLR. - If another ctrl-C is received while the existing scheduled keyboard interrupt is still pending (ie the VM has not yet processed it) then a special hard NLR jump will activate, that preempts the calling code. Within the PendSV interrupt the stack is adjusted and an NLR jump is made to the most recent `nlr_push()` location. This is like a normal NLR except it is called from an interrupt context and completely annihilates the code that was interrupted by the IRQ. The reason for the preemptive interrupt was to handle ctrl-C before the VM was able to handle it. Eventually a mechanism (that's in use today by all ports) was added to the VM and runtime to be able to check for pending interrupts. Then the stm32 port was updated to use this mechanism, with a fallback to the old preemptive way if a second ctrl-C was received (without the first one being processed). This preemptive NLR jump is problematic because it can interrupt long-running instructions (eg store multiple, usually used at the end of a function to restore registers and return). If such an instruction is interrupted the CPU remembers that with some flags, and can resume the long-running instruction when the interrupt finishes. But the preemptive NLR does a long jump to different code at thread level and so the long-running interrupt is never resumed. This leads to a CPU fault. This fault has been previously reported in issues #3807 and #3842 (see also issue #294). It's now possible to easily reproduce this problem, since commit69c25ea865. Running the test suite over and over again on any stm32 board will eventually crash the board (it can happen on a PYBv1.x, but it happens more regularly on PYBD-SF2/6). The point is, a skipped test now soft resets the board and so the board must run `boot.py` again. The test runner may then interrupt the execution of `boot.py` with the double-ctrl-C that it sends (in `tools/pyboard.py`, `enter_raw_repl()`) in order to get the board into a known good state for the next test. If the timing is right, this can trigger the preemptive PendSV in an unfortunate location and hard fault the board. The fix in this commit is to just remove the preemptive NLR jump feature. No other port has this feature and it's not needed, ctrl-C works very well on those ports. Preemptive NLR jump is a very dangerous thing (eg it may interrupt and break out of an external SPI flash operation when reading code from a filesystem) and is obviously buggy. With this commit, stm32 borads no longer hard fault when running the test suite (but it does leave an issue, the tests can still interrupt `boot.py` with a single ctrl-C; that will be fixed separately). An alternative to this commit would be to clear the CPU state for the long-running instruction as suggested in issue #3842. But it's much simpler to just remove this code, which is now unnecessary and can have other problems as per issue #294. Signed-off-by: Damien George <damien@micropython.org>
MicroPython port to STM32 MCUs
This directory contains the port of MicroPython to ST's line of STM32 microcontrollers. Supported MCU series are: STM32F0, STM32F4, STM32F7, STM32G0, STM32G4, STM32H5, STM32H7, STM32L0, STM32L1, STM32L4, STM32WL and STM32WB. Parts of the code here utilise the STM32Cube HAL library.
The officially supported boards are the line of pyboards: PYBv1.0 and PYBv1.1 (both with STM32F405), PYBLITEv1.0 (with STM32F411) and PYBD-SFx (with STM32F7xx MCUs). See micropython.org/pyboard for further details.
Other boards that are supported include ST Discovery and Nucleo boards. See the boards/ subdirectory, which contains the configuration files used to build each individual board.
Build instructions
Before building the firmware for a given board the MicroPython cross-compiler must be built; it will be used to pre-compile some of the built-in scripts to bytecode. The cross-compiler is built and run on the host machine, using:
$ make -C mpy-cross
This command should be executed from the root directory of this repository. All other commands below should be executed from the ports/stm32/ directory.
An ARM compiler is required for the build, along with the associated binary
utilities. The default compiler is arm-none-eabi-gcc, which is available for
Arch Linux via the package arm-none-eabi-gcc, for Ubuntu via instructions
here, or
see here for the main GCC ARM
Embedded page. The compiler can be changed using the CROSS_COMPILE variable
when invoking make.
Next, the board to build must be selected. The default board is PYBV10 but any
of the names of the subdirectories in the boards/ directory is a valid board.
The board name must be passed as the argument to BOARD= when invoking make.
All boards require certain submodules to be obtained before they can be built.
The correct set of submodules can be initialised using (with PYBV11 as an
example of the selected board):
$ make BOARD=PYBV11 submodules
Then to build the board's firmware run:
$ make BOARD=PYBV11
The above command should produce binary images in the build-PYBV11/
subdirectory (or the equivalent directory for the board specified).
Note that some boards require the mboot bootloader to be built and deployed before flashing the main firmware. For such boards an information message about this will be printed at the end of the main firmware build. Mboot can be built via:
$ make -C mboot BOARD=STM32F769DISC
For more information about mboot see mboot/README.md.
Link Time Optimization
Link Time Optimization (LTO) reduces the firmware binary size when enabled (typically 2-3% smaller). However it may make build time longer, particularly on older GCC versions.
Currently LTO is enabled by default for some smaller STM32 boards with less flash, but disabled on other boards.
To enable LTO, pass LTO=1 on the command line:
$ make BOARD=boardname LTO=1
To disable LTO, pass LTO=0 in the same way.
Note that make clean BOARD=boardname will be needed before changing the LTO
setting of a firmware that is already built.
Flashing the Firmware using DFU mode
You must then get your board/microcontroller into DFU (Device Firmware Update) mode.
If you already have MicroPython installed on the board you can do that by
calling machine.bootloader() on the board, either at the REPL or using
pyboard.py. A nice property of this approach is that you can automate it
so you can update the board without manually pressing any buttons.
If you do not have MicroPython running yet, temporarily jumper your board's DFU pin (typ. BOOT0) to 3.3v and reset or power-on the board.
On a pyboard the P1/DFU pin and a 3.3v pin are next to each other (on the bottom left of the board, second row from the bottom) and the reset button is labeled RST.
For the pyboard D-series you can enter the mboot DFU bootloader by holding down the USR button, pressing and releasing the RST button, and continuing to hold down USR until the LED is white (4th in the cycle), then let go of USR while the LED is white. The LED will then flash red once per second to indicate it is in USB DFU mode.
Once the board is in DFU mode, flash the firmware using the command:
$ make BOARD=PYBV11 deploy
This will use the included tools/pydfu.py script. You can use instead the
dfu-util program (available here) by
passing USE_PYDFU=0:
$ make BOARD=PYBV11 USE_PYDFU=0 deploy
If flashing the firmware does not work it may be because you don't have the correct permissions. Try then:
$ sudo make BOARD=PYBV11 deploy
Or using dfu-util directly:
$ sudo dfu-util -a 0 -d 0483:df11 -D build-PYBV11/firmware.dfu
Flashing the Firmware with stlink
ST Discovery or Nucleo boards have a builtin programmer called ST-LINK. With
these boards and using Linux or OS X, you have the option to upload the
stm32 firmware using the st-flash utility from the
stlink project. To do so, connect the board
with a mini USB cable to its ST-LINK USB port and then use the make target
deploy-stlink. For example, if you have the STM32F4DISCOVERY board, you can
run:
$ make BOARD=STM32F4DISC deploy-stlink
The st-flash program should detect the USB connection to the board
automatically. If not, run lsusb to determine its USB bus and device number
and set the STLINK_DEVICE environment variable accordingly, using the format
<USB_BUS>:<USB_ADDR>. Example:
$ lsusb
[...]
Bus 002 Device 035: ID 0483:3748 STMicroelectronics ST-LINK/V2
$ export STLINK_DEVICE="002:0035"
$ make BOARD=STM32F4DISC deploy-stlink
Flashing the Firmware with OpenOCD
Another option to deploy the firmware on ST Discovery or Nucleo boards with a
ST-LINK interface uses OpenOCD. Connect the board with
a mini USB cable to its ST-LINK USB port and then use the make target
deploy-openocd. For example, if you have the STM32F4DISCOVERY board:
$ make BOARD=STM32F4DISC deploy-openocd
The openocd program, which writes the firmware to the target board's flash,
is configured via the file ports/stm32/boards/openocd_stm32f4.cfg. This
configuration should work for all boards based on a STM32F4xx MCU with a
ST-LINKv2 interface. You can override the path to this configuration by setting
OPENOCD_CONFIG in your Makefile or on the command line.
Accessing the board
Once built and deployed, access the MicroPython REPL (the Python prompt) via USB
serial or UART, depending on the board. There are many ways to do this, one of
which is via mpremote (install it using pip install mpremote):
$ mpremote
Other options are picocom and screen, for example:
$ picocom /dev/ttyACM0