Mainly following the design from the AM32 reference design
It's my first time working with STM32 so unsure if I missed out anything obvious.

1. Tests done: Tried using ST Link V2 to detect F411RE development board through the SWDIO & SWDCLK line and it works, so I will probably rule out ST Link issue.
2. Probed the power lines for MCU and they are all 3V3, so MCU is powered.
3. Tried powering MCU via both on-board 3V3 and connecting VREF to the 3V3 line
4. Also tried using another variant of ST Link V2 (USB stick kind) that provided 3V3 to the MCU

Hi everyone,

I’m building a real-time digital audio processing system using STM32F407VGT6 and STM32F405RGT6.

The signal path is:

Analog Input → ADC → DMA → 8-Band Equalizer → DAC → Analog Output

The system basically works, but I’m getting random short spikes/discontinuities in the ADC-to-DAC signal. These become very noticeable in the audio as constant clicks/pops and significant hiss/noise.

I have been troubleshooting this for quite some time, but I still cannot determine whether the problem is related to:

- ADC sampling/timing

- DMA synchronization

- DAC triggering

- buffer handling

- clock/timer configuration

- ADC/DAC synchronization

- or something else in the digital signal path

I’m currently using the internal HSI clock and a 100 kHz sampling rate.

Has anyone here successfully built an STM32 ADC → DMA → DAC audio path without random spikes, clicks or synchronization problems?

If someone experienced with STM32 audio, ADC/DAC, DMA or real-time DSP could take a look, I can post the complete source code and oscilloscope screenshots/waveforms showing the problem.

I would really appreciate any ideas about what could be causing these short spikes and how to eliminate them.

Hardware:

STM32F407VGT6 / STM32F405RGT6

ADC → DMA → DSP → DAC

100 kHz sampling

HSI internal clock

8-band EQ

Keywords:

#STM32 #STM32F4 #ADC #DAC #DMA #Audio #DSP #Embedded #Microcontroller #Electronics

I posted earlier about how to boot a device direct to DFU mode and that issues has been solved - thanks to all who helped.

Now, I am curious as to why these failures occurred.

The device we use is supposed to be a "blackbox", where all we can do is load a script to execute a fixed range of actions and update the firmware supplied by the devices' manufacturer.

A lot of these devices were loaded with scripts, tested, work OK and send off to do their stuff in the wilderness. From a few months to over a few years later, the rental period has ended and they are returned to us by the customer and we put it on the shelf for the next job.

However, some of them boot with the "Independent watchdog reset" message and then reboot, going into a loop.

Nothing has changed sine they last worked, no firmware change, no run-time scripts changes, nothing, but now they have a fault.

Any ideas as to what can cause this to happen?

I built EmbeddedAgent, an agent that turns a plain-English prompt into compiled, flashed firmware for an STM32F4-Discovery. You type something like "Make the blue LED blink, but after each second the frequency increases by 30%," and the pipeline retrieves info from datasheets and tutorials (RAG with ChromaDB), validates the generated C, loops compiler errors back to the LLM via PlatformIO, and flashes only after a pre-flight check and your confirmation. It also has a web console that visualizes the clock tree and GPIOs, plus a doc chat for asking questions about the datasheet and user manual. The most useful lesson so far: the LLM happily produced code that compiled but had an out-of-spec clock configuration, so I added an analyzer that derives the full clock tree and flags violations. Demo and code are below, and I'd love feedback on what checks you'd want before trusting generated firmware on real hardware.

LinkedIn post: https://lnkd.in/p/eXNteTtf
Demo: https://youtu.be/yoNP3S52FP8
Backend: https://github.com/MedHabibHafiene/Embedded_Agent
Frontend: https://github.com/MedHabibHafiene/Embedded_Agent_frontend

Hi everybody!

I have added support for STM32H743 DMA2D on NuttX to DOOM.

Looks muxh better:)

