PIC 12F509 begins to heat at power up

[Pedro Pinto]

Hello

Have anyone a idea what happens.
I have a board with a 12F509 and sometimes when power up the circuit
it begins to heat up and all the IO's are high.
I programm it with intern RC oscilator and the MCRL pin as digital IO
As i said it just happens sometimes.

Thanks for any idea
Best regards
Pedro

[mackrackit]

What do you have connected to the PIC?
Do you have TRIS? statements at the beginning of your code to control the pin's direction?

[Acetronics2]

Hi,

I got such a surprise , years ago with a 16C84 ... ( Andeas Voggender R/C Esc , showns in Elektor Magazine - project 960095-11 ).

While receiving too much glitches, the PIC begins to heat ... one and only solution : power OFF !!!

No overloaded output ...

Back to the " constructive " side ... you must take great care to the config sequence of your PIC, and especially to the reset circuitry.



When the device starts normal operation (exits the
reset condition), device operating parameters (voltage,
frequency, temperature, ...) must be met to ensure
operation. If these conditions are not met, the device
must be held in reset until the operating parameters are
met


these lines are "not so innocent" ...

see Datasheet related pages for that ...

Alain

PS : could you join the " faulty " program ???

[Pedro Pinto]

Hello Acetronics

I think the problem is the Pic itself. I have until 2 years ago 1000 boards that
have not this problems, for 4 Months have make more 200 units and receive 6
boards back from customers that have this problems.

The init part of the code is very simple

sorry, this a original init code, the previous was experiments


DEFINE OSCCAL_2K 1
'
sepic_ok var GPIO.3
call_shutdown var GPIO.4
sepic_on_off var GPIO.5
pulsador var GPIO.2
am_on_off var GPIO.1
'sense var GPIO.0
'
TRISIO = %11001111
'
low sepic_on_off
low call_shutdown
'
ciclo var word
conta var byte
conta2 var byte
flag_pulsador var byte
'
DEFINE DEBUG_REG GPIO
DEFINE DEBUG_BIT 4
DEFINE DEBUG_BAUD 2400
DEFINE DEBUG_MODE 1 '1= direct to pic
DEFINE DEBUG_PACING 1000
'

DEBUG "V1.1 08/07",10,13
'
pause 500 'estabilise

ini:low call_shutdown
ciclo = 1:pause 10
if pulsador = 1 then ini
for ciclo = 1 to 100 ' "debounce"
if pulsador = 1 then ini
pause 1
next ciclo

'Learn if it a switch or a press button
inicia:
High sepic_on_off 'set Buck/Boost on
pause 1000
for ciclo = 1 to 50 'test if the Buck/Boost works
if sepic_ok = 0 then
for conta = 1 to 100
pause 10
if sepic_ok = 1 then learn
next conta
low sepic_on_off 'sepic not OK, shut down
pause 3000
goto ini
endif


The rest of the code is a loop to look for shut down by the user or if the sepic not working

Best regards
Pedro

[mackrackit]

Bad set of boards. Seems pretty clear now.

[Pedro Pinto]

Hello mackrackit
What do you mean?
Bad set of boards. Seems pretty clear now.


Regards
Pedro

[mackrackit]

Same old code, same chip, new batch of boards.
Check for a bad trace.

[ErnieM]

Same old code, same chip, new batch of boards.
Check for a bad trace.

OR... new revision silicon is acting up (doubtful).

Interesting problem, current is going somewhere, but current isn't a directly measurable quantity suck as voltage is. Good news is you only have 6 I/O pins to check.

Depending on how repeatable the problem and how disposable a board is you could try removing one pin at a time to see who the current hog is, then seeing if you can switch on the big current if you put the offending pin back in.

One thing to check is if an INPUT is causing the problem: if an input goes to about half Vdd then it will draw a big current (thru Vdd->Vss, not the pin itself).

[Pedro Pinto]

Hello

OR... new revision silicon is acting up (doubtful).

This is always my opinion. I will order a few Pic's
to test.
The inputs are not the problem i have wired for the
tests all inputs to vcc and the problem are the same.

Regards
Pedro

