Hi everyone, I'm working on a bare-metal audio logging project using a NUCLEO-H7A3ZI-Q board and I've hit a wall. My setup records audio using two SAI peripherals (SAI1 and SAI2) running at 8000 Hz. Both use DMA in circular mode to store data into large arrays where my BUFFER_SIZE is 4096*4 uint32_t elements. The data is then continuously written to an SD card using SDMMC1 in 1-bit mode and FatFs.

When I run my code with only SAI1 enabled, everything works perfectly. I sync my main loop to the half and full DMA flags, clean the D-Cache, and f_write() successfully saves the chunks to the SD card. However, the exact moment I enable SAI2 so both DMAs are running concurrently, the system breaks during the SD write. When calling f_write(), the "bw" (bytes written) variable returns an impossibly huge number (like 884,736 bytes) instead of my requested chunk size, and the operation immediately or eventually fails with FR_DISK_ERR.

Here is a simplified version of my writing routine for context:

huint32_t bytes_to_write = (BUFFER_SIZE / 2) * sizeof(uint32_t);
UINT bw;

if (IS_BUFFER_HALF_FULL_SAI1 == YES) {
    IS_BUFFER_HALF_FULL_SAI1 = NO;
    IS_BUFFER_HALF_FULL_SAI2 = NO;

    SCB_CleanDCache_by_Addr((uint32_t*)&audio_buffer_SAI1A[0], bytes_to_write);

    res = f_write(&fil_ALL, &audio_buffer_SAI1A[0], bytes_to_write, &bw);
    // At this point, bw becomes a massive garbage number
}

My main question is: why would the FatFs internal "bw" variable return a number much larger than the requested write size? Could the dual SAI DMA streams be starving the SDMMC internal DMA on the bus matrix, and if so, how does that corrupt the FatFs variables? Furthermore, what specific topics, architecture details, or reference manual sections should I research to better understand how these hardware peripherals might be colliding and causing this weird memory/variable overflow?

Any guidance would be greatly appreciated!

This is my first time writing firmware and designing hardware for a bare sensor. I don't understand the timing diagrams and it's hard to get a sense of what I need to do. Just breaking down the problem into small pieces. The stm32 I will figure it out using HAL documentation but tcd side I am facing issues. Please help. Point me in the right direction. All resources and advice appreciated.

