How did I damage the STM32F030R8 with external power to DISCOVERY?

[spectator]

In a word: I seem to have damaged the flash on an STM32F0 Discovery board by attaching external power.

Details

I had peripherals attached to the STM32F030R8-Discovery board that required more than 100mA @ 3V available from the Discovery's on-board regulator. I attached a 3.3VDC supply to the 3V pin (pin 1) of the board and let it common ground with GND (pin2). 5V was still provided by USB.

Ever since then, I am unable to flash the STM32F0 . I've removed all my external logic. I was using the same studio and the Discovery's on-board STLINK ability, as always. My understanding of the Discovery is that diodes protect both the on-board 5V (diode drop from USB, so, more like 4.5V) and 3V supplies from external power. But I must have somehow overdriven the STM32.

I can still connect and interrogate the STM32F0. Reading flash shows a few non-FF bytes at 0x0800 0000 but then the rest of the device is blanked. I had attempted a bulk erase at one time and it must have partially completed. The loader etc. at 0x1FFF EC00 is not erased. The option bytes are all 0xFF'd - fortunately that's the default and flash is not write-protected..

I am replacing the Discovery but will need to repeat this. Any advice for how to avoid damaging a second Discovery?

The log of a download to flash from stutil that fails is as follows:

1. 2019-05-17T11:06:50 INFO src/common.c: Loading device parameters....
2. 2019-05-17T11:06:50 INFO src/common.c: Device connected is: F0 device, id 0x20006440
3. 2019-05-17T11:06:50 INFO src/common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
4. 2019-05-17T11:06:50 INFO src/gdbserver/gdb-server.c: Chip ID is 00000440, Core ID is 0bb11477.
5. 2019-05-17T11:06:50 INFO src/gdbserver/gdb-server.c: Listening at *:4500...
6. 2019-05-17T11:07:06 INFO src/gdbserver/gdb-server.c: Found 4 hw breakpoint registers
7. 2019-05-17T11:07:06 INFO src/gdbserver/gdb-server.c: GDB connected.
8. 2019-05-17T11:07:15 INFO src/common.c: Attempting to write 1024 (0x400) bytes to stm32 address: 134217728 (0x8000000)
9. Flash page at addr: 0x08000000 erased
10. 2019-05-17T11:07:15 INFO src/common.c: Finished erasing 1 pages of 1024 (0x400) bytes
11. 2019-05-17T11:07:15 INFO src/common.c: Starting Flash write for VL/F0/F3/F1_XL core id
12. 2019-05-17T11:07:15 INFO src/flash_loader.c: Successfully loaded flash loader in sram
13. 2019-05-17T11:07:18 ERROR src/flash_loader.c: flash loader run error
14. 2019-05-17T11:07:18 ERROR src/common.c: stlink_flash_loader_run(0x8000000) failed! == -1

[spectator]

Well, I had a USB serial translator chip attached to USART1 when this all started, and perhaps somehow it was preventing bootloader activation. No other idea.

But after I was having trouble flashing the STM32F0, my clumsy erases evidently did 0xFF-erase the option bytes. I suspect that changing nBOOT1 to 1 is preventing the serial bootloader on the STM32F030R8 from activating. Unless there is still some other way to revert the option nBOOT1 to 0, I am afraid I have bricked the STM32F0.

[Mon2]

Have not lived through your experience but...if you had voltages being applied onto the I/O pins of the CPU but the CPU was not being powered then it is possible that you faced a reverse voltage feed (bias) and caused these events. Summary, the CPU must be powered before you apply external voltages onto the I/O pins of the device. Ok to have the CPU powered up first but best if both powered up at the same time.

[spectator]

Thank you for your reply. At one point, I did put all the external components on their own supply/domain and gated that power domain with a GPIO-controlled nFET. I saw some back powering along the SPI channel for a moment (forgot a pull-down on the gate), and this would have been the problem you described. I will have to be more careful while prototyping this on the replacement Discovery.