cancel
Showing results for 
Search instead for 
Did you mean: 

Standalone MCU Application - Unable to Flash F103

gatmt
Associate II

Hey, I am currently trying to get my own hardware to run on STM32 Microcontrollers. In this case, I am using a F103RET6, LQFP64 package. It is being used with very improvised hardware, as a proof of concept only. The layout looks like so, made in Kicad. Please be kind, it's my first rodeo. I am aware of the lacking of decoupling, filtering etc - as said, it's a prototype, I wanted to keep it as simple as possible.

gatmt_0-1693909074563.png

I am giving the circuit 9V on the left two solder pads, that are then fed into a 3.3V regulator (500mA max). It works fine up to here.

Now there are two goals: I want to have the LED (above the 220Ohms Resistor) blink so I know flashing software (a two line program that toggles PA9) worked, and ultimately test the second circuit, which is a MOSFET driving a load. At this moment, there i no such said load soldered in yet. The planned-for oscillator is currently not in use, I want to try it first with the internal resonator as to not overcomplicate things. For a better view of pinouts and the configurations:

gatmt_1-1693909456365.png

gatmt_2-1693909488186.png

gatmt_3-1693909557441.png

gatmt_4-1693909605533.png

 

 

 

 

 

gatmt_5-1693909666922.png

 

But I had two phenomena that I don't really know how to handle:

1) Between the lower right VDD and VSS pins, I had a little smoke develop when I first plugged the battery in - removing the chip later revealed a brown (probably burnt) area between both pins on the (self assembled) PCB. The reason I removed the first chip was, because after powering the board again today, (I kid you not) a little smoke turned into a very tiny "flame". I unplugged it, removed the chip, checked - discovered said burnt area, cleaned it to remove possible shorts (checking with a multimeter revealed NO short, 32kOhm when new chip soldered on and unpowered. I personally think it was some dirt trapped in leftover flux creating the connection, although, I mean, it's still only 3.3V...) and switched chips against a new one - because the whole right bank of pins had (when powered) 0.001V, while the other banks were all between 1.5 and 0.1 volts. So I assumed something burnt through with the old one, but I have no real explanation as to why. I double, if not triple checked my pinouts, power lines and soldering, and now things seem fine with the new chip after a short period of testing. I think it could have been a connection between the two pads, not directly connected to the chip itself.

gatmt_6-1693911004724.png

I figured I could leave boot tied to GND since I am using NRST to flash it, not yet the reset button.

-> Does anyone have an idea what I could have done wrong? Is it my wiring, my layout or something else?

 

2) Flashing. So I assumed it should work now, at least seeing things from an electronic standpoint.

I am using the ST-Link, cut away from a Nucleo-F446RET6 board, powered via USB from the PC. Using jumper cables, I can successfully write new programs onto the F4 belonging to the Nucleo, which is powered externally with 3.3V (since VIN somehow doesnt work with 9V, but thats another story). The four main traces I used are GND, SWDIO, SWDCLK and NRST. And as said, that works with the leftover Nucleo.

So I plugged the jumper wires into the according headers on my own board, powered that first and connected the ST-Link to my laptop via USB afterwards. First problem: It opened the media explorer, containing a file called "FAIL", stating: The interface firmware FAILED to reset/halt the target MCU

Aware of this, I tried flashing my "blink"-program anyways. As expected, it didn't work. It looks as if the ST-LINK doesnt even recognize ANY target parameter. I already updated the ST-Link to its latest available software version.

gatmt_7-1693911997386.png

Console said:

gatmt_8-1693912022900.png

And just to be complete:

while (1)
{
HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_9);
HAL_Delay(200);

/* USER CODE END WHILE */

/* USER CODE BEGIN 3 */
}

Debug Settings:

gatmt_9-1693912645328.png

 

I also tried all possible "Hardware reset/Software system reset/connect under reset" configurations, yet i didn't make progress. To sum it up, I dont know nearly enough to find out what's the problem here. Also, soldering this chip was as done as careful as possible, with 280°C for no longer than 10 seconds.

-> What could be the reason for this behavior? Why can I flash the Nucleo-F4, but not this one? Is it a configuration error, a hardware/layout mistake or something completely different?

Any help is greatly appreciated!!

 

 

 

11 REPLIES 11
LCE
Principal

Blinking an LED would probably work with flying wires...

And as Piranha said, on a 2-layer board trace impedance is too high anyway.

Anyway, I would on the bottom side at least try to make an almost unbroken GND plane, so route as many tracks as possible on top.

Then I would also place a GND fill on top (for outer layers and hand soldering I recommend 0.4mm to 0.5mm distance from the GND pour to everything else), and place lots of GND vias.

gatmt
Associate II

Hey! Just catching up on this thread: The boards were manufactured and assembled, and are now working flawlessly.

Thanks for all the advice.

 

May this serve as orientation for future people trying to learn pcb design.