MCU getting shorted internally(?), need some help figuring the cause.

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey!

 

I know its not atmel MCU im using, but i figured that i might get some help here, since from what i know here are people with superior knowledge about the electronics in general.

 

 

My best guess is that CC-debugger used to program the BLE112 module in the board does kill the STM32 mcu i'm using(third mcu just died yesterday), when certain thing happens.

there is atleast one thing i did overlook with the PCB connections which is the RESET pin of this BLE112 module, both CC-debugger and MCU connects to this pin from same NET without any current limiting between those.

 

So, is it possible that since i use the gpio as output from the mcu to control the reset state, and then attach the debugger to program the ble module, which also starts driving the reset pin, that it does source so much current that it kills the mcu?(there is no current limiting between the CC-debugger and MCU in place)

 

While i did program the BLE module the GPIO of MCU was logical 0(low) and programmed as output, after programming the BLE module, i still got connection to the MCU and did set the GPIO to high to let the module operate again, after that the fuse did blow almost instantly and the MCU was shorted.

 

this is the internal connection of GPIO pin for the MCU, if it helps.

 

Is there any remote chance that this could kill(short) the GPIO pin/port from the MCU? my knowledge is not enought here now.

 

 

This topic has a solution.
Last Edited: Sun. Feb 23, 2020 - 05:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do know that ST have their own forum - where you will find people with specific knowledge of their products ... ?

 

https://community.st.com/s/

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

You do know that ST have their own forum - where you will find people with specific knowledge of their products ... ?

 

https://community.st.com/s/

 

 

Yes, i do know and have asked from there aswell. But usually there are more Software oriented people than hardware from what i have observed. And i do know that in these forums there are active people who have huge knowledge about the hardware side of things.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Always give links when cross-posting!

 

https://community.st.com/s/question/0D50X0000C22SyHSQU/did-i-fry-my-mcugpio-output-in-locigal-low-while-external-source-did-drive-it-high-or-other-way-around

 

Otherwise you cause confusion and waste people's time by duplicating stuff

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
I know its not atmel MCU im using, but i figured that i might get some help here, since from what i know here are people with superior knowledge about the electronics in general.

 

Good idea to butter us up before asking about another vendors parts!!! laugh

 

Whenever I have to use lines for ISP/programming that i also need to use elsewhere I put a series resistor on the line(s), and connect the interface to the side of the resistor connected to the part I want to program.  Yes, teh pin on the other side may source/sink current but it should be within the devices limits.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Whenever I have to use lines for ISP/programming that i also need to use elsewhere I put a series resistor on the line(s), and connect the interface to the side of the resistor connected to the part I want to program.

Yes, I usually do that aswell. The first mcu got killed half an year ago, but only now I did figure that I'm missing resistor in this connection, even thought I have spent a lot of hours with the PCB and made sure that i don't violate any given specs of the components.

I need to get new PCB anyway since I forgot voltage divider from the gpio which does sense USB voltage, which does violate the vdd+4.0v maximium rating for that pin.(it's 5v tolerant pin so it's fine unless i attach usb cable without powering the board first)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
You do know that ST have their own forum - where you will find people with specific knowledge of their products ... ?

I think the fact that it's STM32 is irrelevant. If if were some AVR you'll probably blow that up also. It seems the BLE module & programmer combination is at fault.

 

I used to use a micro that during programming required +12V on its RESET/VPGM pin. That was in the early days of on-board flash but you may have something similar going on here.

 

The BLE122 datasheet may should offer some information on programming and almost certainly has advice on connecting the RESET pin.

 

Last Edited: Mon. Jan 27, 2020 - 08:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:
I used to use a micro that during programming required +12V on its RESET/VPGM pin. That was in the early days of on-board flash but you may have something similar going on here.

Hmmn, I haven't actually even thought about such scenario, I think it's TI's CC254x(?) Inside the module, need to consult the datasheet if such thing would actually happen, that there are some odd voltage levels.

Datasheet for the module or was it the mcu it uses internally tells that the reset is very sensitive to noise and one should use rc filter, other than that i can't recall anything special, but have to double check.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'm not quite sure I understand the setup, and I certainly don't know the voltage that the debugger or the BLE might put on the pin...

 

But, to answer your question, the micro I/O pin driver shows a totem pole, PFet and NFet transistors to drive the pin high and low when it is in digital output mode.

 

That is very similar to an AVR.

 

So yes, unfortunately, you can have a pin contention if one pin is trying to drive the pin high, and another pin is trying to drive the pin low, you essentially have V+ to PFet to other device to NFet to Ground as a short circuit.

 

So yes, it is easy to burn out either that I/O pin, or if one is extra unlucky, damage the entire chip beyond use.  

 

Depending upon your surgical skills you might be able to remove and replace the micro, and then cut a small gap in the trace going to it's shared I/O pin.

