STM32F1 bootloader issue

[zexx86]

Posted on February 13, 2015 at 14:23

Hello,

in last batch from our supplier we have a problem with entering internal bootloader via USART1.Something probably changed in the processors, because previously, there was absolutely no problem. Now we have lot of pieces from same batch, that are behaving strange.We have found, that processor react correctly to BOOT0 pin, so it switching to bootloader, but it does not communicate via USART1 at all.Strange is, that it works for some chips in 1/30 tries. Our PCB is very same for all the time, only part that can be problematic is most probably processor.We have some pcs that there is corrupted FLASH memory too to the extent, that some part is working correctly, some pages can't save the data at all.I am sure all is correctly soldered, we have changed processors to new, but they are from same batch so there is potentionally same problem.If we enter finally the bootloader, then all is OK. Our firmware is working correctly.Can you tell me, where can be a problem?Bootloader is probably started, but it does not work (at least with USART).We can see it clearly on the LED, even if there is our firmware and we want to activate internal bootloader, then LED is turned OFF which is correct, but bootloader does not respond.Please help, as we are out of ideas.Chip is STM32F103RBT6.Thanks

[Tesla DeLorean]

Posted on February 13, 2015 at 15:17

Chip is STM32F103RBT6.

And the full markings on the bad batch vs the good batches are what? Where did you source the bad batch? Have you looked at the ROM, the code and version of the System Loader? Have you reviewed the serial connectivity with different serial ports and interface chips? Have you downloaded any test code via SWD/JTAG and programmed/tested the flash via that route? Have you tested serial connectivity independently of the system loader?

[zexx86]

Posted on February 13, 2015 at 16:03

In the latest batch, we have good and bad units.

Some of these was possible to flash via bootloader after first try (powerup with BOOT0).Some was possible to flash with 10 - 30 tries. Some was not possible to flash at all.Older chips was possible to flash always immediately.It is not a problem in PCB, capacitors, etc as we have checked the same problem with more circuits independently. Chips from the last batch are from Farnell GB.Unfortunately we can't check more USART ports nor JTAG or other ports. PCBs are embedded devices with very limited access to processor pins.Bootloader Version      : 0x22It is same version as in previous batch that works perfectly.If chip is finally flashed with our firmware, then serial connectivity is working fine. 115200 data streams are no problem.It is very strange that bootloader is activated but is unable to respond to any command.

[Tesla DeLorean]

Posted on February 13, 2015 at 17:11

The auto-bauding of the System Loader is a one shot deal, if it doesn't time the initial 0x7F correctly in 8E1 format, everything else is going to be broken. The System Loader also uses the HSI clock.

I would suggest you output the clock via MCO (PA8) and inspect it, but I fear you've built an untestable product. If there is any timer pin, try one of those, or inspect the bit timings on the USART.

[zexx86]

Posted on February 13, 2015 at 21:02

Thank you very much.

Interestingly it seems there could be a problem in the auto-bauding.Right now, the one that was faulty works now.I have configured 1200 baud rate and sent to the unit after 10 seconds.Then it is recognized correctly! With baudrate 9600 and higher I am unable to do this.I have to wait few seconds until it is able to detect even 1200 baud rate.So now I am sure something is wrong with these chips. HSI is probably out of tolerance.I will try to do this in the same way with rest of these.