[Acetronics2]

Hi, Pedro

Could you post a piece of scheme ( just around the PIC - with reset circuitry ! )

Alain

PS: in your code, you should preset your outputs ( even inputs ) BEFORE the TRIS command ...

[ErnieM]

I went thru your code a bit to count I's and O's: looks like you have two outputs.

While you wait for your chips to arrive you may want to try this: (assuming you can ICSP this board) make up some test programs, either 4 programs to try each of the two output lines high and low, or use 1 input to step thru the combos.

That way you can see if a single output being hi or low is causing the current.

Acetronics' comment about presetting GPIO's before TRIS is well taken: GPIO is undefined after a reset and perhaps a momentary state collision is occasionally taking down the power supply and ending the program right there.

Post the schematic (as much as you will).

[Pedro Pinto]

Hello ErnieM

I not preset GPIO before TRIS, i make only a alias from the pins before TRISIO

Attached the schematic

Regards
Pedro

[Archangel]

I not preset GPIO before TRIS, i make only a alias from the pins before TRISIO
Pedro

Hi Pedro,
That was the point, that you should, so when TRIS makes the port an output it does so in a state chosen by YOU, not the devil.

[Pedro Pinto]

Hello Joe S.

English is not my natural language, sorry i not understand very well what
you mean in your answer. Is anything wrong in this code?



DEFINE OSCCAL_2K 1
'
sepic_ok var GPIO.3
call_shutdown var GPIO.4
sepic_on_off var GPIO.5
pulsador var GPIO.2
am_on_off var GPIO.1
'sense var GPIO.0
'
TRISIO = %11001111
'
low sepic_on_off
low call_shutdown
'
ciclo var word
conta var byte
conta2 var byte
flag_pulsador var byte


Do you think that i must change it? if yes, what?

Thanks
Best regards
Pedro

[Archangel]

Hello Joe S.

English is not my natural language, sorry i not understand very well what
you mean in your answer. Is anything wrong in this code?
Pedro
Hi Pedro,
I have not time to check data sheets, it's WorkTime , but check what I did below, the comment in blue is because I have not checked the data sheet.


DEFINE OSCCAL_2K 1<font color=blue> 'is this correct? </font color>
'
sepic_ok var GPIO.3
call_shutdown var GPIO.4
sepic_on_off var GPIO.5
pulsador var GPIO.2
am_on_off var GPIO.1
'sense var GPIO.0
'
GPIO = %00000000 '<font color=red>change to suit Your needs</font color>
TRISIO = %11001111
'
low sepic_on_off
low call_shutdown
'
ciclo var word
conta var byte
conta2 var byte
flag_pulsador var byte

[ruijc]

Greetings Pedro,

I think that the idea is to set the pin state before the tris:

GPIO=%01010101 ( either high or low )

PS. tens de definir o estado inicial dos portos ( altos ou baixos ) antes de definires o trisio ;)

PS2. - Like Joe said :)

Regards

[Pedro Pinto]

Hello

Thanks, i will try it. That is the first and unique project where i use a 8 pin PIC
The 12F509 have Flash Program Memory of 1.5 kBytes
The 12F508 have Flash Program Memory of 0.5 kBytes
Therfore i think that is correct - DEFINE OSCCAL_2K 1 - I hope i'm not wrong

The datasheet says - On Reset ALL pins are input.
I will test with GPIO = %00000000 and after that to set the
TRISIO = %11001111

I notice if i have success with this changes

Thanks All

Best Regards
Pedro

Para o Rui, quando estiveres o MSN, falamos

[Archangel]

Hello

Thanks, i will try it. That is the first and unique project where i use a 8 pin PIC
The 12F509 have Flash Program Memory of 1.5 kBytes
The 12F508 have Flash Program Memory of 0.5 kBytes
Therfore i think that is correct - DEFINE OSCCAL_2K 1 - I hope i'm not wrong

The datasheet says - On Reset ALL pins are input.
I will test with GPIO = %00000000 and after that to set the
TRISIO = %11001111

I notice if i have success with this changes

Thanks All

Best Regards
Pedro

