Pic microcontroller trekt veel stroom

Dit heb ik nog al eens ergens gelezen, je hebt je pic toch goed ingesteld want blijkbaar kan het dus dat ie te snel loopt omdat hij op een verkeerde frequentie (klok snelheid) is ingesteld en dus overklokt is, waardoor ie nu te veel stroom trekt.

Wat staat er in je main loop?

Een oneindige loop? Zo ja is dat niet helemaal goed, je staat dan gewoon cpu cycles te verstoken.
In dit geval bij jouw is dat bijna letterlijk.

Kijk in de documentatie hoe je een sleep kunt doen, zodat deze een wakeup doet op moment dat er een interrupt komt de cpu wakker wordt.

Zoiets wordt het dan:

while(1) {
Sleep();
}

Hoe die instructie bij een pic heet weet ik zo niet uit mijn hoofd.

Te dikke onderdeelpootjes maakt geen sluitingen, maar je breadboard gaat er wel aan, doordat de kontakten niet meer veren en open blijven staan.
Een kale PIC die 100mA trekt klopt natuurlijk niet. Is de 50Hz wel netjes begrensd op Gnd...Vcc? (Anders trekken de clamping diodes erg veel stroom)
@Damic: Van ietsje overklokken gaat 'ie niet 500x zo veel gebruiken.

Woops over gelezen. Dat is wel een groot getal.

Oke breadboard is niet de oorzaak dan. In de main loop staat inderdaad niets. het is nu enkel

void main()
{
init();
}

Verder moet de micro controller wel goed ingesteld staan. Want hij werkt wel. Én netjes op tijd. De 50 hz is netjes 5V - 0V. Maar ook als hij daarvan zelfs los hangt trekt hij 100 mA. Hij hang nu dus alleen aan de voeding.

Ik vrees dat 'ie dan is overleden...
Heb je wel beide Vss aansluitingen aangesloten?

