PIC18 - reset in middle of running code

[richcj10]

I ran the code today with it printing the value of RCON today.

I got this when it rebooted: 00111100
This tells me nothing other than maybe a BOR occurred.

Are you turning off the interrupts after the interrupt is triggered ? If not you can get into a situation where the interrupt is triggered, jumps to the sub routine and is triggered again , not allowing the code to progress further and causing an overflow in the variables.


sub procedure interrupt ' Define interrupt subprocedure
cnt = cnt+1             ' Interrupt causes cnt to be incremented by 1
PIR1.TMR1IF = 0         ' Reset bit TMR1IF

If the interrupt is triggered again you will increase cnt by one over and over until the routine passes the reset without it being triggered again.

I suggest changing it to

Code: [Select]

sub procedure interrupt ' Define interrupt subprocedure
PIE1.TMR1IE = 0 'Disable timer interrupt
cnt = cnt+1             ' Interrupt causes cnt to be incremented by 1
PIR1.TMR1IF = 0         ' Reset bit TMR1IF
TMR1H = 0x80            ' TMR1H and TMR1L timer registers are returned
TMR1L = 0x00            ' their initial values
PIE1.TMR1IE = 1 'Enable timer interrupt
end sub                 ' End of interrupt routine

I will try this...

[Jon Chandler]

I don't believe you've answered questions about the circuit except to say "it's right."

Two things often cause mysterious resets:

1. /MCLR not pulled up to Vdd with a 10k resistor.

2.  Lack of 0.1 µF bypass caps across power pins.

Also, be sure ALL power and ground pins are connected.

[AlfBaz]

...I got this when it rebooted: 00111100
This tells me nothing other than maybe a BOR occurred.
...

Thats the exact value to be expected after a Power On Reset (POR). Above each bit in the register description value you have X/X-n where n denotes the value after a POR. _POR and _BOR bits have to be SET immediately after a POR by your software for those bits to be meaningfull. If you read RCON after one of your "reboots" and they are still set then you know its a software issue, which is what I suspect is the isue here.

[richcj10]

I don't believe you've answered questions about the circuit except to say "it's right."

Two things often cause mysterious resets:

1. /MCLR not pulled up to Vdd with a 10k resistor.

2.  Lack of 0.1 µF bypass caps across power pins.

Also, be sure ALL power and ground pins are connected.

The hardware is fine, it actually has more capacitance on the  power pins than .1uf.

[AlfBaz]

The hardware is fine, it actually has more capacitance on the  power pins than .1uf.

There should at least be 1 0.1uf per Vdd pin.
Large caps provide bulk charge and are to slow to bolster the voltage for fast transient current demands on the power distribution system (PDS). Smaller caps placed very close to the power supply pins to reduce parasitic inductunce and therfore delays in current supply are a must for any high speed digital device.

Having said all that what you said could be that you have more than just 1 0.1uf cap on the supplies

[richcj10]

  The board has at each Vcc pin on the uC a .1uF and a 10uF cap.  Hence the comment that it has more than .1uF. 
At the AVCC pin I use a L/C circuit to filter out noise there.  (just encase you ask  )
I have been designing hardware for some time now and know a thing or two about uC hardware design.  (even in nosy environments like this board will be in)
Software on the other hand (as strong as I am with computer c programming) am unfamiliar with PIC's (i am a AVR guy) and there fcn. registers in general.

[alm]

There should at least be 1 0.1uf per Vdd pin.
Large caps provide bulk charge and are to slow to bolster the voltage for fast transient current demands on the power distribution system (PDS). Smaller caps placed very close to the power supply pins to reduce parasitic inductunce and therfore delays in current supply are a must for any high speed digital device.

Note that larger here mainly means physically larger (inductance) or higher K dielectric. A 1 uF X7R cap in 0805 shouldn't be any worse than a 100 nF X7R cap in the same package. A 0.1 uF electrolytic in a through-hole package will perform much worse.

The board has at each Vcc pin on the uC a .1uF and a 10uF cap.  Hence the comment that it has more than .1uF. 
At the AVCC pin I use a L/C circuit to filter out noise there.  (just encase you ask  )
I have been designing hardware for some time now and know a thing or two about uC hardware design.  (even in nosy environments like this board will be in)

Being less arrogant might get you farther. Having years of experience does not preclude you from making bonehead mistakes. The hardware may very well be OK, but don't exclude problems beforehand. This reminds me of a story I once heard about troubleshooting a steam engine. A bunch of senior engineers made a list of possible causes and a list of things that were definitely not responsible for the problem. A junior engineer was assigned to check each of the possible causes, and eventually found it was caused by something on the 'definitely not' list.

[JuKu]

I don't believe you've answered questions about the circuit except to say "it's right."

And the part keeps resetting...  ( Believing in something against empirical evidence is ...).

Wouldn't be the first uC with a bad solder joint or ESD damage on a critical pin.

[Skimask]

You've got the required caps on the Vcap/Vddcore pins?  (Datasheet section 2.4)
Is this the 18F27J13 or the 18LF27J13?

[richcj10]

it is the 18F27J13 with the VDDCore pin. I have 10uF ceramic cap on it.

[Skimask]

And .1uf's across the Avdd & Avcc pins?

[richcj10]

