fd2ff867a0
The SCSI driver calls GetCapacity to get the block size and number of blocks of the underlying block-device/LUN. It caches these values and uses them later on to verify that reads/writes are within the bounds of the LUN. But, prior to this commit, there was only one set of cached values for all LUNs, so the bounds checking for a LUN could use incorrect values, values from one of the other LUNs that most recently updated the cached values. This would lead to failed SCSI requests. This commit fixes this issue by having separate cached values for each LUN. Signed-off-by: Damien George <damien@micropython.org> |
||
---|---|---|
.. | ||
boards | ||
lwip_inc | ||
mbedtls | ||
mboot | ||
usbdev | ||
usbhost | ||
Makefile | ||
README.md | ||
accel.c | ||
accel.h | ||
adc.c | ||
adc.h | ||
autoflash | ||
btstack.c | ||
bufhelper.c | ||
bufhelper.h | ||
can.c | ||
can.h | ||
dac.c | ||
dac.h | ||
dma.c | ||
dma.h | ||
eth.c | ||
eth.h | ||
extint.c | ||
extint.h | ||
factoryreset.c | ||
factoryreset.h | ||
fatfs_port.c | ||
fdcan.c | ||
flash.c | ||
flash.h | ||
flashbdev.c | ||
font_petme128_8x8.h | ||
gccollect.c | ||
gccollect.h | ||
help.c | ||
i2c.c | ||
i2c.h | ||
i2cslave.c | ||
i2cslave.h | ||
irq.c | ||
irq.h | ||
lcd.c | ||
lcd.h | ||
led.c | ||
led.h | ||
machine_adc.c | ||
machine_i2c.c | ||
machine_spi.c | ||
machine_timer.c | ||
machine_uart.c | ||
main.c | ||
make-stmconst.py | ||
modbluetooth_hci.c | ||
modmachine.c | ||
modmachine.h | ||
modnetwork.c | ||
modnetwork.h | ||
modnwcc3k.c | ||
modnwwiznet5k.c | ||
modpyb.c | ||
modstm.c | ||
moduos.c | ||
modusocket.c | ||
modutime.c | ||
mpconfigboard_common.h | ||
mpconfigport.h | ||
mpconfigport.mk | ||
mpconfigport_nanbox.h | ||
mphalport.c | ||
mphalport.h | ||
mpthreadport.c | ||
mpthreadport.h | ||
mpu.h | ||
network_lan.c | ||
network_wiznet5k.c | ||
nimble.c | ||
pendsv.c | ||
pendsv.h | ||
pin.c | ||
pin.h | ||
pin_defs_stm32.c | ||
pin_defs_stm32.h | ||
pin_named_pins.c | ||
pin_static_af.h | ||
portmodules.h | ||
powerctrl.c | ||
powerctrl.h | ||
powerctrlboot.c | ||
pyb_can.c | ||
pyb_i2c.c | ||
pyb_spi.c | ||
pybcdc.inf_template | ||
pybthread.c | ||
pybthread.h | ||
qspi.c | ||
qspi.h | ||
qstrdefsport.h | ||
resethandler.s | ||
resethandler_m0.s | ||
rfcore.c | ||
rfcore.h | ||
rng.c | ||
rng.h | ||
rtc.c | ||
rtc.h | ||
sdcard.c | ||
sdcard.h | ||
sdio.c | ||
sdio.h | ||
sdram.c | ||
sdram.h | ||
servo.c | ||
servo.h | ||
softtimer.c | ||
softtimer.h | ||
spi.c | ||
spi.h | ||
spibdev.c | ||
stm32_it.c | ||
stm32_it.h | ||
storage.c | ||
storage.h | ||
system_stm32.c | ||
systick.c | ||
systick.h | ||
timer.c | ||
timer.h | ||
uart.c | ||
uart.h | ||
usb.c | ||
usb.h | ||
usbd_cdc_interface.c | ||
usbd_cdc_interface.h | ||
usbd_conf.c | ||
usbd_conf.h | ||
usbd_desc.c | ||
usbd_desc.h | ||
usbd_hid_interface.c | ||
usbd_hid_interface.h | ||
usbd_msc_interface.c | ||
usbd_msc_interface.h | ||
usrsw.c | ||
usrsw.h | ||
wdt.c | ||
wdt.h |
README.md
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 and STM32L4. 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), and PYBLITEv1.0 (with STM32F411). 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.
The STM32H7 series has preliminary support: there is a working REPL via USB and UART, as well as very basic peripheral support, but some things do not work and none of the advanced features of the STM32H7 are yet supported, such as the clock tree. At this point the STM32H7 should be considered as a fast version of the STM32F7.
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
.
First the submodules must be obtained using:
$ make submodules
Then to build for a given board, run:
$ make BOARD=PYBV11
The default board is PYBV10 but any of the names of the subdirectories in the
boards/
directory can be passed as the argument to BOARD=
. The above command
should produce binary images in the build-PYBV11/
subdirectory (or the
equivalent directory for the board specified).
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. For the pyboard you can try:
$ picocom /dev/ttyACM0