48f67d007e
complete pin mapping for Feather pins
stubbed out files needed for complilation. still to be modified
0 out all CPY modules in mpconfigboard.mk until we get the build running
add csv for pin generation for STM32L4R5
add F4R5 references in peripherals files
refactored out board files BECAUSE I AM AN IDIOT; add L4 series system clocks file from CubeMX
took a guess at the number of USB endpoint pairs to get the build done
guess was close, but wrong. It is 8
clean up peripheral DEFs
Fixes build error:
```
In file included from ../../py/mpstate.h:33,
from ../../py/mpstate.c:27:
../../py/misc.h: In function 'vstr_str':
../../py/misc.h:196:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
static inline char *vstr_str(vstr_t *vstr) {
^~~~~~
```
Sleuthing steps:
* verify that the feather_stm32f4_express board builds correctly
* put a `#error` at the bottom of the `mpstate.c` file.
* build for the feather and swan boards, with V=2 to capture the build command for that file.
* use a differencing tool to inspect the differences between the two invocations
* inspecting the differences, I saw a missing `-mcpu=cortex-m4` I tested by adding that to the Swan build command. The file built fine (stopping at the hard error, but no other warnings.)
A grep through the sources revealed where this flag was being set for the stm ports.
With this commit, the build gets further, but does not complete. The next exciting episode in this unfolding coding saga is just a commit away!
working build with minimal set of modules for the Blues Swan r5
chore:change header copyright name to Blues Wireless Contributors
USB operational. Fixed up clocks to be hardwired for LSE no HSE case. (Trying to combine HSE in there made the code much more complex, and I don't have a board to test it out on.)
USART working
adds support for `ENABLE_3V3` and `DISCHARGE_3V3` pins. I am surprised that pin definitions are quite low-level and don't include default direction and state, so the code currently has to initialize `ENABLE_3V3` pin as output. The LED takes over a second to discharge, so I wonder if the board startup code is not having the desired affect.
short circuit implementation of backup memory for the STM32L4
all the ports
remove company name from board name to be consistent with the Arduino board definition.
add default pins for I2C, SPI and UART, so that `board.I2C` et al. works as expected. Confirmed I2C timing.
fix board name
fix incorrect pin definition. add test to allow manual check of each output pin
analog IO
code changes for WebUSB. Doesn't appear to work, will revisit later.
ensure that `sys.platform` is available
checkin missing file
feat: make room for a larger filesystem so the sensor tutorial will fit on the device.
fix:(stm32l4r5zi.csv): merged AF0-7 and AF8-15 into single lines and removed extraneous headers mixed in with the data.
fix(parse_af_csv.py): pin index in the csv is 0 not 1, and AF index made 1 larger
chore(Swan R5): update peripherals pins from `parse_af_csv.py` output
optimize flash sector access
|
||
|---|---|---|
| .. | ||
| boards | ||
| common-hal | ||
| hal_conf | ||
| packages | ||
| peripherals | ||
| st_driver@1900834751 | ||
| supervisor | ||
| tools | ||
| .gitignore | ||
| Makefile | ||
| README.md | ||
| background.c | ||
| background.h | ||
| fatfs_port.c | ||
| mpconfigport.h | ||
| mpconfigport.mk | ||
| mpconfigport_nanbox.h | ||
| mphalport.c | ||
| mphalport.h | ||
| qstrdefsport.h | ||
README.md
Circuitpython on STM32
This port brings the ST Microelectronics STM32 series of MCUs to Circuitpython. STM32 chips have a wide range of capability, from <$1 low power STM32F0s to dual-core STM32H7s running at 400+ MHz. Currently, only the F4, F7, and H7 families are supported, powered by the ARM Cortex M4 and M7 processors.
Refer to the ST Microelectronics website for more information on features sorted by family and individual chip lines: st.com/en/microcontrollers-microprocessors/stm32-high-performance-mcus.html
STM32 SoCs vary product-by-product in clock speed, peripheral capability, pin assignments, and their support within this port. Refer to mpconfigport.mk for a full list of enabled modules sorted by family.
How this port is organized:
- boards/ contains the configuration files for each development board and breakout available on the port, as well as system files and both shared and SoC-specific linker files. Board configuration includes a pin mapping of the board, oscillator information, board-specific build flags, and setup for OLED or TFT screens where applicable.
- common-hal/ contains the port-specific module implementations, used by shared-module and shared-bindings.
- packages/ contains package-specific pin bindings (LQFP100, BGA216, etc)
- peripherals/ contains peripheral setup files and peripheral mapping information, sorted by family and sub-variant. Most files in this directory can be generated with the python scripts in tools/.
- st-driver/ submodule for ST HAL and LL files generated via CubeMX. Shared with TinyUSB.
- supervisor/ contains port-specific implementations of internal flash, serial and USB, as well as the port.c file, which initializes the port at startup.
- tools/ python scripts for generating peripheral and pin mapping files in peripherals/ and board/.
At the root level, refer to mpconfigboard.h and mpconfigport.mk for port specific settings and a list of enabled modules.
Build instructions
Ensure your clone of Circuitpython is ready to build by following the guide on the Adafruit Website. This includes installing the toolchain, synchronizing submodules, and running mpy-cross.
Once the one-time build tasks are complete, you can build at any time by navigating to the port directory:
$ cd ports/stm
To build for a specific circuitpython board, run:
$ make BOARD=feather_stm32f405_express
You may also build with certain flags available in the makefile, depending on your board and development goals. The following flags would enable debug information and correct flash locations for a pre-flashed UF2 bootloader:
$ make BOARD=feather_stm32f405_express DEBUG=1 UF2_BOOTLOADER=1
USB connection
Connect your development board of choice to the host PC via the USB cable. Note that for most ST development boards such as the Nucleo and Discovery series, you must use a secondary OTG USB connector to access circuitpython, as the primary USB connector will be connected to a built-in ST-Link debugger rather than the chip itself.
In many cases, this ST-Link USB connector will still need to be connected to power for the chip to turn on - refer to your specific product manual for details.
Flash the bootloader
Most ST development boards come with a built-in STLink programming and debugging probe accessible via USB. This programmer may show up as an MBED drive on the host PC, enabling simple drag and drop programming with a .bin file, or they may require a tool like OpenOCD or StLink-org/stlink to run flashing and debugging commands.
Many hobbyist and 3rd party development boards also expose SWD pins. These can be used with a cheap stlink debugger or other common programmers.
For non-ST products or users without a debugger, all STM32 boards in the high performance families (F4, F7 and H7) include a built-in DFU bootloader stored in ROM. This bootloader is accessed by ensuring the BOOT0 pin is held to a logic 1 and the BOOT1 pin is held to a logic 0 when the chip is reset (ST Appnote AN2606). Most chips hold BOOT low by default, so this can usually be achieved by running a jumper wire from 3.3V power to the BOOT0 pin, if it is exposed, or by flipping the appropriate switch or button as the chip is reset. Once the chip is started in DFU mode, BOOT0 no longer needs to be held high and can be released. An example is available in the Feather STM32F405 guide.
Windows users will need to install stm32cubeprog, while Mac and Linux users will need to install dfu-util with brew install dfu-util or sudo apt-get install dfu-util. More details are available in the Feather F405 guide.
Flashing the circuitpython image with DFU-Util
Ensure the board is in dfu mode by following the steps in the previous section. Then run:
$ make BOARD=feather_stm32F405_express flash
Alternatively, you can navigate to the build directory and run the raw dfu-util command:
dfu-util -a 0 --dfuse-address 0x08000000 -D firmware.bin
Accessing the board
Connecting the board to the PC via the USB cable will allow code to be uploaded to the CIRCUITPY volume.
Circuitpython exposes a CDC virtual serial connection for REPL access and debugging. Connecting to it from OSX will look something like this:
screen /dev/tty.usbmodem14111201 115200
You may also use a program like mu to assist with REPL access.