[stm32f4, stm32f411_blackpill] Initial stm32f4 implementation#23
[stm32f4, stm32f411_blackpill] Initial stm32f4 implementation#23AlexLanzano merged 1 commit intowolfSSL:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adds an initial STM32F4 platform bring-up (focused on STM32F411 BlackPill) by introducing STM32F4-specific clock (RCC), UART, SPI, and flash drivers, plus a new board port and build artifacts to run wolfHAL on the target.
Changes:
- Introduce STM32F4 driver implementations for RCC (PLL), UART (USARTv1), SPI, and embedded flash.
- Add STM32F411xx convenience device/clock macros and a new
stm32f411_blackpillboard port (startup, linker script, board init). - Reuse the existing STM32WB GPIO driver via an STM32F4 alias wrapper.
Reviewed changes
Copilot reviewed 17 out of 17 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
| wolfHAL/uart/stm32f4_uart.h | STM32F4 UART config/types and driver API declarations. |
| wolfHAL/spi/stm32f4_spi.h | STM32F4 SPI config/types and driver API declarations. |
| wolfHAL/platform/st/stm32f411xx.h | Convenience macros for STM32F411 device instances and clock gates. |
| wolfHAL/gpio/stm32f4_gpio.h | Alias header mapping STM32F4 GPIO API to STM32WB implementation. |
| wolfHAL/flash/stm32f4_flash.h | STM32F4 flash configuration (sectors/latency) and driver API declarations. |
| wolfHAL/clock/stm32f4_rcc.h | STM32F4 RCC PLL configuration structures and driver API declarations. |
| src/uart/stm32f4_uart.c | STM32F4 USARTv1 UART driver implementation. |
| src/spi/stm32f4_spi.c | STM32F4 SPI driver implementation (master mode, SW NSS). |
| src/gpio/stm32f4_gpio.c | STM32F4 GPIO implementation aliasing STM32WB driver source. |
| src/flash/stm32f4_flash.c | STM32F4 embedded flash driver (read/write/erase, latency ext). |
| src/clock/stm32f4_rcc.c | STM32F4 RCC PLL clock driver implementation. |
| boards/stm32f411_blackpill/Makefile.inc | New board build configuration selecting STM32F4 platform and sources. |
| boards/stm32f411_blackpill/linker.ld | Linker script for STM32F411 (512KB flash / 128KB RAM). |
| boards/stm32f411_blackpill/ivt.c | Startup/IVT for STM32F411 BlackPill. |
| boards/stm32f411_blackpill/board.h | Board globals/pin definitions and board API. |
| boards/stm32f411_blackpill/board.c | Board initialization wiring clocks, GPIO, UART, SPI, SysTick timer, flash. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 18 out of 18 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| for (size_t i = 0; i < dataSz; i += 4) { | ||
| uint32_t *flashAddr = (uint32_t *)(addr + i); | ||
| const uint32_t *dataAddr = (const uint32_t *)(data + i); | ||
|
|
||
| *flashAddr = *dataAddr; |
There was a problem hiding this comment.
whal_Stm32f4Flash_Write() casts the const uint8_t *data buffer to const uint32_t * and dereferences it. Even though addr/dataSz are checked for 4-byte alignment, the data pointer itself may be unaligned, which can trigger an unaligned 32-bit access fault on Cortex-M. Consider assembling the 32-bit word from bytes (or copying into a local uint32_t with memcpy) before programming each word, and/or validate data alignment explicitly.
| /* Write byte to data register (must not read DR — use pure write) */ | ||
| whal_Reg_Write(reg->base, UART_DR_REG, buf[i]); | ||
| } | ||
|
|
There was a problem hiding this comment.
The UART driver’s Send operation is specified to be blocking until all bytes are fully transmitted (see docs/writing_a_driver.md UART section). This implementation waits for TXE before each write, but returns immediately after the last byte is written without polling the transmission-complete flag (TC), so the final byte may still be shifting out when Send returns. Add a final poll on TC after the loop (and clear TC as required by the USARTv1 semantics) so Send is fully blocking.
| if (dataSz > 0) { | |
| whal_Error err; | |
| /* Wait for transmission complete for the last byte */ | |
| err = whal_Reg_ReadPoll(reg->base, UART_SR_REG, UART_SR_TC_Msk, | |
| UART_SR_TC_Msk, cfg->timeout); | |
| if (err) | |
| return err; | |
| /* Clear TC flag according to USARTv1 semantics */ | |
| whal_Reg_Update(reg->base, UART_SR_REG, | |
| UART_SR_TC_Msk, | |
| whal_SetBits(UART_SR_TC_Msk, UART_SR_TC_Pos, 0)); | |
| } |
| /* Determine source frequency */ | ||
| if (pllCfg->clkSrc == WHAL_STM32F4_RCC_PLLCLK_SRC_HSI) | ||
| srcFreq = 16000000; | ||
| else | ||
| srcFreq = 25000000; | ||
|
|
There was a problem hiding this comment.
whal_Stm32f4RccPll_GetRate() hardcodes HSE to 25 MHz. STM32F4 boards commonly use different crystal frequencies (e.g., 8 MHz), so GetRate will report an incorrect SYSCLK on those boards. Consider making the HSE frequency a field in the RCC/PLL config (or otherwise board-provided) and using that value here, or at minimum document/annotate the 25 MHz assumption (similar to the TODO in src/clock/stm32h5_rcc.c).
No description provided.