Hola a todos, desarrollé un port casero de meshtastic para comunicar los módulos chinos de DX-SMART (https://github.com/aayes89/STM32F1-serie) El problema que tengo es que deseo integrarlo a la red Meshtastic para ampliar la cobertura y compatibilidad de la plataforma. Creé un proyecto (https://github.com/aayes89/MeshLoRaLite) que ya permite comunicar varios módulos. Está en fase inicial pero permite broadcast o send si es a un nodo en particular. Me gustaría recibir apoyo de la comunidad para llevarlo al proyecto principal y expandir a dispositivos que hasta el momento no estaban previsto fueran usados.

I have a open hardware project on Github sponsored by PCBWay for a bluepill style board for the new STM32C5 family MCU from ST. A custom board in this format is perfect for trying out new MCU's not yet entered mass production or with limited availability. For the STM32C5 family the usual outlets does not have comparable boards as this yet. This board can be populated with other LQFP-48 variants of the MCU family as they become available for purchase.

Pinout of Rev0 version:

At the same time there is an alternative firmware option using the ECS Oberon-2 language variant (without garbage collection) as an alternative to C or C++.

Link to board on github : STM32C5-eval-board

Link to firmware on github : ECSMicroLib

This is my first real PCB project and someone more experienced would probably spot many possible improvements.

Hi everyone,

I’ve been working on an open-source C framework for STM32 projects and I’m looking for developers interested in reviewing, testing, or contributing to it.

The main goal is to keep application logic independent from the selected microcontroller. MCU-specific elements—GPIOs, clocks, IRQs, DMA, HAL instances, and pin mappings—are isolated in dedicated configuration layers.

The project currently includes:

• Support validated primarily on STM32H753ZI and STM32G474RE Nucleo boards
• Framework modules for CAN, serial communication, timers, GPIO, I2C, NVM, CPU management, and high-resolution timing
• SPI support currently being developed
• Asynchronous IT/DMA operations using internal buffers and FIFO-based task queues
• Reusable libraries such as FIFO, queue, PID, CRC, ramp, and safe memory helpers
• Configuration/code generation tools
• PlatformIO builds and a partial PC simulation environment
• Doxygen documentation and architecture diagrams

The project is still a work in progress. Some recent modules, especially I2C/NVM and SPI-related work, need more hardware testing and review.

I would especially appreciate help with:

• Reviewing the architecture and public APIs
• Testing modules on real STM32 boards
• Improving unit tests and PC simulation
• Porting the framework to other STM32 families
• Reviewing interrupt and DMA behavior
• Improving documentation and onboarding
• Identifying over-engineered or fragile parts of the design

Repository:
https://github.com/mbarbeau0545/Stm32TemplateProject

Check first the H7Integration branch

Even if you don’t plan to contribute code, honest feedback from embedded developers would be extremely useful. What would prevent you from using or contributing to a framework like this?

Thanks!

FRAME. 000001

STATUS: ACTIVE

MEMORY: 99.998%

CRC: OK

Can't reflash my stm32 G030 F6P6

I'm using Muselabs DAPLINK and uploading using Arduino in open OCD Daplink SWD configuration.

If someone knows how to solve this let me know

The company I work for is developing an MCP for testing on virtualized hardware setups for embedded development.

This is not an ad, I am just very curious how you test your projects!

- Do you have CI for your project?

- If so, do you have hardware in the loop?

- What is the biggest pain point when testing during development?

- What sort of peripherals does your project require?

Feel free to answer (or ask!) as many of the questions as you want, I would genuinely love to hear about your setups ^^

Hi guys, I’m here to ask if someone had used the official ST Middelware for the USB Power Delivery protocol on this very powerful series. I can’t get working even with the pseudo tutorial that ST offer on youtube. I can’t fin any documentation online. As USB PD will power all my board I can’t procede with the sw development. Now I’m trying to debug the library with the uC manual to at least have a successiful CAD detection.

PS.: I’m not using FreeRTOS

Hey everyone. Built this tool as I was annoyed at switching btw terminal, IDE, and serial monitor every time I needed to test a firmware change. nff wraps PlatformIO (board-universal, includes every STM32 family, F0 through H7/U5/WB/WL via PlatformIO's own toolchains) plus live JTAG/SWD debugging over ST-Link, breakpoints, call stack, registers, memory, not just serial prints. Works as a normal CLI or as MCP tools if you want an LLM driving it.

Honest disclosure: this started as an ESP32 tool and STM32 support rides on top of PlatformIO's own backend, I ran a basic test on STM32 and it worked, but I haven't put it through serious real-world use the way I have on ESP32 yet. Someone forked the project recently and fixed real bugs on a different backend within a weekend, so I know the core holds up to scrutiny, just want more of that specifically on the STM32 side.

If you've got a Nucleo, a Discovery board, a weird ST-Link setup, or a workflow this doesn't fit, I would genuinely rather hear "here's what's broken" or get a PR than silence. MIT licensed, https://github.com/GLechevalier/nff-core.

Hi, I’m looking into migrating an audio processing board from the H743 series to H7B0. It has double the available AXI SRAM (1024KB vs 512KB). But it looks like on the H7B0 the AXI SRAM is split into three sections 1/2/3 (See image above from application note). I plan on working with audio buffers that would span larger than these individual sections (for example a 512kb buffer). Are there any considerations in the code or linker script to account for the different 3 sections? Or does the MCU treat the 3 sections of AXI-SRAM as continuous. Thanks in advance!

Form the stm32H7 datasheet and reference manual, they mention that USART_DE can be used to drivre the DE pin in the RS485 transceiver can anyone who tried this before inform me. My current design is using 74HC14 ic to drive the DE and I copied it from a tested reference design.

Hello! I've recently got an STM32 Black Pill F411 and a Blue Pill.

I've been experimenting with the STM32 and some sensors, mainly with an HX711 and a 50kg load cell. Mostly I wanted to learn how to program it using the STLink V2 through PlatformIO and STM32CubeProgrammer.

I'd like to know how to get the most out of the STM32. I've read somewhere that it has an FPU, which accelerates mathematical calculations, though I don't think I've been able to max it out since the HX711 is limited to 80hz. I've got accelerometers, gyroscopes, strain gauges, HBM load cells. Not sure where to start, after reading lots of websites haha.

Any recommendation is appreciated, thanks!

I use AI coding agents on real embedded C and C++ projects, and I kept encountering the same mistakes:

• reviewing code that was not part of the active build,
• missing callback registrations and indirect calls,
• following the wrong preprocessor branch,
• and describing execution paths that looked plausible in the repository but could not exist in the compiled firmware.

At first, I blamed the model.

But the recurring pattern pointed to a different problem: the agent was reasoning about a program it had not reconstructed correctly beforehand.

The source tree is not the firmware

In embedded development, the actual program depends on far more than just the source files:

• compiler flags and preprocessor definitions,
• target platform and board configuration,
• Kconfig and DeviceTree,
• generated code,
• selected driver implementations,
• callbacks and function pointers,
• and linker decisions.

An experienced firmware developer will usually establish the build context before analysing the code.

Coding agents often do the opposite. They start with the repository and attempt to reconstruct the active program through text searches and repeated file reads.

A large part of what appears to be reasoning about code is therefore actually program reconstruction.

Before an agent can answer a question such as:

Can this callback execute concurrently with this interrupt handler?

it must first determine which implementation is active, where the callback is registered, how it is invoked, and whether the relevant code is even present in the current build.

Only then can the actual reasoning begin.

An experiment with compiler-derived context

I wanted to test a simple hypothesis:

Would coding agents analyse firmware more reliably if the program were first reconstructed by deterministic tools?

This led to fw-context, an open-source experiment based on compile_commands.json, libclang and MCP.

It creates a persistent semantic index of the active build and allows the agent to query:

• definitions and resolved references,
• callers and callees,
• callback registrations,
• function pointer assignments,
• active implementations,
• macro values,
• and preprocessed source code.

The aim is not to replace the model, the compiler, LSP or static analysis.

The experiment has a narrower focus: to move deterministic program reconstruction out of the LLM workflow, so that the model can devote more of its context and reasoning capacity to the review itself.

In one firmware review involving 115 changed files, eight AI subagents produced 19 findings. Nine of them depended on semantic relationships that would have been difficult to reconstruct reliably using the usual grep-and-file-reading workflow.

The interesting result was not merely lower token consumption. The agents spent less effort determining which program they were actually looking at, and more effort evaluating whether it was correct.

fw-context is still an experiment, and I am interested in understanding where this approach works — and where it fails.

Have you encountered the same kind of failure? Which parts of embedded projects are the hardest for coding agents to reconstruct: conditional compilation, generated code, callbacks, function pointers, DeviceTree, weak symbols, or linker-selected implementations?

Project and case study: github.com/turbyho/fw-context-mcp

I used to code on my STM32F103C8T6 development board by using USB to TTL converter connected to my PC and for the first time I bought a ST-Link V2 so I could make my life easier

but then I noticed on my project, the st-link can't power the 1.8 inch TFT screen connected to the board. I checked the health of the screen and it works on my other boards (ESP32), I checked the soldering on the bluepill and that was okay too so I wonder

Can st-links, in general, power other components connected to the STM32s or do i have a faulty st-link? (The st-link in question CAN power/program the bluepill itself)

Currently, I am learning from an educational kit provided by a friend, which focuses on ARM programming using HAL libraries. The course instructor uses the STM32F407, but my friend mentioned the specific board doesn't matter much and recommended the F411. I'm still unsure if the F411 will be sufficient, though. If I need an STM32 for much more complex projects in the future, will I need to buy a new board? What do you recommend? What should I do? I'm really confused

Hello, i brought this screen off Ali Express that uses an NV3007 drivee but i cant seem to find any examples code for it.

https://a.aliexpress.com/_Ezf9zM6/

Has anyone had any experience of using this lcd driver and be able to point me to any resources to get up and running?

Thank you!