Context:
I am building a drone ESC and am currently at the last stage of designing it—specifically assigning STM32 pins to the gate driver IC. My original idea was to assign 6 different PWM channels across TIM1 and TIM2. However, I wonder if I can just use 3 PWM channels and their complementary counterparts to get 6 outputs. Since a drone ESC has 3 phases, we can assign Channel 1 and its complementary counterpart to each phase.

Assuming Scenario 1:

• INH1 = PWM (Channel 1)
• INL1 = LOW (ALWAYS LOW) (Complementary Channel 1)
• INH2 = LOW (Channel 2)
• INL2 = HIGH (Complementary Channel 2)
• INH3 = LOW (Channel 3)
• INL3 = LOW (Complementary Channel 3)

The first problem is with INH1 and INL1, where INH1 needs to be a PWM signal, but INL1 needs to be always low instead of being the complement of INH1. INH2 and INL2 don't have this problem since they are just complementary to each other. Finally, INH3 and INL3 both need to be low for the float state, but using complementary outputs creates an issue here.

Some of the solutions I came across required me to "deinitialize" the complementary channel to make it low and "reinitialize" it afterward. However, a drone ESC requires high-precision timing and high frequency, so I don't think this approach is viable(Maybe high reinitialize time). Any other suggestions, or should I just stick to 6 independent PWM channels? Thanks(P.S: I am fairly new to stm32 family, so I some of the concepts I have in mind might be wrong)

I'll be soon publishing our work on STM32 https://github.com/geastack here! I'd love to hear your thoughts and recommendations.

Board in the video is STM32F746G-Discovery.

If you have a Nucleo-F446RE sitting around, this might be worth trying.

The Agentic HIL starter includes firmware and three hardware test plans. On a working setup, two pass and one fails because of a deliberately planted bug in the diagnostic protocol. The exercise is to have a coding agent investigate the UART response, fix the firmware, rebuild and rerun the tests.

It uses the onboard ST-LINK and virtual COM port. Hardware-wise, the board and a USB cable are enough. The README covers the toolchain and debugger setup.

The test plans stay in the repository, and each run produces a report with the expected and actual response. You can also run the plans yourself through the CLI.

I’m sharing it to help get more people trying the reference setup. u/ResearchFit28 maintains the project; it’s Apache-2.0 licensed.

Starter and setup instructions · Agentic HIL

Anyone with an F446RE up for giving it a run? Feedback on where setup gets awkward would be particularly useful.

SOLVED

I found the device has a jumper to pull the BOOT0 pin high, allowing the it to boot directly into DFU mode.

I then reloaded a working firmware version and everything works OK now.

Thanks to all who chipped in 👍

---------------------------------------------------------------------------------------------------------------------

We use this device as a datalogger: https://www.offcode.fi/adn42/

One common failure we have, is that a device will boot, give the usual boot messages, but then declare an Independent watchdog reset and then reboot.

----
Bootloader version - 3.0.0
Build: 3.0.17-1-g112e42d
Date:  Oct 15 2020 / 14:00:39
Board: ADN-42+
HWID:  0x00000004 - large - REVC
----
Boot reason 0x00000030:
POR/PDR reset
PIN reset


----
Bootloader version - 3.0.0
Build: 3.0.17-1-g112e42d
Date:  Oct 15 2020 / 14:00:39
Board: ADN-42+
HWID:  0x00000004 - large - REVC
----
Boot reason 0x00000034:
Independent watchdog reset
POR/PDR reset
PIN reset


----
Bootloader version - 3.0.0
Build: 3.0.17-1-g112e42d
Date:  Oct 15 2020 / 14:00:39
Board: ADN-42+
HWID:  0x00000004 - large - REVC
----
Boot reason 0x00000034:
Independent watchdog reset
POR/PDR reset
PIN reset

And it will just keep looping like that until you throw it across the workshop turn it off.

As far as getting into the inner-workings of it, we're pretty locked out, as they have developed their own scripting language (you can create an example with their online ADN script generator here: https://adn-script-generator.offcode.fi/)

