STM32F103 Custom PCB - Weird Startup Issues

[Saboteur94]

Greetings EEVBlog members!

I have just made a small homemade PCB for the STM32F103.I have managed to program it via UART using STM32 Flash Loader (Simple LED blink on PB5).I used a USB-to-Serial converter to program with BOOT0=1 and BOOT1=0.However,when I reset the STM32 (With BOOT0=0 and BOOT1=0) the blink program doesnt start unless I touch the chip with my index finger at the corner where PINS 1-5 are located (VBAT,PC13,PC14,PC15).This is a rather weird Issue.My schematic and PCB layout is attached.Whats more weird is that when I try to power the device from a battery or lab PSU it doesnt blink the LED at all even after I do the touch with my index finger.The reference for my design was the "Blue Pill" board.

I'm new to the blog.Please tell me if I have provided insufficient info.

[Siwastaja]

The layout is horrible enough that it's the probable cause.

Use a ground plane and direct vias to it. This means every CPU GND pin has a via to the GND plane right next to it, and the 100n caps will have those vias as well.

[oPossum]

Check the oscillator configuration.

[hans]

In schematic, you've drawn OSC_IN and OSC_OUT, but there is no actual crystal.

The STM32 boots with internal oscillator. Your firmware may start to then switch over to an external oscillator and seemingly hang.

If the board is grounded and you touch it with your finger, you may inadvertently create a really crappy clock signal from your body acting as an antenna, for the board to seemingly work for a short while.

[Siwastaja]

So we would like to see the code, as well.

It was my assumption that a "simple LED blinker" would not do any clock configuration, but maybe this is a borrowed code somewhere?

[free_electron]

vbat needs to be connected to keep the ram alive....

[Saboteur94]

There are ground vias and a ground plane.The green you see on the board is the "ground plane".There are vias to the ground plane.The small circles you see with "GND" on it are vias.

[criznach]

I was going to say all of those VSS pins need to be connected together to GND but then I saw your reply that you have a GND plane.

And as others have said, make sure your code isn't switching to an external oscillator - because you don't have one.  The Blue Pill does have an 8mhz ext crystal, so if you're using that firmware it probably won't work.

[Saboteur94]

Thank you,this makes perfect sense!!!!.I will check on this asap.

[Saboteur94]

Its quite clear from the PCB layout pic provided that a ground plane is present as well as vias to the ground plane.

[criznach]

Its quite clear from the PCB layout pic provided that a ground plane is present as well as vias to the ground plane.

Apparently not.   

[Siwastaja]

Yes I see the plane, but you need to think how you connect to it.

Vias are too far from the ground pads to be of much use.

