microcontroller - Debugging an MCU short circuit

I have a board with an STM32F103VGT6 MCU. Yesterday, the MCU worked fine, I had just gotten semihosting working, LED blinking, played around getting a timer running and so on.

I then decided to try to see if I can get the DAC to output a voltage. I simply turned on the peripherals (GPIO port A and the DAC itself), enabled the DAC and wrote a half-scale value. Once I uploaded the program and attached the debugger, the program started running fine, but while I was reaching for my DMM to check the DAC output, I thought I might be smelling burning electronics, though apparently the smell wasn't too strong as I wasn't worried at the time. Then the MCU suddenly stopped working, i.e. it stopped outputting the timer values on the debug channel, LED stopped blinking and so on. Based on the values output, this happened 26 seconds after startup (plus a few more seconds for initialization). At this point I realized that the regulator is very hot, and disconnected power from the board.

After trying out some things (which included connecting power for a few seconds at a time, as I didn't realize what's going on), I noticed that 3.3V and GND are shorted. I have a jumper on the board which allows breaking the power between the regulator and the rest of the circuit, for measuring current, and with that I was able to verify that the short is on the MCU side. The regulator seems to be working fine.

I'm now worried that I've burned the MCU and it's shorting internally. However, I don't remember it getting hot to the touch during the event, and now if I connect power for a few seconds, it does not heat up, which makes me doubt that the short would be in the MCU. The regulator pulls about 700mA (!) through the short, I would imagine that much current passing through the MCU would cause quite noticeable heating?

Also, I don't understand how could turning on the DAC or GPIOA cause such destruction (some details on the circuit in the end on the post)?

My questions:

1. What can I do to debug this? Obviously looking for shorts in individual components is a bit difficult, since the 3.3V and GND are shorted, so measuring decoupling caps or VCC pins for example just shows that the two sides are shorted. I have measured the non-power pins of the MCU, and those do not seem to be shorted to VCC or GND.


2. If it is the MCU that's broken, what, if anything, can I do to verify that? I'd really hate to cut the pins on the chip and remove it only to find out that the short remains.


3. How could turning on the wrong devices destroy the MCU (details on the circuit in the end)? It would be even worse if I swap the MCU only to burn another one (I have exactly one spare, after which there's a week of waiting and ridiculous postage to get the part...).

Now for the promised details:

• as the board is mostly unpopulated yet, there is nothing attached to any of the pins of GPIOA, except the JTAG, which shares some of them.


• the Vref+ -pin on the MCU is unconnected except for the decoupling caps, as there is a external reference which is not yet soldered on the board. As I was just testing, I was under the impression that VCC would be used for Vref+ in this case (although I realize now this is probably not the case). Could this actually cause destruction of the part?

Finally, relevant parts of the schematic, sorry for the messy layout:

Fig 1: GPIOA. All the labeled connections go to unpopulated areas of the board.

Fig 2: Power. 3.3VDAC is currently unconnected, but the caps are populated.

Finally, the DAC init code:

//Set up DAC1
RCC->APB1ENR |= (uint32_t)0x20000000;//Weird bug in stm32f10x.h, 

                                     //the macro constant isn't defined for XL devices
RCC->APB2ENR |= RCC_APB2ENR_IOPAEN;
DAC->CR |= DAC_CR_EN1;
DAC->DHR12R1 = 2048;

I didn't write anything to the mode configuration registers, as it looked like they should be all zeroes anyway, and this was just a very first test to see if I can get something out of the DACs. Proper init code would come later.

Answer

Considering how the problem got started, I convinced myself that it is very likely I've fried the MCU, so I proceeded to remove it by cutting its legs. Indeed, this resolved the short circuit, and measuring the earthly remains of the poor device shows that its VDD and VSS -pins are indeed shorted.

Also, from the STM32F103 Getting Started -manual, page 7: "In all cases, Vref+ must be between 2.4V and VDDA". I clearly broke this requirement, as the pin was floating.

Unfortunately, I ended up destroying some of the pads on the MCU in the process (probably used too much force/too dull a knife), so I will have to start the build all over again...

Anyway, the answer is that based on circumstantial evidence, it was likely that the MCU is fried, and this indeed turned out to be correct.

Update:

Having built the second prototype, with the reference now included, the MCU survived turning on the DAC, and seems to be working fine. There was also a minor mistake in the code, in that the reset state of the pins is floating input, whereas the recommended setting is analog input when using the DAC. I do not believe that this is the cause for the self-destruction though, as I would imagine the datasheet would state this a bit more strongly than as a "recommendation" if ignoring it destroys the whole device. However, I'm obviously a bit reluctant to put that to the test!

Just for anyone trying to google it, let me state the conclusion: floating Vref on STM32 destroys the chip!

Final note: do read Spehro's comments though, which suggest that there's a chance that this was simply a coincidence involving destruction by static electricity.