cancel
Showing results for 
Search instead for 
Did you mean: 

Check if a uC is alive or dead

tecnico23
Associate II
Posted on April 11, 2012 at 18:39

I wonder if someone could help me.

I recently have developed my own PCB board. I've soldered all the components, and now I want to starting downloading some firmware to the uC (STM32F407ZG - LQFP144pin).

For my surprise I can't connect my programmer to the uC via JTAG. I've contact my programer/ IDE supplier and after some check procedure we concluded that the programmer is OK and that it can't connect with my uC.

I've double checked all connections, and power supply. Everything seems to be OK. I have analysed the board and the schematic, and the power supply pins and, JTAG pins are well connected.

I've also measured 1.29V on the VCAP1 and VCAP2 pin.

But I can't comunicate with the device.

At this time, I would like to check if the uC is dead or alive, but I don't know how to procedure.

Do someone know if there is some pins where I can read a signal to check if the device is alive? I thought that the VCAP pin could be a start, but even with the 1.29V the device don't communicate with the programmer.

I've also turned the boot0 On and OFF (to enter in system memory). But the device don't react.

I've also turned the PDR_ON pin ON and OFF. And the device don't react.

Thank you all,

Best regards,

A.Paiva

28 REPLIES 28
Posted on April 11, 2012 at 18:49

I've also turned the boot0 On and OFF (to enter in system memory). But the device don't react.

 

It doesn't react, or is simply waiting for the right stimulus?

With BOOT0 high when reset the part expects you to send a 0x7F (8-E-1) at a baud rate of your choice, if it is functional it will then send back a 0x79. Should work with USART1 or USART3

If this doesn't work after repeated reboots, we can assume your part or circuit are bad.

If you have a known good eval board you'd also be able to test your JTAG and IDE.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
tecnico23
Associate II
Posted on April 11, 2012 at 19:30

Hi Clive1,

Thank you for your reply.

When I said it don't reacts, I mean I can't establish any connection between the uC and the programmer.

Regards,

A.Paiva

emalund
Associate III
Posted on April 11, 2012 at 19:49

besides the obvious (bad/wrong/shorted JTAG connection) the most frequent reasons for no JTAG are

a) reset

b) insufficient decoupling

c) not all power pins powered

d) not all ground pins grounded

e) oscillator not running

Erik

Posted on April 11, 2012 at 19:59

I agree with Erik, most of these problems are usually mundane issues, rather that ST shipping bad chips or JTAG vendors shipping bad pods.

If you had a STM32F4 Discovery, you could at least compare-and-contrast what some of the pins do. Definately check for solder bridges, and make sure the reset pins aren't driven high or low with external push-pull drivers.

I would however think that ST missed a trick with the System Loader ROM, by not toggling some GPIO pins, or outputting a clock via MCO. I can definately see how something like that would be helpful.

The System Loader uses the HSI and PLL, so none of the external oscillators will show signs-of-life.

I've contact my programer/ IDE supplier and after some check procedure we concluded that the programmer is OK and that it can't connect with my uC.

 

I'm sure they get a lot of that. This is why it's useful to have a number of pods, and boards that one can test them against.
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
tecnico23
Associate II
Posted on April 11, 2012 at 20:08

Hi Erik,

Thank you for your reply. Do you know how can I see if the oscilator is running? By factory, the internal oscilator is selected right?

What about PRD_On pin? Should it be tied to Vdd or VSS?

Regards,

A.Paiva

tecnico23
Associate II
Posted on April 11, 2012 at 20:30

I would however think that ST missed a trick with the System Loader ROM, by not toggling some GPIO pins, or outputting a clock via MCO. I can definately see how something like that would be helpful.

 

 

I agree with you clive.

I have verified solder bridges, and connections with all pins. All the ground pins are tied to ground and all power supply pins are tied do VDD.

I'm not sure if I should tied the PDR_ON pin to ground or to VDD.

But, as I have reffered before, I can measure 1.27V on VCAP. This means that something is still alive in the device.

I didn't said that ST shipped bad ships. But I've read that this device is very absortion sensitive, and can be demaged if it absorbs humidity. Is it right?

Posted on April 11, 2012 at 20:59

I didn't said that ST shipped bad ships. But I've read that this device is very absortion sensitive, and can be demaged if it absorbs humidity. Is it right?

 

I meant that the chance of the part/pod being bad were significantly lower than the board/soldering.

The moisture is an issue with wave/reflow soldering on a line, you get a pop-corn effect with the device physically exploding as the water turns to steam and has no where to go. You're unlikely to see this with a soldering iron.
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on April 11, 2012 at 21:04

I'm not sure if I should tied the PDR_ON pin to ground or to VDD.

 

The STM32F4-Discovery ties it to GND
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
tecnico23
Associate II
Posted on April 11, 2012 at 21:47

I've designed my board based on the STM32F4Discovery and the STM320G-Eval board, and the device datasheet. I've verified the power supply on all power pins.

Clive1, what about the 1.29V on the VCAP pin? What kind of conclusions can we take?