STM32F205 has bad bootloader from factory?

[cmeyers]

Posted on May 11, 2015 at 20:16

Hello,

We have been using STM32F205VB6 in production for several years. In a recent batch we purchased a high percentage of processors the boot loader doesn't work over USB properly. We have a jumper tied to BOOT0 pin and I have verified that the voltage is correct when the device is powered up or reset, however the device never shows up over USB.When I use JTAG to examine the state of the processor just after reset I see the follow address on the program counter: Good Board: pc=0x0B92349EBad Board:   pc=0x1FFF3DE4You can see that a bad processor is not in valid memory space.Any ideas on how I can further interrogate the boot loader and figure out what is the problem. #bootloader #stm32f2

[Tesla DeLorean]

Posted on May 11, 2015 at 20:42

Copy out the ROM to a .HEX file and post it

Review the version# of the Boot Loader, and the date code(s) from the afflicted parts.

[cmeyers]

Posted on May 11, 2015 at 23:38According to the Bootloader ID they are equivalent.

[cmeyers]

Posted on May 12, 2015 at 00:05Also the System memory contents are the same.Must be a hardware thing. Could be a problem with the USB but I can load the program through the JTAG and the board functions normally but I can no longer load over USB from the factory bootloader.

[Tesla DeLorean]

Posted on May 12, 2015 at 01:08

How do you have BOOT1 (PB2) connected? What frequency crystal do you have, and how close to tolerance is it, and compared to the units that function.

[cmeyers]

Posted on May 12, 2015 at 03:09BOOT1 pin is left open/floating. I pulled the pin low with a wire and it did not make a difference.Here is the main problem, using openocd and JTAG I reset and halt the core and look at the PC value. The first one is normal mode executing from FLASH, the second result is when I pull-up BOOT0. That second PC location is just random junk. I am trying to force the core to change the PC but I get a fault.> reset haltJTAG tap: stm32f2x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)JTAG tap: stm32f2x.bs tap/device found: 0x06411041 (mfg: 0x020, part: 0x6411, ver: 0x0)target state: haltedtarget halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x080001d0 msp: 0x20010000> reset haltJTAG tap: stm32f2x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)JTAG tap: stm32f2x.bs tap/device found: 0x06411041 (mfg: 0x020, part: 0x6411, ver: 0x0)target state: haltedtarget halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x58282054 msp: 0x46445450

[cmeyers]

Posted on May 12, 2015 at 03:17

Sorry, I forgot to answer your second question. The crystal is not used, the internal clock is used. The external crystal is never started when in the bootloader mode. This is one of the first things I checked.

[waclawek.jan]

Posted on May 12, 2015 at 08:54

You might want to tell us about your hardware, namely grounding, VDD/VDDA(!), RST connections.

JW

[cmeyers]

Posted on July 02, 2015 at 00:06

We made some progress on this problem. There is some behavior change related to the Boot0 and Boot1 pins when the processor is held in reset.

Normally the processor does not care about the Boot1 pin when Boot0 is pulled low. This is normal bootup mode. However when 0 is pulled hi to enter DFU mode 1 is also sampled to determine ROM vs SRAM.We don't use the Boot1 pin and have always left it open. We have now seen that on older revisions of the silicon this pin naturally was low when the device is held in reset. On never silicon it is floating high.If we use a reset controller that holds the device in reset when the board comes up, about 200ms, the Boot1 pin has enough time to float high and screw up the boot process.If we remove the external reset controller then the processor can start up faster and samples the pin while it is still low.