Hi, I know this might be a basic question, but I'm facing an issue while building my soldering station.

My setup consists of an STM32 Black Pill board connected to an SPI TFT display based on the ILI9341 controller.

The problem is that when I power the Black Pill through its USB port, the TFT initializes correctly and the UI is displayed every single time. However, when I power the board externally by supplying 5 V to the Black Pill's 5 V pin from a linear regulator, the display does not initialize. The TFT remains completely white with only the backlight turned on.

To verify that the STM32 is actually booting, I added a simple LED blink routine to the same firmware. Even when powered externally, the onboard LED blinks as expected, confirming that the MCU is running the code. The only issue is that the display never initializes and remains a blank white screen.

I'm trying to understand why the exact same firmware works perfectly when powered over USB but fails to initialize the ILI9341 when the board is powered through the external 5 V supply.

post regulator - 7805

preregualtor- a switching PSU.

essesntially the 5v regulator poweres the onboard LDO on the stm blackpill so I dont know where the problem arises from.

For microcontrollers constrained to 16 KB ROM and 2 KB RAM or less, I have always implemented firmware using a classic superloop (super main loop).

I’d like to switch to a simple task scheduler for better code organization and maintainability.
The Arduino TaskScheduler library looks promising, however I’m concerned that C++ support can be spotty or problematic on many bare-metal embedded platforms.

I’m curious to hear how the community handles this resource class of MCU:

1. Do you use simple cooperative schedulers written in pure C to avoid C++ overhead?

2. What lightweight, low-memory cooperative task schedulers would you recommend for this tight memory budget?

3. Any pitfalls to watch out for when porting Arduino-style task scheduling onto non-Arduino MCUs with limited Flash/RAM?

4. Do you generally avoid preemptive RTOS entirely at this memory level?

Thanks in advance for sharing your real-world workflows!

Hey everyone.

I browsed through the different STM32 boards and found the Blue Pill and Black Pill boards to be cheaper than the Nucleo board.

This would be my first time purchasing and using an STM32.

Which one should I buy?

Any suggestions would be helpful.

Thanks in advance.

I’m designing a multi-channel USB audio interface PCB as a learning project and I’d like some feedback before I start routing.
Current plan:
STM32F407
USB3300 (USB High-Speed ULPI PHY)
TDM/I²S audio
Initially 8 channels
Future expansion to 32 channels
Up to four PCM1681 DACs (I’ll probably only populate one for the first prototype)
I’m mainly looking for feedback on the architecture.
Am I missing any important components?
Is the STM32F407 + USB3300 + PCM1681 combination a reasonable approach?
Are there any common mistakes I should avoid before designing the PCB?
If you’ve built a similar project, I’d appreciate any advice.
I’m doing this mainly to learn, so any pointers are welcome.

Hey guys, I've finished my prototype of a project (thank you claude code) for a simple telemetry system, and now I am moving on to the PCB prototyping. I'm using a Nucleo board for F446RE for development, but I dont want my board to just be a nucleo carrier, and I'm gonna design it with the chip by itself and build the other things up.

With that, I'm still confused on all the thing's ill have to add to make that chip work alone, and specifically finding a datasheet which points me in the right direction .

I know I need a few things connected

