.. | |||
TARGET_STM32F0 | 11 months ago | ||
TARGET_STM32F1 | 11 months ago | ||
TARGET_STM32F2 | 11 months ago | ||
TARGET_STM32F3 | 11 months ago | ||
TARGET_STM32F4 | 11 months ago | ||
TARGET_STM32F7 | 11 months ago | ||
TARGET_STM32G0 | 11 months ago | ||
TARGET_STM32G4 | 11 months ago | ||
TARGET_STM32H7 | 11 months ago | ||
TARGET_STM32L0 | 11 months ago | ||
TARGET_STM32L1 | 11 months ago | ||
TARGET_STM32L4 | 11 months ago | ||
TARGET_STM32L5 | 11 months ago | ||
TARGET_STM32U5 | 11 months ago | ||
TARGET_STM32WB | 11 months ago | ||
TARGET_STM32WL | 11 months ago | ||
tools | 2 years ago | ||
CMakeLists.txt | 2 years ago | ||
PeripheralPins.h | 1 year ago | ||
PinNamesTypes.h | 2 years ago | ||
PortNames.h | 7 years ago | ||
README.md | 2 years ago | ||
USBPhyHw.h | 2 years ago | ||
USBPhy_STM32.cpp | 1 year ago | ||
analogin_api.c | 6 years ago | ||
analogout_api.c | 3 years ago | ||
can_api.c | 11 months ago | ||
device.h | 1 year ago | ||
gpio_api.c | 2 years ago | ||
gpio_irq_api.c | 2 years ago | ||
gpio_object.h | 3 years ago | ||
hal_tick_overrides.c | 2 years ago | ||
i2c_api.c | 11 months ago | ||
lp_ticker.c | 2 years ago | ||
lp_ticker_defines.h | 3 years ago | ||
mbed_crc_api.c | 4 years ago | ||
mbed_overrides.c | 2 years ago | ||
mbed_rtx.h | 3 years ago | ||
nvic_addr.h | 3 years ago | ||
ospi_api.c | 11 months ago | ||
pinmap.c | 2 years ago | ||
port_api.c | 7 years ago | ||
pwmout_api.c | 3 years ago | ||
qspi_api.c | 3 years ago | ||
reset_reason.c | 3 years ago | ||
rtc_api.c | 2 years ago | ||
rtc_api_hal.h | 2 years ago | ||
serial_api.c | 1 year ago | ||
serial_api_hal.h | 5 years ago | ||
sleep.c | 2 years ago | ||
stm32_assert.h | 5 years ago | ||
stm_i2c_api.h | 1 year ago | ||
stm_spi_api.c | 2 years ago | ||
trng_api.c | 2 years ago | ||
us_ticker.c | 3 years ago | ||
us_ticker_defines.h | 4 years ago | ||
watchdog_api.c | 2 years ago |
Mandatory: get the latest USB driver in order to make available all the USB interfaces provided by the ST-LINK:
Default Windows USB drivers will not setup full capabilities.
https://www.st.com/en/development-tools/stsw-link009.html
Mandatory: get the latest ST-Link Firmware:
https://www.st.com/en/development-tools/stsw-link007.html
You could have some issue to connect your board if you didn't install full USB drivers.
Note that with the latest FW version, you are able to check the version number easily with a simple "mbedls":
$ mbedls | platform_name | platform_name_unique | mount_point | serial_port | target_id | interface_version | |---------------------|------------------------|-------------|-------------|--------------------------|-------------------| | DISCO_H747I | DISCO_H747I[0] | D: | COM13 | 081402210D03E72132477E08 | V3J7M2 | | DISCO_L475VG_IOT01A | DISCO_L475VG_IOT01A[0] | E: | COM9 | 07640221683B630A577FF553 | V2J37M26 |
$ mbedtools detect Board name Serial number Serial port Mount point(s) Build target(s) Interface Version --------------- ------------------------ ------------- ---------------- ----------------- ------------------- NUCLEO-U575ZI-Q 0022003c5553500d20393256 COM25 D: NUCLEO_U575ZI_Q V3J7M3
https://www.st.com/en/embedded-software/stm32cube-mcu-packages.html
There is one STM32Cube package for each individual STM32 MCU family.
It includes:
Part of STM32Cube files are copied in each targets/TARGET_STM/TARGET_STM32\/STM32Cube_FW directory:
Mbed OS HAL calls ST porting layer, which calls ST HAL and LL API.
Note that all ST HAL and LL files are available:
Each STM32Cube package is also available in Github. This table summarizes the STM32Cube versions currently used in Mbed OS master branch :
STM32 Serie | Cube version | Github source |
---|---|---|
F0 | 1.11.2 | https://github.com/STMicroelectronics/STM32CubeF0 |
F1 | 1.8.3 | https://github.com/STMicroelectronics/STM32CubeF1 |
F2 | 1.6.0 | https://github.com/STMicroelectronics/STM32CubeF2 |
F3 | 1.11.2 | https://github.com/STMicroelectronics/STM32CubeF3 |
F4 | 1.26.1 | https://github.com/STMicroelectronics/STM32CubeF4 |
F7 | 1.16.1 | https://github.com/STMicroelectronics/STM32CubeF7 |
G0 | 1.5.0 | https://github.com/STMicroelectronics/STM32CubeG0 |
G4 | 1.4.0 | https://github.com/STMicroelectronics/STM32CubeG4 |
H7 | 1.9.0 | https://github.com/STMicroelectronics/STM32CubeH7 |
L0 | 1.12.0 | https://github.com/STMicroelectronics/STM32CubeL0 |
L1 | 1.10.2 | https://github.com/STMicroelectronics/STM32CubeL1 |
L4 | 1.17.0 | https://github.com/STMicroelectronics/STM32CubeL4 |
L5 | 1.4.0 | https://github.com/STMicroelectronics/STM32CubeL5 |
U5 | 1.0.0 | https://github.com/STMicroelectronics/STM32CubeU5 |
WB | 1.11.1 | https://github.com/STMicroelectronics/STM32CubeWB |
WL | 1.1.0 | https://github.com/STMicroelectronics/STM32CubeWL |
In Mbed OS repository, we try to minimize the difference between "official" and copied files.
STM32CubeMX is a graphical tool that allows a very easy configuration of all STM32
https://www.st.com/en/development-tools/stm32cubemx.html
Tool is not used in Mbed OS, but it can be useful for you.
It provides an easy-to-use and efficient environment for reading, writing and verifying device memory.
https://www.st.com/en/development-tools/stm32cubeprog.html
Tool is not used in Mbed OS, but it can be useful for you.
It should be "easy" to add your custom board with a STM32 MCU in Mbed OS
You can also check in https://github.com/ARMmbed/stm32customtargets
STM32 root directory is https://github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_STM
This contains:
Each STM32 family contains several "sub-families".
Each STM32 Part Number defines a sub-family: STM32F401 / STM32F407 / STM32F429 / ...
But also each STM32 Part Number with different FLASH size : STM32F401xC / STM32F401xE
Mbed OS porting layer specific for this family are placed here.
Example in TARGET_STM32G0:
Each STM32 sub-family contains:
ST provides the complete support for few NUCLEO and DISCO boards.
Locate one of these boards with the minimum difference with your chosen MCU.
Copy paste, and update!
2 files in Mbed OS:
It is recommended to use a python script to generate those files
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py
This script is using MCU database from https://github.com/STMicroelectronics/STM32_open_pin_data.git repo
$ python targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py -h SScript version 1.19 Checking STM32_open_pin_data repo... *** git clone done usage: STM32_gen_PeripheralPins.py [-h] (-l | -b | -m xml | -t HW | -c CUSTOM) [-g] Script will generate PeripheralPins.c thanks to the xml files description available in STM32_open_pin_data GitHub repo More information in targets/TARGET_STM/README.md optional arguments: -h, --help show this help message and exit -l, --list list available mcu xml files description in STM32CubeMX -b, --boards list available boards description in STM32CubeMX -m xml, --mcu xml specify the mcu xml file description in STM32CubeMX to use (use double quotes). Parameter can be a filter like L496 if you want to parse all L496 chips (-m STM32 to parse all). -t HW, --target HW specify the board file description in STM32CubeMX to use (use double quotes). Parameter can be a filter like L496 (only the first file found will be parsed). -c CUSTOM, --custom CUSTOM specify a custom board .ioc file description to use (use double quotes). -g, --gpio Add GPIO PinMap table Once generated, you have to check and comment pins that can not be used (specific HW, internal ADC channels, remove PWM using us ticker timer, ...)
How to generate files for a custom boards based on a STM32F427 MCU:
$ python targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py -l | grep F427 STM32F427A(G-I)Hx.xml STM32F427I(G-I)Hx.xml STM32F427I(G-I)Tx.xml STM32F427V(G-I)Tx.xml STM32F427Z(G-I)Tx.xml $ python targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py -m "STM32F427V(G-I)Tx.xml" Script version 1.19 Checking STM32_open_pin_data repo... Already up to date. STM32_open_pin_data DB version STM32CubeMX-DB.6.0.10 * Output directory: targets_custom\TARGET_STM\TARGET_STM32F4\TARGET_STM32F427xG\TARGET_STM32F427VGT * Generating PeripheralPins.c and PinNames.h with 'STM32_open_pin_data\mcu\STM32F427V(G-I)Tx.xml' * GPIO file: STM32_open_pin_data\mcu\IP\GPIO-STM32F427_gpio_v1_0_Modes.xml * I/O pins found: 135 connected: 0 * Output directory: targets_custom\TARGET_STM\TARGET_STM32F4\TARGET_STM32F427xI\TARGET_STM32F427VIT * Generating PeripheralPins.c and PinNames.h with 'STM32_open_pin_data\mcu\STM32F427V(G-I)Tx.xml' * GPIO file: STM32_open_pin_data\mcu\IP\GPIO-STM32F427_gpio_v1_0_Modes.xml * I/O pins found: 135 connected: 0
https://os.mbed.com/docs/mbed-os/latest/porting/porting-a-custom-board.html
Example with a board based on STM32F103C8 (like BluePill):
$ python targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py -m "STM32F103C(8-B)Tx.xml" // PeripheralPins.c and PinNames.h template files are created in targets_custom/TARGET_STM/TARGET_STM32F1/TARGET_STM32F103x8/TARGET_STM32F103C8T directory $ mv TARGET_STM32F103C8T TARGET_BLUEPILL_F103C8 // Edit PeripheralPins.c and PinNames.h to match your board configuration // Create a custom_targets.json with: { "BLUEPILL_F103C8": { "inherits": [ "MCU_STM32F103x8" ], "overrides": { "clock_source": "USE_PLL_HSE_XTAL" }, "device_has_remove": [ "STDIO_MESSAGES" ], "device_name": "STM32F103C8" } }
Example with a board based on STM32H745ZI
$ python targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py -m "STM32H745ZITx.xml" // PeripheralPins.c and PinNames.h template files are created in targets_custom/TARGET_STM/TARGET_STM32H7/TARGET_STM32H745xI/TARGET_STM32H745ZIT directory $ mv TARGET_STM32H745ZIT TARGET_H745ZI_BOARD // Edit PeripheralPins.c and PinNames.h to match your board configuration // Create a custom_targets.json with: { "H745ZI_BOARD_CM4": { "inherits": [ "MCU_STM32H745I_CM4" ], "extra_labels_add": [ "H745ZI_BOARD" ] }, "H745ZI_BOARD_CM7": { "inherits": [ "MCU_STM32H745I_CM7" ], "extra_labels_add": [ "H745ZI_BOARD" ] } }
We will be happy to add every public board in https://github.com/ARMmbed/stm32customtargets
Make a Pull request, we will check consistency and build.
It can be useful to have a look on files that describes pin configuration for your board:
You can easily see the alternate functions for each pin.
Ex:
{PC_10, UART_3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF7_USART3)}, {PC_10_ALT0, UART_4, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_UART4)},
The same alternate choice feature is also used for PWM, ADC, SPI, etc...
Sometimes there are some conflicts in pin use.
Ex:
{PA_5, SPI_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI1)}, // Connected to LD2 [green led]
==> You can use PA_5 pin as SPI, only if your application is not using LED...
Sometimes, pin is explicitly removed by default to avoid issues (but you can uncomment the line for your custom board)
// {PB_4, UART_2, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF7_USART2)}, // Connected to same instance as STDIO
System Core Clock is based on an high-speed clock.
For each target, a default choice has been made in the "clock_source" config settings in the targets.json file.
For main targets, it is something like:
"clock_source": { "value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
Meaning that:
Low power ticker and RTC are based on an low-speed clock.
In targets.json file, it is supposed that a LSE is provided in the board
"config": { "lse_available": { "value": "1"
You can change this in you local mbed_app.json:
{ "target_overrides": { "XXXX": { "target.lse_available": "0" } } }
I2C drivers version 2 use I2C timing register.
Enable I2C timing algorithm by setting the value of i2c_timing_value_algo
target config to true
"i2c_timing_value_algo": { "help": "If value was set to true I2C timing algorithm is enabled. Enabling may leads to performance issue. Keeping this false and changing system clock will trigger assert.", "value": false }
Default configuration disables I2C timing algorithm. If user need to use different system clock speed other than default system clock configuration. Then I2C timing calculation algorithm need to enable. To enable
"i2c_timing_value_algo": { "value": true }
ST MCUs feature several low-power modes, please check Reference Manual of each one for more details.
MBED sleep mode is usually mapped to ST SLEEP mode:
MBED deepsleep mode is mapped to ST STOP2 mode:
Detailed sleep Mbed OS description : https://os.mbed.com/docs/mbed-os/latest/apis/power-management-sleep.html
"target_overrides": { "*": { "platform.deepsleep-stats-enabled": true, "platform.deepsleep-stats-verbose": false },
https://github.com/ARMmbed/wifi-ism43362
https://os.mbed.com/teams/ST/wiki/How-to-make-wifi-tests
Depending on your PHY, you will have to customize several configuration values:
Check the default values in: https://github.com/ARMmbed/mbed-os/blob/master/connectivity/drivers/emac/TARGET_STM/mbed_lib.json
Option is also to define your own HAL_ETH_MspInit
function, you then have to add USE_USER_DEFINED_HAL_ETH_MSPINIT macro.
To use the custom IRQ Handler and the callbacks, you need to add USE_USER_DEFINED_HAL_ETH_IRQ_CALLBACK macro inside any of the JASON file in either targets.json or in mbed_app.json file.
For example in the targets.json, you need to add this line in your target:
or for example in the mbed_app.json, you need to add: ``` "macros": ["USE_USER_DEFINED_HAL_ETH_IRQ_CALLBACK"]
By doing the any of the above json files, the corresponding user defined custom apis like HAL_ETH_RxCpltCallback() and STM_HAL_ETH_Handler() can be called from the user application.
To change the default MAC address in STM32, If we have the function mbed_otp_mac_address() in the user application,the default ethernet address can be changed. Because as this is defined as weak in mbed-os/connectivity/drivers/emac/TARGET_STM/stm32xx_emac.cpp
#include "platform/mbed_toolchain.h" MBED_WEAK uint8_t mbed_otp_mac_address(char *mac).
Please find the code snippet here for reference:
.. uint8_t mbed_otp_mac_address(char *mac); uint8_t mbed_otp_mac_address(char *mac) { unsigned char ST_mac_addr[6] = {0x00, 0x88, 0xe0,0x90,0x80,0x70}; // New User mac address // printf("%s:%s\n",__FILE__,__func__); memcpy(mac,ST_mac_addr,sizeof(ST_mac_addr)); return 1; } int main() { // Bring up the ethernet interface printf("Ethernet socket example\n"); uint8_t MyMAC[6]; printf("return of set_mac_address:%d\n",net.set_mac_address(MyMAC,sizeof(MyMAC))); net.connect(); printf("MAC address %s\n",net.get_mac_address()); ...
The current Asynchronous SPI implementation will not be able to support high speeds (MHz Range). The maximum speed supported depends on
For application that require optimized maximum performance, the recommendation is to implement the DMA-based SPI transfer. The SPI DMA transfer support shall be implemented on a case-by-case based on below example https://github.com/ABOSTM/mbed-os/tree/I2C_SPI_DMA_IMPLEMENTATION_FOR_STM32L4
In bxCAN and earlier versions the receive interrupt flags can be cleared only on performing a read operation in ST MCUs But can_read() cannot be used in interrupt context as it is gaurded by lock operation and mbed does not allow locks in interrupt context. Hence the Rx interrupt is disabled for a while and read is deferred to thread context, the interrupt is enabled on a successful read.
As an other option RawCAN (with unlocked CAN apis) is also available and can be used directly, if only one thread is accessing the CAN interface.
While using RxInterrupt with the CAN object the receive ISR callback registered should defer read to thread context. A simple example is as shown below:
#include "mbed.h" Ticker ticker; Thread canReadThread; DigitalOut led1(LED1); DigitalOut led2(LED2); DigitalOut led3(LED3); CAN can1(PD_0 ,PD_1); EventQueue queue(32 * EVENTS_EVENT_SIZE); int counter = 0xABCD; CANMessage msg; void canRead(){ if(can1.read(msg)) { if(msg.id==1100) led2 = !led2; if(msg.id==1102){ led3 = !led3; } } } void canISR(){ queue.call(canRead); led3 = !led3; } int main() { can1.frequency(100000); can1.mode(CAN::Normal); can1.attach(canISR, CAN::RxIrq); canReadThread.start(callback(&queue, &EventQueue::dispatch_forever)); while(1) { } }
https://os.mbed.com/teams/ST/wiki/
https://os.mbed.com/teams/ST/wiki/STDIO
https://os.mbed.com/teams/ST/wiki/How-to-enable-flash-dual-bank
https://os.mbed.com/teams/ST/wiki/Nucleo-144pins-ethernet-spi-conflict