cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F103CB not entering the bootloader...

PhilSter
Associate II

Hi,

I am making a custom PCB. I am able to reliably flash it with a ST-Link and a Segger programmer. I also have a custom program that I use to flash the MCU using the UART. It has worked for years with other ST chips and partially worked with the above mentioned chip in these situations:

1 - MCU is already flashed and the firmware executes a software reset command, after the external PC raises BOOT0. Works perfectly every time @115200

2 - MCU is already flashed and external PC raises BOOT0 and prompts user to press RESET button on PCB. Works perfectly every time @115200

3 - MCU is erased and external PC raises BOOT0 and prompts user to press RESET button on PCB. I tried it about 100 times with different baud rates and the bootloader only responded once...

I spent 2 days debugging this and I eventually figured out that this particular chip is very sensitive to the NRST rise time. My original PCB design had a 0.1uF cap and a 10K pullup. I removed the 10K pullup per the example given in your documentation and it still did not work. I eventually got the bootloader to start by using a 1uF cap and a 10K pullup. IMHO the NRST was rising too quickly (It was not a soldering problem or a bad cap because I checked the reset line with a digital oscilloscope).

I was able to correct the problem, but I am wondering where is the NRST rise time spec documented?

Thanks,

Phil

5 REPLIES 5

I don't think it's the NRST rise time as such. Does the reset button reset some other hardware on the board to? Does this chip have other interfaces used in bootloader (see AN2606) and if yes, can't there be accidental activity (noise) on the respective pins during bootloader entry?

JW

PhilSter
Associate II

I checked it with a digital oscilloscope, and there was no noise and the switch shorted nRST to 0V. Also the reset net is only connected to the cap, pullup, switch, and a male header for the programmer(not connected during testing) and is surrounded by a ground plane.

0.1uF worked once with about 100 attempts, but the 1.0 uF cap works perfectly every time. What is bizarre is that if the firmware was programmed first with my Jegermeister, the 0.1uF cap worked perfectly, but if the firmware was erased, then it did not work and I even attempted to connect with a bunch of baud rates (down to 1200 baud) just in case the internal oscillator was out of cal.

The only change the MCU saw would be a slower rising slope because the 1uF cap's RC time constant would be 10x bigger.

And have you checked the other possible bootloader interfaces?

Also, have you tried a power cycle before the attempt to enter the bootloader?

What is Jegermeister?

JW

PhilSter
Associate II

Yes, I tried power cycling it once, and my PCB was designed to use the USART1 which I believe is the only interface supported by the STM32F103. Jegermeister is my affectionate name for my favorite programmer, the Seger J-link and my favorite schnapps LoL

I fixed the problem by changing the cap, so I am GTG but I did want to document this bizarre behavior for others. Maybe my distributor (LCSC) snuck in a counterfit part, or maybe ST has QC issues, I don't know... For the latter, I am wondering if ST has a site where can check the chip's UID bytes to see if it is legit?

> Maybe my distributor (LCSC) snuck in a counterfit part

Oh, that 's quite likely in light of the latest development on the far-eastern 'F103 sources... sort of decreases the value of your report...

> For the latter, I am wondering if ST has a site where can check the chip's UID bytes to see if it is legit?

What would prevent the counterfeiters to use any UID taken from legit ST parts?

JW