[Bericht gewijzigd door Arco op donderdag 5 juli 2012 22:49:57 (40%)

Hardware:
Tsja, een sluiting ergens tussen twee pootjes kan ook.

Wat een zeer plausibele oorzaak is dat je 50Hz aansluiting latchup veroorzaakt in het substraat (Zie opmerking van'Arco').
Dus bij voorkeur twee shottky diodes gebruiken om de inputs tegen de +5V en GND te begrenzen.

-edit-: Niet dus volgens bovenstaande post, ik wil je dit toch even vertellen:

Daar moet je NOOIT de interne clamping diode voor 'misbruiken' dat kan een soort "thyristor" werking veroorzaken zodat de hele chip spontaan in sluiting gaat, dat noemt men dus latchup. Dat gebeurd als je een pin onder spanning zet en daarna pas de VCC aansluit.
Bij zo'n truuk (50Hz aftappen van de trafo) is die spanning altijd net wat eerder als de VCC die via een regulator aangeboden wordt.

Ik heb echt zo complete chips zien ontploffen, dat is geen grap.

Dus ik denk dat dit nu de oorzaak is dat je chip gedeeltelijk overleden is.

Software:
Wat zit er in die init() een oneindige loop?

Het lijkt er nu op de in de main() geen while(1) zit, dus je code loopt gewoon uit je main. Knap dat het dan toch nog werkt.
Als de init() code geen blocking while() bevat zou ik toch even proberen dat erin te zetten.

Nee ik heb nu enkel 1 VCC en gnd gebruikt. Het gedeelte over latchup gaat me eventjes iets te snel. Verder is dit mijn code:

int number=0;
int number2=0;
int number3=0;
int number4=10;
int count=0;
int cnt=0;
int i;
int displayteller= 0;
int shifter = 1;
int cijfer[4] = {0,0,0,10};
int teller = 0;


void init()
{
TrisA = 0b11111111;
TrisB = 0b00000000;
TrisC = 0b00000000;
TrisD = 0b00000000;
PortA = 0b00000000;
PortB = 0b00000000;
PortC = 0b11111111;
PortD = 0b00000000;

ANSEL = 0;          // alle pinnen digitaal
ANSELH = 0;

//interrupt instellingen
TMR0 = 206;
TMR2 = 0;          // Initial value of timer register TMR2

OPTION_REG.F7 = 1;
OPTION_REG.F6 = 1;
OPTION_REG.F5 = 1;        // Counter TMR0 receives pulses through the RA4 pin
OPTION_REG.F4 = 1;
OPTION_REG.F3 = 1;        // Prescaler rate is 1:1
OPTION_REG.F2 = 0;
OPTION_REG.F1 = 0;
OPTION_REG.F0 = 0;








T2CON = 0b00000100;       // Set timer T2
INTCON = 0b11100000;      // Set bits GIE and PEIE
PIE1.TMR2IE = 1;    // Enable interrupt
/*OPTION_REG = 0b10111110;*/

}




void ssegments(int i){
switch(i)
{
case 0:portc = 192; break;
case 1:portc = 249; break;
case 2:portc = 164; break;
case 3:portc = 176; break;
case 4:portc = 153; break;
case 5:portc = 146; break;
case 6:portc = 130; break;
case 7:portc = 248; break;
case 8:portc = 128; break;
case 9:portc = 144; break;
case 10:portc = 255; break;
case 11:portc = 249; break;
case 12:portc = 164; break;
}
}


void interrupt() {
if (INTCON.TMR0IF) {

    TMR0 = 206;
    INTCON.TMR0IF = 0;
    teller++;
    /*portb = ~portb;*/
    if (teller > 59)
    {
    teller = 0;
    cijfer[0]++;

    }
    if (cijfer[0] > 9)
    {
    cijfer[0] = 0;
    cijfer[1]++;
    }
    if (cijfer[1] > 5)
    {
    cijfer[1] = 0;
    cijfer[2]++;
    }
    if (cijfer[2] > 9)
    {
    cijfer[2] = 0;
    cijfer[3]++;
    }
    if (cijfer[3] > 11 && cijfer[2] > 3)
    {
    cijfer[0] = 0;
    cijfer[1] = 0;
    cijfer[2] = 0;
    cijfer[3] = 10;
    }

  } 


if (PIR1.TMR2IF) {
    PORTD = 0;  
    ssegments(cijfer[count]);
    PORTD = SHIFTER;
    
    count++;
    if (count > 3)
    count = 0;

    shifter <<= 1;
    if (shifter > 8u)
    shifter = 1;

    TMR2 = 0;
    PIR1.TMR2IF = 0;


}


}

void main()
{
init();





}

Inderdaad geen while loop. Echter functioneert het geheel wel.

Waarschijnlijk voegt de compiler zelf een eindeloze loop toe, maar ik zou daar niet op vertrouwen...
De beide Vss aansluitingen MOETEN aangesloten worden. (En uiteraard een 100nF tussen Vcc/Vss bij chip)

Probeer dit eens in je main: (en zoals Arco zegt: goed aansluiten!)

void main()
{
init();
 
  while(1) {
    Sleep(); 
  } 
 
}

[Bericht gewijzigd door henri62 op donderdag 5 juli 2012 23:05:59 (14%)

Ik ga dat morgen meteen proberen. Ook heb ik nog 1 reserve liggen. Dus kan daar de code ook eens inschieten. Bedankt voor de input! Ik houd jullie op de hoogte.

Op 5 juli 2012 23:03:35 schreef Arco:
Waarschijnlijk voegt de compiler zelf een eindeloze loop toe, maar ik zou daar niet op vertrouwen...
De beide Vss aansluitingen MOETEN aangesloten worden. (En uiteraard een 100nF tussen Vcc/Vss bij chip)

Als de Pic het einde van zijn code bereikt heeft loopt het de rest van het geheugen af en begint daarna weer op nieuw. De opcode die in de lege ruimte staat wordt door lopen. Weet niet 100% zeker of dit voor elke PIC geld.

Wat je kan doen is een port hoog zetten in het begin voor init. Scoop erop en misschien kan je zien of hij in een reset loop loopt.

Het idee van henri62 is dan ook een oplossing.

Sommige compilers voegen zelf een eindeloze loop toe aan het eind van de code...

Misschien eens vanaf de hardware-kant bekijken, hoe worden die displays aangestuurd ?
Als de segmenten van de displays direkt aan de PIC-pins hangen, moet de PIC de stroom voor de segmenten leveren, dan is het natuurlijk logisch dat die stroom eerst opgenomen moet worden.
Als er transistoren tussen zitten, moet de PIC nog steeds de basisstroom leveren voor die transistoren, en die kan, afhankelijk van het aantal aan te sturen transistoren en de gekozen basisweerstanden natuurlijk ook nog hoog zijn.

In de startpost staat dat de kale PIC ook 100mA trekt, dus daar ligt het niet aan...

Op AVR is er ergens een opstartroutine die main aanroept. Main hoort niet terug te keren, dus daarna springt ie terug naar af.

Iets als:

  main ();
  goto _reset;

Gaat nou iedereen eraan voorbij dat een μC of picding normaal nooit 100mA kan trekken? Ook als het ding gewoon cycles staat te draaien niet (dus niet staat te sleepen). Doet-ie dat wel, dan is er wat mis. Danwel in de aansluitingen, danwel 'schade'. Aansluitingen controleren (alles wat er zijn moet, moet er zijn, alles wat er niet moet zijn is er niet), ontkoppeling controleren, voeding controleren. Als dat allemaal binnen spec valt en het ding blijft stroom gebruiken: ding wegmikken.

Ik heb vorige week nog een pic gehad die 200+ mA verstookte. Na een paar minuten deed die niks meer. Niet kunnen achterhalen waar het precies aan lag. Alles was goed aangesloten, en hij heeft een paar maanden bijna non-stop goed gewerkt.

Of de PIC controller nu staat te wachten (pause) of een flinke rekensom maakt, dit heeft geen invloed op het stroom verbruik. Het stroomverbruik is wel afhankelijk van de ingestelde clock. Voor 8Mhz is meer stroom nodig dan 4Mhz. Zuinigste is op 32Khz, zeer geschikt voor batterijvoeding. Dus een PIC controller die waarbij alleen de + en - is aangesloten al 100mA trekt is gewoon stuk!

De PIC16F887 is zelfs van het nanoWatt Technology type, dus verbruik 220uA bij 2.0-Volt bij een clock van 4Mhz. !!! Standby slechts 50nA.

Het beste is om FETs te gebruiken als je veel LEDs wilt aansturen/multiplexen. Types zoals BSS138 zijn zeer geschikt.

Ik sluit me bij EricP aan, die controller kan wel weg. Waarschijnlijk is iets doorgeslagen naar het substraat.

@Henry S.: Ja denk ik ook, kan latchup geweest zijn of ESD.

Op 6 juli 2012 16:17:18 schreef plano:
Of de PIC controller nu staat te wachten (pause) of een flinke rekensom maakt, dit heeft geen invloed op het stroom verbruik.

Daar ben ik het niet mee eens, als je de Sleep() zorgvuldig gebruikt heeft dit wel degelijk invloed op het stroomverbruik.

Maar in dit geval is het verschil veel te groot, dus stuk of ergens een kortsluiting.

@ Henri6, Ik had het over Pause of Delayms.

Bij Sleep zet je de PIC in Slaapstand. Hij neemt dan slechts een paar uA.

Ja de PIC is inderdaad overleden. Heb het sleep gedeelte nog geprobeerd en dat mocht niet baten. Vervolgens heb ik een nieuwe 16F887 gepakt en precies hetzelfde programma er in geladen. Deze doet het met enkele mA.

Nu blijft mij de vraag hoe ik wél veilig de 50 hz aan kan bieden? Ik deed het nu met een comparator en daar de sinus rechtstreeks op. Of zou een 32.768 khz kristal net zo precies zijn?

Zet een zenerdiode van 4v7 van de pin naar gnd. En voer het signaal aan via een weerstand van 2k2...
Je kunt trouwens op de kapotte PIC nog wel kijken waar de sluiting zit. Meet alle pins door naar Vss en Gnd pin met een multimeter op doorpiepen. (Dus gewoon zonder voedingsspanning er op)

[Bericht gewijzigd door Arco op vrijdag 6 juli 2012 21:12:34 (49%)