1. Oscillator crystal
2. FRAM
3. Power filtering for microcontroller
4. STM32 Prog/Debug
5. Power regulators (i hvae a 12v DC input, so some bucks to step down to +5v and +3.3v respecitvely.

Is there anything else I need? And i can't find a datasheet showing PCB setup, but i found one like 1300 pages long explaining all the registers and stuff. The photo I have is something I got from copying a similar project which im kind of basing mine off of but i need to go past it.

I’m designing a multi-channel USB audio interface PCB as a learning project and I’d like some feedback before I start routing.
Current plan:
STM32F407
USB3300 (USB High-Speed ULPI PHY)
TDM/I²S audio
Initially 8 channels
Future expansion to 32 channels
Up to four PCM1681 DACs (I’ll probably only populate one for the first prototype)
I’m mainly looking for feedback on the architecture.
Am I missing any important components?
Is the STM32F407 + USB3300 + PCM1681 combination a reasonable approach?
Are there any common mistakes I should avoid before designing the PCB?
If you’ve built a similar project, I’d appreciate any advice.
I’m doing this mainly to learn, so any pointers are welcome.

I was curious about the content of an STM32F103RFT6 firmware binary. It uses CAN communication and it is being updated via CAN bootloader, thats how the firmware is being updated.

So I opened it in a hex editor and had a look. But that was not what I expected.

reverse engineering binary

Right in the beginning, there seems to be a 0x200 long header. The first four bytes are the size of the whole file, that was easy. Then four bytes containing the version, I guess, because I have another firmware which is a bit newer and they just differ by increasing 0x2c to 0x30.

Everying after that I don't understand right away, and the header after 0x050 is just zeros until it ends at 0x1FF.

At offset 0x200, the real firmware seems to start:

reverse engineering binary

At first glance, it looks as expected: First four bytes show the stack pointer address, and it's located in SRAM (starting 0x2000_0000).

But the following entries are supposed to be a vector table, and the addresses in there point to strings:

reverse engineering binary

I know that's thumb addressing, and all the LSB are set, but in the vicinity of these addresses there's just strings.

I don't understand that. And I don't know how to go on from here, if I don't know where the actual entry point is located.

For comparison, I opened an STM32 .elf for a project I wrote. In this .elf, the real code starts at offset 0x1000:

STM32.elf

Four bytes stack pointer, and then flash locations for the vector table. Going there and taking the file offset 0x1000 into account:

STM32.elf

I figured, fe e7 fe e7 must be pretty rare in the original firmware binary, so I searched for it:

reverse engineering binary

That does look pretty similar. But why is that, and where does this offset come from? And how should I continue?

One of the hardest parts of building my LoRa GPS tracker wasn't the RF design or even the firmware.

It was battery life.

When people ask how a tiny GPS tracker can last close to a year on a single charge, they usually expect some secret hardware trick.

There isn't one.

It's mostly about avoiding unnecessary work.

Here are a few of the biggest lessons I learned:

• Sleeping is everything. Every microamp matters when your goal is measured in months instead of days. Most of the time, the MCU is doing absolutely nothing—and that's exactly how it should be.

• GPS is expensive. Keeping the receiver running continuously drains power quickly. Deciding when to acquire a fix turned out to be just as important as getting the fix itself.

• Radio airtime matters. Transmitting every second sounds nice until you look at the battery graph. Simply increasing the reporting interval can extend runtime dramatically.

• Every wake-up has a cost. Reading sensors, checking timers, writing to flash, or transmitting "just in case" all add up over thousands of cycles.

• The battery wasn't the answer. It would have been easy to install a much larger battery, but I wanted the device to stay small enough to fit almost anywhere. That meant squeezing every bit of efficiency out of the hardware and firmware instead.

After dozens of firmware revisions and more current measurements than I'd like to admit, I finally reached a point where slow reporting intervals could achieve close to a year of operation on a tiny rechargeable battery.

I'm curious—what's the biggest battery optimization you've discovered in your own embedded projects? I'm always interested in learning new techniques.

https://preview.redd.it/ery0a2o4zcah1.jpg?width=4032&format=pjpg&auto=webp&s=b0484c51a2311de6522e8c62638ca3ec3912c053

I have a 6-legged robot (hexapod) project where I use an STM32F4 to communicate via PCA9685 to control the servos. When I transmit a set of angles to keep the robot stationary, it poses correctly right after booting up. However, an issue occurs when I try to manually force or shift the servos back and forth while the angles are being transmitted: the servos start spinning wildly for a moment before returning to their designated positions. I suspect this is due to interference caused by the deviation between the forced physical angle and the commanded angle from the PCA9685. Is there a way to resolve this issue? Could it perhaps be that the current I am supplying to the servos is insufficient?

Previously, when I purchased Espressif MCUs (e.g., esp32-c3, not board), it was easy to find and build minimal circuit - just few resistors.

Is it the same with pure stm32 chips, specifically stm32wb09ke? And how can I find these minimal schemes in docs?

I'm an ECE student and I've recently started learning STM32 (Blue Pill / STM32F103). My goal right now is not RTOS, Linux, AI, or advanced projects. I just want to learn how to properly understand a microcontroller and write code from the reference manual.

The problem I'm facing is that I still don't fully understand even the basics. I can't confidently blink an LED on my own yet without following a tutorial step-by-step. I get confused about things like enabling clocks, configuring GPIO registers, and writing the correct bit manipulations. I feel like I'm missing some very fundamental understanding, and I want to build that from the ground up instead of just copying code.

I don't want to become someone who only copies HAL examples. I want to understand:

• How experienced embedded engineers read reference manuals
• What information should become muscle memory vs what should be looked up
• How to navigate a datasheet/reference manual efficiently
• How to go from "I want to blink an LED" to finding the right registers and writing the code myself
• How to learn bare-metal programming the right way

Could you recommend:

• YouTube channels
• Blog series
• STM32 learning paths
• Exercises/projects that specifically teach reading documentation and writing code from it

If you were starting from scratch today and your goal was to become very comfortable with microcontroller architecture, registers, datasheets, and bare-metal programming, how would you do it?

I'd appreciate any roadmap or resources from people who have gone through this themselves.

About a year ago, I made a post (https://www.reddit.com/r/embedded/s/rk0xTafhjy) asking whether there was still a need for a practical guide to learning firmware engineering. The response was pretty clear — there’s still demand for it.

So I’ve decided to commit the next 3–6 months to writing one.

The challenge is that since I’ve been doing this for a while, it’s hard for me to step into the shoes of someone just starting out. I already know how to navigate datasheets, search for solutions, debug hardware, and piece things together. That makes it harder to identify where beginners actually struggle.

That’s where I need help.

I’m looking for a few learners who are willing to spend time over the next few months actively learning embedded firmware development. If that sounds like you, comment here or send me a DM.

What this guide will be about

This will be a practical, hands-on, build-first guide — not a theory-heavy one.

Instead of covering endless concepts upfront, we’ll pick small tasks/projects, build them, and document the process.

For example:

"I want to control an LED."

From there, we’ll work through:

• What do I need to understand about my microcontroller?
• Which parts of the datasheet matter?
• How do I find relevant examples or methods online?
• How do I implement it?
• How do I verify that it’s correct?

As the guide progresses, the tasks will naturally become more complex, introducing deeper concepts along the way.

How this will work

• I’ll first understand where you are in your learning journey and what you already know.
• I’ll give you practical tasks to solve.
• You’ll explore documentation, datasheets, and online resources to figure them out.
• I’ll guide you whenever you get stuck.
• Afterward, you’ll tell me how you approached the problem:
  • What was your first thought?
  • What did you read?
  • What confused you?
  • How did you solve it?
  • What did you learn?

Your feedback will directly shape how I write the tutorials.

What you’ll need

• Access to at least one microcontroller development board (AVR, Arduino, 8051, ESP32, STM32, etc.) — or be willing to buy one.
• Willingness to spend time learning and experimenting.
• Willingness to give honest feedback about your process.

What you need to know beforehand

Not much.

A basic understanding of C and some electronics knowledge will help, but you don’t need prior firmware experience.