B0/INT interrupt crasht microcontroller

Beide zijn aanwezig. 10K naar Vdd en 100nF naar gnd.
Lijkt me geen MCLR probleem, want als ik de rotary encoder met rust laat werkt het prima.

Het project is een GPS logger. Ik heb er een route van 1,5 uur gewoon mee kunnen loggen zonder resets. Zolang je maar van die rotary encoder afblijft...

Het lijkt me dat er dan toch ergens iets lelijks in je code moet gebeuren...
RB0 staat ook niet als output? Probeer anders eens een gewoon drukschakelaartje i.p.v. de rotary.

Zelfs als ik mijn hele main loop reduceer tot dit:


for(;;) {

}

(en alle config en functie declaraties met rust laat) blijft het ding willekeurig crashen op een interrupt... Schakelaartje ga ik morgen eens testen, maar ik vermoed dat dit ook gewoon moet werken.

Edit:

Op 7 juli 2011 23:52:18 schreef Arco:
Ook zoals gezegd kijken dat RB0 niet als output staat. Dan werkt hij wel als input, maar trekt erg veel stroom...

TRISB0 is als input ingesteld... Dat lijkt me toch correct?

[Bericht gewijzigd door TheCrazyInventor op (26%)]

Ook zoals gezegd kijken dat RB0 niet als output staat. Dan werkt hij wel als input, maar trekt erg veel stroom...

Het is toch niet een heel "oude" 16F876 ?
Met een productiedatum uit 2002 of eerder ?

Ooit twee weken gespendeerd aan een soortgelijk random crash probleem met een interrupt (toevallig ook met een rotary encoder). Bleek het uiteindelijk een bug in 16F876A te zijn (chip revisie B0).

Een nieuwere chip besteld en het probleem was opgelost (en ik had flink wat tijd verspilt). Dit probleem is beschreven in het rev B0 errata sheet (ds80128f.pdf).

De datum stempel op de PIC is 062252S. Ik kan even nergens vinden hoe je die datum moet lezen, maar dit lijkt op week 22 van 2006.

Misschien moet je niet in je programma zoeken, maar zit je ergens met een elektrisch/EMC probleem.

Op 8 juli 2011 12:00:35 schreef TheCrazyInventor:
De datum stempel op de PIC is 062252S. Ik kan even nergens vinden hoe je die datum moet lezen, maar dit lijkt op week 22 van 2006.

Yep, daar is die bug al in gefixt. Dan moet je na een reset maar eens kijken waardoor die reset komt (TO en PD), misschien heb je glitches op de power of reset lijn.

OK, probleem gefixt... Hoe? Weerstandje in serie met de voeding van de encoder gesoldeerd.

Ik dacht vanmorgen dat het aan het ontdenderen kan liggen. Dus daarom eens een potmetertje van 1k in serie met de voeding van de encoder geplaatst. Dat bleek te werken. Sommige kliks zag hij niet, maar hij crasht in ieder geval niet...
Vervolgens die potmeter terug gaan draaien. Op een gegeven moment deed hij het lekker ZONDER te resetten. Dat bleek bij 10 ohm te zijn. Ik kon zelfs nog tot 5 ohm zakken... Daar heb ik het maar op gehouden en dat heb ik er tussen gebakken.

Ik begrijp nu nog steeds niet waarom het ding eerst wel deed resetten. Veel interrupts achter elkaar (vanwege denderen) is toch geen reden om te resetten...? En 5 ohm is toch totaal niks op de 10K pulldown die er al zat...

Denderen -> veel interrupts -> stack ontploft?

Alleen, ik denk niet dat 5R in serie het denderen oplost... Dan heb je toch een RC combinatie nodig.

Hoezo ontploft de stack? Als er een interrupt is geweest, worden de interrupts uitgeschakeld. De INT interrupt word afgehandeld en vervolgens worden de interrupts weer ingeschakeld. De ISR word vervolgens weer aangeroepen vanwege dender en het hele verhaal hierboven begint weer opnieuw... De stack word dan nu toch niet veel groter? En daarbij, er is plaats zat op mijn stack. Programma is niet zo complex.

