STM32Cube is an STMicroelectronics original initiative to ease the developers life by reducing efforts, time and cost.
STM32Cube covers the overall STM32 products portfolio (MCU and MPU). It includes a comprehensive embedded software platform, delivered for each STM32 series.
The CMSIS modules (core and device) corresponding to the ARM(tm) core implemented in this STM32 product.
The STM32 HAL-LL drivers, an abstraction layer offering a set of APIs ensuring maximized portability across the STM32 portfolio.
The BSP drivers of each evaluation, demonstration, or nucleo board provided for this STM32 series.
A consistent set of middleware libraries such as RTOS, USB, FatFS, graphics, touch sensing library...
A full set of software projects (basic examples, applications, and demonstrations) for each board provided for this STM32 series.
GitHub is a new publication model for the STM32Cube MCU embedded software. Different models of publication are proposed:
The MCU Package: A unique repo per STM32 MCU series containing the different components of a STM32 MCU firmware (Drivers, Middleware, Utilities, Examples). Please refer to the STM32Cube MCU Packages chapter below.
The MCU components: Each component of a STM32 MCU firmware (Drivers, Middleware, Utilities) is proposed in a dedicated repo, allowing the user to select and get only the required ones. Please refer to the STM32Cube MCU Components chapter below.
The X-CUBE: Expansion software proposing examples and applications that complement the ones of the STM32Cube firmware.
A set of MCU Utilities: Various utility features proposed in dedicated repos.
Please note that a MPU offer is also proposed for the STM32 MPU Products. You can refer to the repo STM32MPU_EmbSW_Overall_Offer.
Description
This repo is a simple Readme describing all STM32 MCU related GitHub projects, the overall offer for the STM32 MCU products.
This new publication channel of the STM32Cube embedded software components will provide new added values:
In complement to the MCU Package zip files today proposed on st.com, the capability for STM32 customers to get a configuration management based delivery (Git)
A more direct communication between developers, thanks to the Issues features. Caution: only software related questions will be taken into account. Any other subject must be submitted to the ST Community forum
Thanks to the deployment of a Contributor License Agreement feature (please refer to each repo CONTRIBUTING guide), the Pull-Request permits also to take into account customers proposed updates and enrich the STM32Cube FW offer.
For general communication and support, you can use
The STM32Cube expansion software contains embedded software components that complement the functionalities of the STM32Cube and/or enable the usage of a multitude of ST devices in domains such as of sensing, power management, connectivity or audio, together with the most appropriate STM32 MCUs.
Provides examples and drivers for STM32 to recognize sensors and collect temperature, humidity, pressure, motion, and ISPU (Intelligent Sensor Processing Unit) data.
STM32 Function Packs (FP) are a combination of low-level drivers, middleware libraries and sample applications assembled into a single software package. You can get the entire list of available Function Packs on st.com here.
The below list represents the Function Packs available on github.com
STM32Cube function pack for acquiring audio signals from 4 digital MEMS microphones, processing them, and streaming them to both a USB host and a loudspeaker.
STM32Cube function pack for IoT node with BLE connectivity to view environmental and intertial sensors data, plus some advanced functionalities (e.g., voice communication over BLE, sound source localization).
STM32Cube function pack for IoT node with BLE connectivity to save data from any combination of sensors and microphones configured up to the maximum sampling rate.
STM32Cube function pack for IoT node with BLE connectivity to save data from any combination of sensors and microphones configured up to the maximum sampling rate (evolution of the fp-sns-datalog1 pack).
STM32Cube function pack for STEVAL-STWINBX1 and EVLSPIN32G4-ACT to collect heterogeneous data, combining STWIN.box sensor information with STSPIN32G4 motor control data (derived from the fp-sns-datalog2 pack).
STM32Cube function pack for IoT node with BLE connectivity to view environmental and intertial sensors data for F4, L0, and L4 based on the BlueNRG transceiver.
STM32Cube function pack for the Pro Mode of wireless multi sensor development kits.
STM32Cube MCU Components
As mentioned above, the STM32Cube Components is an alternative delivery model to the STM32 Packages. In this case, each module is delivered as individual repos, allowing the customer to select and download only the pertinent features.
Components available today: CMSIS - HAL/LL - BSP - Base MW (USB, FatFS, FreeRTOS, LwIP)
Components upcoming: Other MW - Utilities
In each module README file you will find the cross compatibility information. When all modules will be available a set of new Manifest files (series by series) will be proposed to drive the user.
The HAL Drivers MCU Components propose the HAL and LL Drivers modules controlling all the HW IPs embedded in the STM32 products.
HAL Drivers:
A set of portable abstraction APIs offering high level services, built around standalone processes. The HAL drivers are functionalities oriented, example: for the Timer peripheral, the APIs could be split into several categories following the functions offered by the IPs (Basic timer, capture, PWM...) for a communication IP: an initialisation function, eventually a configuration function and data transfer services (polling, interruption or DMA based)
The compatibility SHALL be guaranteed across all the STM32 families for the generic APIs, including generic macros and common structures defines. Any specific feature is given in a dedicated extension model available in the associated extension files
LL Drivers:
Low Layer Drivers: a set of basic functions with direct hardware access (no standalone process), this layer can be called either by applications or by the HAL drivers.
HAL and LL Drivers are provided in the same module/repo
The dynamic usage of HAL APIs is provided thru projects examples, available in the respective STM32Cube MCU Packages STM32Cubexx where xx correspond to the series
The BSP Drivers MCU Components propose the BSP Drivers modules, which are constituted from the:
STM32Cube BSP Boards Drivers, based on the HAL drivers, and providing a set of high level APIs allowing a quick access to the boards services (e.g., audio, graphics, access to external memories).
STM32Cube BSP Components Drivers providing a set of high level APIs allowing a quick access to the (e.g., audio codecs, LCD drivers, SD cards, MEMS). The link between these external components and the HAL drivers (e.g., a SD card and the OSPI/QSPI HAL driver) is done within the BSP Boards drivers.
NOTE: A number of BSP components drivers (particularly of MEMS) come in two forms, each addressing a different purpose. For each one of such BSP components drivers, two repositories are available as explained below:
PID: Platform-Independent Drivers. Recognizable to their repositories' names <bspcomp> (e.g., hts221). Are low-level drivers allowing direct access to components' registers. These drivers are independent of any software platform, as the acronym PID suggests. The complete list can be found here.
STM32: STM32Cube-compatible drivers. Recognizable to their repositories' names stm32-<bspcomp> (e.g., stm32-hts221). Are hardware-abstracted drivers, specially designed to be compatible with the STM32Cube software offer, as the stm32- prefix suggests. The complete list is provided below (refer particularly to tables MEMS and Temperature Sensor).
It looks like stm32cube programmer does not erase proper page 12/erases non existent page 8 in some corner case of dual bank
I'm having a problem with STM32CubeProgrammer and a 1MB STM32F767ZG configured in dual bank mode. On the left, I tried to flash a 520k bin to the device, over the top of previous firmware.
Expected behavior: erase sectors 0-7, 12, then write 520K bytes starting at address 0x08000000.
Actual behavior: erases sectors 0-8, then write 520K bytes starting at address 0x08000000.
Since it tries to erase the non-existent sector 8, sector 12 (the actual sector at 0x08080000) doesn't get erased and as such the contents of sector 12 get corrupted by the multiple writes without an erase.
See screenshot below: stm32cubeprogrammer tries to erase sector 8 at 0x0808 0000, but in dual bank mode, there is no sector 8!
Historically, device headers, eg stm32F303.h, have lines like this:
#include "core_cm4.h" /* Cortex-M4 processor and core peripherals */
#include "system_stm32f3xx.h" /* STM32F3xx System Header */
But in some newer ones, eg stm32L562.h, it is now like this:
#include <core_cm33.h> /*!< ARM Cortex-M33 processor and core peripherals */
#include "system_stm32l5xx.h" /*!< STM32L5xx System */
Putting just the one CMSIS header but not the other in the -isystem search path instead of the -iquote search path is, obviously, crazed. I think they correctly belong in the -iquote search path, and why change from the past?
Please replace #include <core_cm...h> with #include "core_cm...h" everywhere that it got messed up.
I have been using STM32 series for years and I tend to swap between the STM32G0, STM32F0, STM32F4, STM32G4 and now the STM32C0. I have been using drivers but would love to only have a general driver that worked for all STM32xx MCU's they all seem very similar and could be easily done with some macros( #ifdefs and such ) based on configurations of each chip. this would allow validation to be easier since the same code would work for all MCUs and not need to be revalidated. also seems extensive to manage multiple sets of drivers that may get stale and have opputunity to improve the size and speed of code.
as the subject states, it would be nice to have some pre-configured PlatformIO project "code" generation from CubeMX.
This is currently some barrier to start tinkering around with Nucleo boards. PlatformIO is used a lot in the Maker community and the STM32 support is really great atm. CubeMX generation PlatformIO projects would be even greater.
I've noticed that several PDFs are invalid format, ie. they are not displayed by the browser and also cannot be opened by my local PDF renderer. This seems to be a new problem, maybe a month ago, these PDFs were still valid, did you change something in your CDN setup maybe?
Here are the URLs of the invalid PDFs I could find (there may be more that I haven't found).
I am not sure if this is the best place to write this issue/idea but the only I found.
Firstly thank yo for all the support, hoewer as an end user not much experienced yet, I found examples hard to use (in other words you idea is that your software provided should speed up "production process", however is not). With the Examples you do not provide .ioc file (which would be very useful for further adjustments), secondly the examples are not compatible with code generated by STMCube tools (MX or IDE) which again make things time consuming to make it working.
I also found Cube MX verry buggy (especially clock configurator).
One thing that would be great is if ST could have *.svd files for all device families on GitHub. If linked here as well, this could be a one-stop shop to have everything needed source-wise to develop and debug applications on STM32 hardware.
The STM32Cube MCU Packages listed in this repository contain vulnerable usb device middleware.
Multiple usb device classes are affected by buffer overflows allowing successful attacks on devices.
The issue was reported to ST and resolved in march 2021 (https://github.com/stmicroelectronics/stm32_mw_usb_device/, release 2.8.0) but the fixed implementation was not incorporated in MCU specific Cube packages till now. So despite the fixes available users are still creating vulnerable applications for months. Furthermore the corresponding CVE-2021-38541 still was not published. The PSIRT team at [email protected] ignores my questions about updating Cube MCU Packages with up to date middleware and CVE.
Thank you for sharing HAL drivers etc. on Github!
I suggest rename this repo to something more meaningful.
Why call it STM32Cube when it is more about HAL?
Why call it Overall Offer? Overall implies something generic, non-specific while offer implies it is something for sale or trade exchange. Certainly this name does NOT encourage community participation. Quite opposite - to be honest.
It also makes this repo impossible to find if someone simply looks for STM32 HAL.
IMHO it is a very bad name. I suggest get more opinions, consult it with someone more familiar with Github and English language usage - I am not an expert.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent