Community of electronics hobbyists established in 2002

Atom Feed | View unanswered posts | View active topics It is currently 17 Jan 2018 20:11

Reply to topic  [ 1 post ] 
Debugging an MCU short circuit 
Author Message

Joined: 13 Dec 2017 00:21
Posts: 1
Reply with quote
Hi to all, in my debugging program, there's a bad thing happened. I'm worried that I've burned the MCU and it's shorting internally.
Background for question: 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:

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.
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.
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
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.

13 Dec 2017 00:45
Display posts from previous:  Sort by  
Reply to topic   [ 1 post ] 

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.