Para o Rui, quando estiveres o MSN, falamos

I think you should have
DEFINE OSC 4
in your code. I have never seen OSSCAL done as a define before, I
do not see why not, but I have only seen it done as so:
OSCCAL = %0000000
or
OSCCAL = $00

ANYBODY want to give a short treatise on this ?

[mackrackit]

???????????



PicBasic Pro Compiler
calibration factor in the last location of code space. The on-chip
oscillator may be fine-tuned by acquiring the data from this location and
moving it into the OSCCAL register. Two DEFINEs have been created
to perform this task automatically each time the program starts:
Define OSCCAL_1K 1 ' Set OSCCAL for 1K
device
Define OSCCAL_2K 1 ' Set OSCCAL for 2K
device
Add one of these 2 DEFINEs near the beginning of the PicBasic Pro
program to perform the setting of OSCCAL.

[ErnieM]

Pedro,

Don't apologies for your English. I'm always amazed when people can learn anything (such as electronics) in something other then their native language: that double translation is huge, good for you for jumping it.

So in your code you state:

TRISIO = %11001111

That sets GP0 to GP3 to inputs, and GP4 and GP5 to outputs. Yet your schematic shows GP5 is the only output.

Which one is correct?

But that isn't the problem anyway, even if all pins are driven as low outputs there isn't enough current to make trouble. What does concern me is the GP2 input: if that ever mistakenly is used as an output it is directly connected to ground and hence will suck out a ton of current.

[Archangel]

???????????

Thanks Dave, I missed that.

[Pedro Pinto]

Hello ErnieM

The GPIO.2 is a input, like you can see on the TRIS
TRISIO = %11001111
This input alias "pulsador" have a resistor 27k to VCC and a press switch to GND to turn on a external circuit. When press the on button then the GPIO.5
go high and turn on the external circuit. The other pins are all inputs except the GPIO.4 that are output, on it in serie a resistor of 1k and after power up i make it low.

Best regards
Pedro

[ErnieM]

Pedro,

OK, so GP4 and GP5 are the outputs, the rest are inputs. Each output has a 1K resistor, so the max that goes into/out of there is 5/1K or 5mA each output, 10 mA total. 10 is well within any PIC limit. That isn't where the problem is.

In your original post you state the problem happens "sometimes." Does this mean a particular part will sometimes fault, or sometimes several parts in a lot will fault but each will fault every time?

Do you do any testing before shipping? If you have customer returns after test then the parts seem to have worked at least once.

[Pedro Pinto]

Hello ErnieM

Thank you for help
With the first 1000 boards two years ago i have not receive back one board with this problem.
For 3 months i have make 220 same boards, same software and now received
back from coustomer 6 unit with this problems. I have order a few Pic's now to test with this new order serie. I will hope, it helps, than i have no more ideas what can be that. In this moment i think that it is the Pic. I post feedback when i receive the news pic's

Best regards
Pedro

[Ingvar]

Pedro,

Have you checked that all resistorvalues are what they should be? It happens that resistors are faulty, or most common, wrong value was fitted at manufacturingtime. There could also be a short across a resistor thus making it zero, this not easy to spot if it's underneath the resistor. There is also the possibility that the PIC have experienced a nasty shock that makes a pin stuck at high or low level, even when it shouldn't be. I've seen them all over the years. Lucky for you, your board isn't so big, you should be able to measure all possible combinations.

/Ingvar

[ErnieM]

Always helps to go back to the definition of the problem:

Hello
Have anyone a idea what happens.
I have a board with a 12F509 and <b>sometimes</b> when power up the circuit it begins to heat up and <b>all the IO's</b> are high.


Questions:

Does <b>"sometimes"</b> mean some units all the time or any unit some of the time? Do the bad units fail every time or not every time?

Does <b>"all the IO's"</b> really mean all? GP0 to GP4 are normally at 5V at turn on as they have their pull-up resistors to 5V. How close to 5V are they? Same voltage to a millivolt or so or are they measurably lower or higher? (If different that tells us where current is going, the amount of difference tells us how much current).

And when failing, are Vdd and Vss still normal?