yes

[Psi]

I've not read the whole thread but at this point i'd probably do a binary search elimination analysis. (assuming you've already tried a replacement mcu)

Remove half the features in the code and retest for the fault.

If the fault is gone, go back to the code you removed and retest half of that.

If the fault is still there remove half of the remaining code/features and retest.

Rinse/repeat.

It's the quickest way to find the line/feature causing the problem (or at least the area involved in the problem).
For example you might find when you stop reading the ADC the problem goes away.

[richcj10]

Not a bad idea

[lewis]

Sounds like a brown-out reset or (less likely) stack over/underflow reset to me...

To get meaningful information out of the RCON register, you need to manually set the POR and BOR bits after checking the RCON register at boot-up.

Procedure is as follows: Power-on > check RCON register > RCON = 00111111

This way, when the PIC randomly reboots next time, checking the RCON register will tell you what's going on. If the POR and BOR bits are clear again, it's a power-on reset. If POR is set and BOR is clear, it's a brown-out reset (but only if you're using the internal voltage regulator for VDDCORE). See section 5.0 (RESET) in the datasheet, and specifically section 5.4.1. (Ref. the latest DS from Mchip's website).

It's also possible it's a stack overflow reset, although at 31 levels deep it's unlikely. I use MikroC, not MikcoB, but the library functions can sometimes use a lot of stack overhead, especially if interrupts are enabled. Look at the 'Functions Tree' section under View > Statistics in the compiler. You can see the function dependencies - ie how many calls within calls you have. Don't forget to add one for the interrupt routine.

Also, always read the errata. Very important! There's stuff in there about the EUSART and oscillator. A mis-configured oscillator/PLL could cause this. If you have an early chip revision you need to pay attention to every point listed. See http://ww1.microchip.com/downloads/en/DeviceDoc/80503e.pdf

You also need to check the interrupt routine is doing it's context saving correctly. You'll need to do this in the disassembly listing (View > Listing). I had a problem on an older version of MikroC where the interrupt routine was not saving context correctly (compiler issue). The PIC does hardware context saving in some circumstances, but might not. See datasheet page 138.

Also, on page 119 of the datasheet it says: NOTE - Do not use the MOVFF instruction to modify any of the Interrupt Control registers while any interrupt is enabled. Doing so may cause erratic microcontroller behavior. Check the disassembly listing to see if any of the INTCON, PIR or PIE registers are modified using this instruction.

Failing all that, plough through the disassembly listing to see if anything looks unusual. But if you're not familiar with the PIC architecture, that might be tricky.

Good luck!

[richcj10]

Thanks Lewis. I shall go over the this tonight. I am using a 16 Mhz crystal with no PLL. One thing I have learned is to look at the errata. Dave tought me that. 

[mamalala]

Software on the other hand (as strong as I am with computer c programming) <...snip...>

So strong that you have to use BASIC on that poor µC? (Hint: C is just fine for PIC's. Especially the PIC18 series, since that architecture is optimized to be used with C) For some project that allegedly is under some NDA even (meaning that you want us to help you without even showing what you are doing because of the supposedly big $$$ in it)?

Haha ...

Greetings,

Chris

[richcj10]

Software on the other hand (as strong as I am with computer c programming) <...snip...>

So strong that you have to use BASIC on that poor µC? (Hint: C is just fine for PIC's. Especially the PIC18 series, since that architecture is optimized to be used with C) For some project that allegedly is under some NDA even (meaning that you want us to help you without even showing what you are doing because of the supposedly big $$$ in it)?

Haha ...

Greetings,

Chris

My client wants the project done in basic.  He doesn't understand / like C.

[richcj10]

It is responding with 00111111 during serial resets.

[richcj10]

i have the code to a point that You can see it.
It is attached B/C it is too large.

[richcj10]

I did some testing with print outs of the code to tell me what was going on and here is what i found:

Code: [Select]


VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

?c

  VI

BK

BR

BK

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR


 63   

Boot Done

BR

VI

Bk

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI
VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR
VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR

VI

BR


 63   

Boot Done

BR

VI

Bk

VI

BR

VI

BR

VI

BR

VI

BR

VI




?c = charging
VI = vin fcn called
BR = Bat read
BK = call return susesful from charging code
Bk = call return susesful from time based int. code

If you take a look at a reboot (boot done)  you notice the that VI and BR are being called but they are not being called by the two places that they are normally being called at.  weird....
Now, I need to figure out why...

[notsob]

Perhaps try writing it in C and use a different compiler (ie mplab) just to eliminate the compiler you are using

[amyk]

To rule out a stack overflow check the STKFUL bit in the stack pointer after a reset. A POR will clear it, a stack full reset will set it.

[richcj10]

I am reading the reset and overflow like this:

Code: [Select]


rseting = RCON
rsetg = STKPTR
RCON = %00111111


I am getting a 0 back
When I read STKFUL ( I read it during the problem part of the code where it charges the battery)
I am getting back a 7 or  00000111
I don't think this is a problem?

[lewis]

i have the code to a point that You can see it.
It is attached B/C it is too large.

You have two instances of "rseting = RCON" in your code, get rid of the one under the init(). The second one reads RCON after you've written to it which overwrites your rseting variable with the overwritten value, not the original RCON value.