Then jump the gap with a small current limiting resistor.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you try disconnecting the debugger?  Maybe it is holding the micro in reset at all times, looking like to failed.  Make sure your program isn't trying to immediately pin reset the micro, otherwise it will chatter between running & resetting & may appear dead.  What does the reset pin look like on a scope?

 

You also have to assume the pins are extremely well conditioned during the reset release (that's probably an ok assumption)...even the nearly slightest pin low drive pulse (reset) would generate another reset, in an endless cycle. You assume the pin will be hi-z at all instants of the reset release (I'm assume reset upon low, but similar caution applies if reset is upon high).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Jan 28, 2020 - 02:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

So yes, unfortunately, you can have a pin contention if one pin is trying to drive the pin high, and another pin is trying to drive the pin low, you essentially have V+ to PFet to other device to NFet to Ground as a short circuit.

 

So yes, it is easy to burn out either that I/O pin, or if one is extra unlucky, damage the entire chip beyond use.

This is probably what is happening, first two burned MCU's was on day one when i assembled couple prototypes for first time, and at that time I had to program the ble112 Bluetooth modules firmware with CC-debugger programming tool, that was sad day 100€ worth of PCB/components to trash can since I don't have proper tools to take out small and components without damaging the pcb, at that point i did assembly third one, but this time it did not die and i kind of forgot the whole thing until now, It actually lasted good half year until couple days ago i had to reprogram the Bluetooth module on board, which at this time did kill the mcu just like the first 2 boards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, be extra careful that both the BLE module & micro are always powered together (hard to tell from your schematic).  If the BLE is powered, but the micro is not....bad things can happen.  You don't want one pin on the BLE module trying to parasitically power up the micro through a micro io pin (and vice-versa).  Putting resistors between all of their connecting lines can help (basically the current is reduced to a supposedly short-term non-damaging level).  If both chips share the same power net, this is not a concern.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Also, be extra careful that both the BLE module & micro are always powered together (hard to tell from your schematic).  If the BLE is powered, but the micro is not....bad things can happen.  You don't want one pin on the BLE module trying to parasitically power up the micro through a micro io pin (and vice-versa).  Putting resistors between all of their connecting lines can help (basically the current is reduced to a supposedly short-term non-damaging level).  If both chips share the same power net, this is not a concern.

Both are powered from same net, and I did not route the programmer pins that would feed power, so it should not be possible that only one is powered, or that either bluetooth module or mcu would try to power itself from some uknown path.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This isn't something silly, like a 5V programmer burning out a micro that can only tolerate 3.3V?.....it happens

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

This isn't something silly, like a 5V programmer burning out a micro that can only tolerate 3.3V?.....it happens

No, both are 3.3v devices(also the programmers are only capable of feeding 3.3v, but i left those traces unconnected anyway) and the mcu I use does have 5v tolerant IO's.

I do indeed have a "bug" in the hardware, if i attach usb without powering the board first it will feed 5v to "vbus sense", and IO can only take vdd+4v, which can kill it. But since i noticed that allready when waiting for the boards, i have just used used the spare usart I did break out on the board instead of USB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Can confirm now the fault was the missing resistor between mcu and cc-debugger(which both were driving the reset of ble module).

I got couple more boards assembled and did lift the gpio used to drive the ble module reset of the pad when soldering and the proplems are gone, well sort of, making the ble module to "sync it's state" with mcu software without having the reset capability certainly makes the development work harder for now, damn Corona virus can't get my new fixed pcb's..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well done!

well, almost done ... re PCB

There are PCB fabs in Europe.

PCB fabs in Finland?

 


Who are we? - Eurocircuits Eurocircuits Who are we?

Where are the boards made? | AISLER

 

A link to PCB fabs though an industry publication would be more extensive :

PCBShopper – A Price Comparison Site for Printed Circuit Boards

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Well done!

well, almost done ... re PCB

There are PCB fabs in Europe.

PCB fabs in Finland?

 


Who are we? - Eurocircuits Eurocircuits Who are we?

Where are the boards made? | AISLER

 

A link to PCB fabs though an industry publication would be more extensive :

PCBShopper – A Price Comparison Site for Printed Circuit Boards

 

It's the price proplem, I can get the 4-layer boards 10 pieces for less than 50€ from china and in black surface color! From Europe the price is allready atleast 5-6x that amount. Here in Finland would cost ~500€ to get couple boards done for testing, which is quite alot since I'm funding the project from my own pocket.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think we used to pay $600 or thereabouts to get the photo negatives made from our PCB CAD file (took 10 days for the negatives to arrive at our facility), so the board could then be etched for a few hundred dollars each (took another 2 weeks).  Five boards for $1200 if you were in a hurry.   Of course, even the slightest change & the process would start all over.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!