This may or may not be the source of these particular issues, but I do guarantee you from experience that this layout is broken. But, the good news: it is easy to fix. Just add vias near the ground pins, move the bypass caps closer to the power pins (moving to a smaller capacitor package is highly recommend, even though not mandatory - even if you didn't like soldering 0402, just a few capacitors is not a daunting task to do!), and add vias there as well. If you already have the PCBs made, this can be fixed by drilling a few holes and soldering some wire.

Fixing the obvious source of problems first removes one very probable source of really mysterious problems later on. This particular issue either gets fixed, or does not. In the latter case, you can go on with other possible causes...

One simple way to do power distribution in 2 layers is to dedicate the space under the chip for Vdd. This way, the backside is free for complete ground layer, as you have now, and you don't need to jump between the layers as much. An example is attached where I did this. Well it's a 4-layer so the bottom is noncontinous as it doesn't matter here because of the other layers, but you can see you could route the "power in" between the corner pins on the top layer for a similar 2-layer design.

It's not super critical, but when I was a beginner, it took me at least 5 years to admit that yes, the layout really might have been behind my random resets and reliability issues, since the problems just vanished once I started to listen to others and stop being stubborn  with "it can't matter that much" attitude .

[mbless]

vbat needs to be connected to keep the ram alive....

I think vbat is only for RTC, RTC crystal, and backup registers

[Siwastaja]

vbat needs to be connected to keep the ram alive....

I think vbat is only for RTC, RTC crystal, and backup registers

This is the absolute classic source of confusion on the STM32 family. If you read the datasheet carefully, they imply everywhere that the Vbat must contain valid voltage between 1.8 and 3.6V, hence suggesting it cannot be left unconnected.

OTOH, they write about the internal power switch: "The RTC and the backup registers are supplied through a switch that takes power either on VDD supply when present or through the VBAT pin.", implying the complete Vbat island would get powered up properly from Vdd though the internal switch, but they don't say this exactly.

I forgot to connect Vbat at least in one design with no issues whatsoever. Others have reported otherwise. I guess it depends device-by-device.

If you want to play it safe and absolutely follow the datasheet, you power this pin; leaving it unconnected is kinda working outside the datasheet specifications. OTOH, running these devices at all is playing outside the datasheet specifications all the time, so YMMV.

Still, I suspect (guess?) this is not the source of the OP's problems.

[janoc]

The 100k pull-up resistors on the BOOT pins don't look right. 10k would be more like it. What may be happening is that once you programmed it, the very weak pull-up is not enough and the MCU starts in the bootloader instead of your code.

The fact that it works when you touch it with your finger pretty much points to an issue like that.

I would also remove the 1uF cap from the reset switch - that's way too large and could cause undefined state on the reset pin while it slowly charges up.

[mbless]

The 100k pull-up resistors on the BOOT pins don't look right. 10k would be more like it. What may be happening is that once you programmed it, the very weak pull-up is not enough and the MCU starts in the bootloader instead of your code.

I wouldn't think that is the issue since the pull-up is used to put it into the bootloader not flash. When Boot0 is connected to ground it'll boot from flash.

I would also remove the 1uF cap from the reset switch - that's way too large and could cause undefined state on the reset pin while it slowly charges up.

Quite possibly. The datasheets always demonstrate 0.1uF (possibly because jellybean parts). BTW OP, there is an internal pull-up resistor on RST. I've never used an external resistor.

[Saboteur94]

Yes I see the plane, but you need to think how you connect to it.

Vias are too far from the ground pads to be of much use.

This may or may not be the source of these particular issues, but I do guarantee you from experience that this layout is broken. But, the good news: it is easy to fix. Just add vias near the ground pins, move the bypass caps closer to the power pins (moving to a smaller capacitor package is highly recommend, even though not mandatory - even if you didn't like soldering 0402, just a few capacitors is not a daunting task to do!), and add vias there as well. If you already have the PCBs made, this can be fixed by drilling a few holes and soldering some wire.

Fixing the obvious source of problems first removes one very probable source of really mysterious problems later on. This particular issue either gets fixed, or does not. In the latter case, you can go on with other possible causes...

One simple way to do power distribution in 2 layers is to dedicate the space under the chip for Vdd. This way, the backside is free for complete ground layer, as you have now, and you don't need to jump between the layers as much. An example is attached where I did this. Well it's a 4-layer so the bottom is noncontinous as it doesn't matter here because of the other layers, but you can see you could route the "power in" between the corner pins on the top layer for a similar 2-layer design.

It's not super critical, but when I was a beginner, it took me at least 5 years to admit that yes, the layout really might have been behind my random resets and reliability issues, since the problems just vanished once I started to listen to others and stop being stubborn  with "it can't matter that much" attitude .

Thanks for the sound advice.I will design a new board tomorrow taking your tips into consideration

[janoc]

The 100k pull-up resistors on the BOOT pins don't look right. 10k would be more like it. What may be happening is that once you programmed it, the very weak pull-up is not enough and the MCU starts in the bootloader instead of your code.

I wouldn't think that is the issue since the pull-up is used to put it into the bootloader not flash. When Boot0 is connected to ground it'll boot from flash.

His schematic shows a chip that has both BOOT0 and BOOT1. If the DIP switch on BOOT0 is 1 (i.e. open), then BOOT1 decides whether it boots into boot loader or SRAM. All that it needs for a problem is a dicky contact on the BOOT0 DIP switch.

I wouldn't use a dual DIP switch for something like this but pull BOOT1 permanently to ground (that chip is unlikely to be used to boot from RAM as it doesn't have much of it - if you do need it, put a jumper there) and put a jumper on BOOT0. And also change the resistor to a pull-down, not pull-up. Then the jumper would connect the pin to Vcc when installed. Like that  the default in the case of a bad contact isn't the boot loader but flash.

I would also remove the 1uF cap from the reset switch - that's way too large and could cause undefined state on the reset pin while it slowly charges up.

Quite possibly. The datasheets always demonstrate 0.1uF (possibly because jellybean parts). BTW OP, there is an internal pull-up resistor on RST. I've never used an external resistor.

100n is used for both debouncing the switch and to ensure that the chip is in reset long enough for the Vcc to stabilize, together with that pull-up. The internal pull-up is likely too weak/has ill defined value so the cap would take a long/not well defined time to charge through it.

However, both are not needed as much these days as these modern MCU have brown-out detectors and generate their own reset pulses on power up. It still won't harm anything to include it, though. The ST Nucleo and Discovery boards have them.

[mbless]

The 100k pull-up resistors on the BOOT pins don't look right. 10k would be more like it. What may be happening is that once you programmed it, the very weak pull-up is not enough and the MCU starts in the bootloader instead of your code.

I wouldn't think that is the issue since the pull-up is used to put it into the bootloader not flash. When Boot0 is connected to ground it'll boot from flash.

His schematic shows a chip that has both BOOT0 and BOOT1. If the DIP switch on BOOT0 is 1 (i.e. open), then BOOT1 decides whether it boots into boot loader or SRAM. All that it needs for a problem is a dicky contact on the BOOT0 DIP switch.

Which is a problem with the switch, not the pull-up resistance as you originally claimed. Since OP wants Boot0 low to boot from flash, a higher pull-up resistance would indeed be better, not worse.

[andyturk]

[...] layout really might have been behind my random resets and reliability issues, [...]

What kind of random resets and reliability issues did you have? I've done all sorts of dumb stuff to STM32 parts and they still seem to run (usually).

[janoc]

Which is a problem with the switch, not the pull-up resistance as you originally claimed. Since OP wants Boot0 low to boot from flash, a higher pull-up resistance would indeed be better, not worse.

When I wrote the original reply I didn't check the table in the datasheet yet.

Regardless of that, I still think the 100k pull-up resistors are wrong because then the circuit is going to be susceptible to random noise getting in the trace (and given the PCB layout, no surprise). Which could have all sorts of weird effects if it happens during the time when the MCU samples the state of these pins on boot.

He should redesign it as I wrote in the previous reply - change BOOT0 to pull down, use 10k resistors and get rid of the DIP switches which are not designed to be constantly changed back and forth.

[Siwastaja]

[...] layout really might have been behind my random resets and reliability issues, [...]

What kind of random resets and reliability issues did you have? I've done all sorts of dumb stuff to STM32 parts and they still seem to run (usually).

I was talking about issues on AVR. STM32 didn't exist back then when I was having layout issues. This is between about 1999-2005. In about 2005, I started taking electronics more seriously again...

Random resets, well, are random resets. Sometimes right at the startup, sometimes related to driving IO, sometimes just randomly.

AVR, on the other hand, had a classically broken-by-design reset circuitry for a long time, which was fixed on the later revisions. Might be one of the causes. It required both a carefully sized pullup resistor, and a small cap to perform reliably. Which I probably didn't use.

Never had any such reliability issues on STM32. Maybe it's more robust against poor layout; or it could be worse. Hard to verify. With lower Vcc (i.e. smaller noise margin), higher speed and higher dynamic current, I'd expect it's more prone to layout issues. Especially the bigger packages which run the core from 1.2V.

On STM32, I have never tied NRST to anything. I simply haven't found any use. If I want to do a harder reset than the software can perform, then I probably want to do a full power cycle anyway - just to be sure, and to properly reset all external devices as well.