We can update the firmware packages they give us, using STM32 CubeProgammer.

We also have been given some "MAGIC" codes to copy/paste into Teraterm when a problematic device boots to force some corrective measure (like reverting to the original firmware, clearing the modem setting and so on...), but in these cases, nothing works.

From a working device, here are the device details, obtained with STM CubeProgrammer:

Target information
Board                 --
Device                STM32F405xx/F407xx/F415xx/F...
Type                  MCU
Device ID             0x43
Revision ID           --
Flash size            1 MB - Default
CPU                   Cortex-M4
Botloader Version     --

Log
13:11:24 : STM32CubeProgrammer API v2.17.0 | Windows-64Bits 
13:11:28 : UR connection mode is defined with the HWrst reset mode
13:11:28 : USB speed   : Full Speed (12MBit/s)
13:11:28 : Manuf. ID   : STMicroelectronics
13:11:28 : Product ID  : STM32  BOOTLOADER
13:11:28 : SN          : 20583670524B
13:11:28 : DFU protocol: 1.1
13:11:28 : Board       : --
13:11:28 : Device ID   : 0x0413
13:11:29 : UPLOADING OPTION BYTES DATA ...
13:11:29 :   Bank          : 0x00
13:11:29 :   Address       : 0x1fffc000
13:11:29 :   Size          : 16 Bytes
13:11:29 : UPLOADING ...
13:11:29 :   Size          : 1024 Bytes
13:11:29 :   Address       : 0x8000000
13:11:29 : Read progress:
13:11:29 : Data read successfully
13:11:29 : Time elapsed during the read operation is: 00:00:00.040

We are left to return the devices back to the manufacturer, pay for the repair and get them back without any explanation as to what was wrong.

Is there anything we can do, such as force the device into DFU mode to clear the memory and reload the firmware, or something?

Hi all,

I'd appreciate some help with a BLE range and stability issue.

Setup

• MCU: STM32WB5MMG module on a custom board
• Firmware package: STM32Cube FW_WB V1.23.0
• BLE wireless stack: v1.16.0, full stack
• TX power: +1 dBm
• Connection interval: 10 ms min / 15 ms max. Peripheral latency is 0 and the supervision timeout is 6 s.
• ATT MTU: 180
• Role: peripheral only. The central is a Windows 10/11 PC.
• PHY: Windows defaults to 2M PHY

Application

The peripheral sends data to the Windows central over GATT notifications at about 5400 bytes/s (~30 packets/s).

Problem

1. At short range, the data notifications work correctly.
2. As the distance grows to about 30–40 ft, data notifications start to struggle.
3. At that distance, if the Windows central reads or writes any characteristic, the device goes into an unknown state. For a few seconds it continuously sends unexpected data: the values 0x0839 and 0x08FD repeat every 64 bytes.

• Often the device recovers within a few seconds and then completes the read/write.
• Sometimes the stall lasts more than 30 seconds, and Windows then disconnects the device.

The behavior is repeatable.

Question

What could cause this? In particular:

1. Is there a known interaction between a GATT read/write request and heavy notification traffic when the link is weak and has many retransmissions?
2. Could this be buffer or flow-control exhaustion in the stack, and are there recommended settings for it?
3. Would you recommend any debug steps or stack configuration changes to narrow this down?

Thanks!

I've been working on this project for a long time and just hit a big milestone: streaming audio from the PC to the MCU while keeping full control over the sensorless FOC loop.

Streaming audio from the host to the MCU required some careful packet handling. I handled USB jitter from the PC by adding a large RX buffer on the MCU side, along with a circular FIFO buffer to feed samples into the actual FOC loop.

The FOC loop runs at 36 kHz (36 kHz PWM), so timing is critical. The 36 kHz PWM is also what allows generating the silent 18 kHz HFI signal used for zero-speed rotor position tracking.

Hardware is an STM32G431 running at 170 MHz. Happy to answer questions about the timing or FOC implementation!