Ik vind dit soort 'fixes' maar griezelig... (Iets doen 'omdat 't werkt'...)
Moet een andere oorzaak zijn. (Dender kan een MCU niet laten vastlopen of resetten)
Ook ontkoppelingsc 100nF aanwezig tussen Vcc en Gnd bij PIC?

@inventor, een klassieke stack ontploft gebeurt als je interrupt niet vanzelf de interrupts uitzet en/of aanzet. Hoe dat in de PIC ook al weer werkte weet ik niet meer.

Ik zie jou code iets doen als INTF = 0. Mogelijk zet je daarmee je interrupts al weer aan. Als er dan al een interrupt staat te wachten.... gaat ie nog voordat ie de return from interrupt gedaan heeft weer de interrupt routine in. Die moet returnen naar de eerste interrupt routine, dus dat kost een extra stack positie. Enz. enz....

Is dat gedoe met "intf" nodig? .... effe gegoogled: ja. OK.

@ arco: ik vind deze "fix" ook maar niks. Ik snap gewoon niet hoe dit kan werken... Als ik die weerstand weg neem reset hij zich weer mooi, zoals hij altijd deed. Soldeer ik hem terug --> alles goed. Misschien wat Peter al zei, een EMC probleem oid... De flanken uit die encoder zijn vrij krap.

Heb al verschillende dingetjes geprobeert zoals een grotere waarde voor de pulldown, grotere ontdender capaciteit, kleinere ontdender capaciteit, maar het probleem blijft gewoon.

@rew: als de PIC de ISR verlaat, word er een context restore gedaan. Daar worden de interrupts ook weer ingeschakeld. Als ik het goed begrepen heb, heeft de ISR de stack alweer verlaten voordat de interrupts weer worden geactiveerd.

[Bericht gewijzigd door TheCrazyInventor op (20%)]

Je kunt de 16f876a ook vervangen door een 16f1936. Pin compatible, goedkoper, en kan veel meer...
Die heeft een tweemaal zo grote stack, en ook een 'stack overflow' flag die je kunt testen.
Zou met wat kleine wijzigingen in de firmware moeten werken.

Probeer eens een 100nF tussen de RB0/INT en GND te zetten ? Dit zal het dender-probleem op lossen...
Uiteraard ook een 100nF tussen de GND & +5V, dichtbij de µC

@roel: cap op B0/INT zit er al:

Op 7 juli 2011 23:31:25 schreef TheCrazyInventor:
Beide zijn aanwezig. 10K naar Vdd en 100nF naar gnd.

Ontkoppel condensators op de voeding van de pic is er ook. Het project is verder batterij gevoed (3 * lion) en de spanning wordt geregeld met een 7805. Mijn scoop vindt dat de voeding zeer stabiel is. Het hele project trekt ook maar slechts 60mA.

zodra je de interrupt handler binnevalt moet je de interrupt disablen.. waar gebeurt dat in je code.

en die stack. ik meen me te herinneren dat de 16 reeks hoop en al 4 of 6 levels heeft op zijn stack ....

dat gedoe met die 5 ohm weerstand wijst op een mogelijke hardware probleem...

ben je zeker dat de logische nieveaus niet boven de voeding van de pic uit komen ?

zet eens een scoop op de voedingsspanning van de pic en draai eens aan de encoder ...

Op 8 juli 2011 19:07:10 schreef free_electron:
zodra je de interrupt handler binnevalt moet je de interrupt disablen.. waar gebeurt dat in je code.

Bij een PIC zijn de interrupts automatisch disabled, enablen gebeurt met de retfie instructie.

Ik ben niet zo'n kei in C, maar test je nu interrupt on change?
Dat betekent dat portB.0, B.1, B.2 of B.3 oorzaak van de interrupt is. Wat heb je aan de poorten zitten die niet de interrupt genereren? Zijn die zwevend?

edit//
sorry heb het mis. ik zie dat je de INT op poortB.0 pakt. Iets te vroeg gereageerd.

[Bericht gewijzigd door DIY op (18%)]

Op 8 juli 2011 19:07:10 schreef free_electron:
ben je zeker dat de logische nieveaus niet boven de voeding van de pic uit komen ?

zet eens een scoop op de voedingsspanning van de pic en draai eens aan de encoder ...

Yup, scoop ziet nergens wat boven de 5V. Niet op de voeding en niet op de B0/INT poot. Ik zie zelf niks en ik kan er ook niet op triggeren. Zou ook erg sterk zijn, aangezien alles uit een enkele 7805 gevoed word vanuit 3 lion cellen.

@DIY: de INT/B0 staat los van de andere poort B interrupts. Verder word de rest van poort B gebruikt voor het aansturen van een HD44780 display. Alle poten van poort B zijn dus benut, behalve B7.

Hier is het schema, hoeven we niet zo te blijven gokken: http://dl.dropbox.com/u/699251/schema%20gps%20logger.png

Hoe staan die 100nF condensatoren (C8 en C9) daar aan de encoder?
Die staan parallel aan de weerstanden. Ik zie daar het nut niet van in. Ik zou wel kunnen denken dat je telkens als je aan de encoder draait, je daarmee de 5V kortstondig eens kortsluit doordat de 100nF condensator in ongeladen toestand een kortsluiting is.

Die weerstand is een pulldown weerstand om te voorkomen dat die poten wat staan te zweven. Die 100nF zit er om de dender van de encoder op te vangen.

Die 100nF zit toch zo vol? De hele schakeling word bij de voeding gebufferd via een 220uF elco.

[Bericht gewijzigd door TheCrazyInventor op (11%)]

Die C8 en C9 zijn k*t zo. Je zet inderdaad een lege C van 100nF op je voeding. Je voeding stuitert dus even. Wat er gebeurt is erg afhankelijk van je PCB layout, of je al dan niet een BOD hebt (geen idee of die dingen van microchip daaraan doen) en het feit dat dat spul van microchip ook relatief trigger-happy is op de reset.

Dat je die 7805 aan de uitgang ontkoppeld hebt met 100nF is leuk, maar schiet natuurlijk niet zo op. Die 100μF is te traag. de voeding van dat microchip ding lijkt ook niet separaat ontkoppeld te zijn. Per saldo zal het mij niet verbazen dat je - afhankelijk van je layout - behoorlijke spikes op de voeding hebt.

Door 5Ω in serie te zetten, wordt de dip zover afgezwakt dat je er in elk geval geen reset meer uit haalt.

Wat geeft het als je héél traag aan je rotary encoder draaid? Als het aan het feit ligt dat de interrupts veel te snel achter elkaar komen en zo een stack overflow genereren, zou dit nu niet mogen gebeuren.
Anders de rotaty encoder eens vervangen door 2 drukknoppen (fase 1 en fase 2) en de encoder manueel simuleren.

Toen ik dit alles las, was mijn eerste gedacht ook dat het om een stack overflow ging door het denderen van de contacten. Heb je je code al eens gesimuleerd? PIC Simulator IDE van Oshonsoft is zeker een aanrader om je code te debuggen.