PIC18 - reset in middle of running code

[richcj10]

Hi,

I have had Atmega's lock up on me but never reset while executing code. Any ideas?
P.S.- WDT disabled, running board off of Power supply.

Thanks,

Rick

[AndyC_772]

A few obvious things to check:

- do you have a pull-up resistor between MCLR and VCC?
- do you have decoupling caps on the power & ground pins, physically located right next to the pins and on very short leads?
- what's the brown-out voltage set to (#pragma config BORV)? Is it anywhere close to your VCC voltage?
- where's the clock coming from, is it an external clock or the internal RC oscillator / HSPLL?

What's the code doing? Is it possible it's just a software bug writing over a pointer or something and causing a crash?

[AlphZeta]

Also, if the power supply is shared with some inductive components (e.g. motors), this tend to happen quite a bit if the decoupling and filtering of the power supply is not sufficient.

[richcj10]

It is not a power issue. I have checked it with a scope. No inductive loads attached to the device.
It works for hours and then reboots into a loop that continues to reboot. I haven't looked at the Brown out but it doesn't seam likely that it would be causing this. 

[Psi]

Have you tried another chip?
That will prove if its a software issue or a faulty IC

Are you doing anything complex with pointers?

Are you using a bootloader?

Using the EEPROM values for anything? especially eeprom address 0 ?

[MikeK]

I don't know about AVR, but PICs have the ability to determine the source of the reset.  If AVR does you could add this to your program.

[joelby]

Yes, you could try logging the value of RCON at power. It might help you determine what caused the reset.

I thought there might also be an illegal instruction/divide by zero trap or interrupt but I can't actually see any evidence of such a thing on a PIC18 with a casual glance.

[richcj10]

This is a PIC, How would you track a reset?

Thanks,

Rick

[richcj10]

It has a External EEPROM but it is not using it when reset normally occurs...

[UPI]

Have you tried a much simpler program to see if it still locks up? If it does not, you could then add the more complex portions until it starts locking up again.

Divide and conquer.

[richcj10]

Here is the code I am running:

Code: [Select]


program MyProject

dim cnt, prevcount, prevcount1 as word         ' Define variable cnt


sub procedure interrupt ' Define interrupt subprocedure
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
end sub                 ' End of interrupt routine

main:                   ' Start of program
TRISA.3 = 1     'Serial I/O
TRISA.5 = 0     'Serial I/O
Soft_UART_Init(PORTA, 5, 3, 2400, 0)
TRISC.0 = 0
PORTC.0 = 1             ' Initial value of PORTB bits
TRISC.7 = 0             ' PORTB pins are configured as outputs
T1CON = 1               ' Set timer TMR1
PIR1.TMR1IF = 0         ' Reset bit TMR1IF
TMR1H = 0x80            ' Set initial value for timer TMR1
TMR1L = 0x00
PIE1.TMR1IE = 1         ' Enable interrupt on overflow
INTCON = 0xC0           ' Enable interrupt (bits GIE and PEIE)
Soft_UART_Write("D")
Soft_UART_Write("O")
Soft_UART_Write("N")
Soft_UART_Write("E")
Soft_UART_Write(10)
Soft_UART_Write(13)

while 1                 ' Endless loop
  if ((cnt - prevcount) > 1400 ) then        ' Rtn 1 - chg check
    prevcount = cnt
    'PORTC.0 = NOT PORTC.0
    Soft_UART_Write("C")
    Soft_UART_Write(10)
    Soft_UART_Write(13)
  end if
  if ((cnt - prevcount1) > 4200 ) then        ' Rtn 1 - chg check
    prevcount1 = cnt
    'PORTC.0 = NOT PORTC.0
    Soft_UART_Write("D")
    Soft_UART_Write(10)
    Soft_UART_Write(13)
  end if
wend
end.                    ' End of program



[Psi]

Code: [Select]

cnt = cnt+1             ' Interrupt causes cnt to be incremented by 1


I had someone tell me off for using a variable named "cnt". Apparently it's offensive. 

I laughed pretty hard, which wasn't the best plan since they were serious. 

[richcj10]

lol

[mazurov]

You may want to explicitly define a handler for each interrupt in this device with while(1) inside. IIRC default interrupt handlers all jump to zero.

[richcj10]

You may want to explicitly define a handler for each interrupt in this device with while(1) inside. IIRC default interrupt handlers all jump to zero.

I hope I don't sound too stupid but what do you mean by this?

[Psi]

I don't know PICs, but i think he means if your code is triggering an interrupt which has no handler it will reboot the micro

[mazurov]

I looked at PIC18 datasheet - there are only two interrupt vectors, one for high and another for low priority. Do this: write an ISR for each one and place a breakpoint inside each ISR. This way you can see if ISR gets called accidentally. You need to work around the timer code which is already in the ISR.

[Skimask]

There's a register in the PIC that you can look at AFTER the reset to figure out what caused the reset itself.
But, since we don't know which PIC, and don't know if that is actually the full code, kinda hard to say.
A bit more, ok, a lot more information, might be quite a bit more helpful, like maybe a schematic, config bits, the list goes on.
I've been using PIC18's of all types for quite awhile and don't remember any cases of "random resets" that I haven't been able to eventually explain...usually thru my own mistakes.

[AlfBaz]

Far out man...

What pic18 are you using
What compiler are you using
What incarnation of basic code is that
Are you running this on a dev board or something you made
Do you have schematics
Where do your variables ever get initialised
Is the interrupt code placed at the proper inturrupt vector
The cnt variable is a word which means to process it in main it will take several interruptable cycles which makes it quite possible that the hibyte (required for values greater than 255) never gets touched
etc, etc...

[richcj10]

It is a PIC18F47J13
I cant show the schematic because of a NDA but it is hooked up correctly and functional.
The IDE is Mikro Basic Pro
I have used this IDE in the past with no problems on this board.

[AlfBaz]

May i suggest that for the time being, do away with the interrupt and just pole the interrupt flag

instead of
while 1
blah
blah

while NOT PIR1.TMR1IF
blah
blah

and previous to that just comment out any code that enables interrupts

The interrupt flag will be set regardles, when the timer overflows, all you have to do in the while loop is reset it

[mamalala]

A few things. You have no setup for the OSCCON registers to select which oscillator/clock source to use. How does the soft-uart know what the actual clock rate is?

Speaking of soft-uart, how does it time the bits it sends? Using a timer also? And if so, which one? There is the possibility of a conflict there. Or does it use an interrupt? If so, how does your compiler handle that?

Then, you use "cnt" in the interrupt as well as the main code. However, i see no provisions to tell the compiler about it. Using a variable shared between interrupt and other code requires special handling of the variable. Plus, you have it defined as word, which requires multiple accesses to it. Imagine that your variable is 0xFFFF. Now you do the first check. The substract operation will load one byte of the variable, substract one by of the other one, then does the same with the second byte plus the proper status bit for over/underflow carry of the previous operation.

Now you have the problem that during this the IRQ can kick in and modify the variable. Which means that the result of the operation will be just wrong.

A similar condition can happen when you load the other variables with the contents of "cnt". It will take 4 clock cycles to do that. It can either use two MOVFF operations, each using two clock cycles, or it can use two MOVF/MOVWF combinations, again using two cycles for each combination. Right in the middle of that it could happen that the IRQ changes the cnt variable now.

Depending on how the compiler generates the interrupt code there could also be problems with the call- and variable-stack save/restore. The PIC18 chips have two interrupt levels, low and high priority. The high priority can save/restore some of that stuff automatically, while for the low priority it needs to be done by hand. If you now call functions, and a IRQ happens during that, there is a chance of messing up any of these stacks, leading to corrupted data or return stack if the IRQ is done.

Greetings,

Chris

Edit: Forgot to explain that substraction thing a bit better. As said, lets assume cnt is 0xFFFF. The other variable is 0xF000. You would expect the result to be 0x0FFF. But what happens is that first the low byte is substracted, 0xFF - 0x00 = 0xFF. Now the interrupt occurs, cnt becomes 0x0000 (since it overflows now). So on the high byte part of the substract, you now would have 0x00 - 0xF0 instead of the 0xFF - 0xF0.

[AlfBaz]

Just looked at the data sheet the register to interigate after a reset is RCON

[Kremmen]

The embedded peripherals in a MCU are usually able to generate an interrupt when something interesting happens. Say a USART receives an incoming data byte, it then generates an interrupt to flag the event. The built-in interrupt controlled (another embedded periperal) does what the name says- interrupts the flow of program and causes a jump to the point in program space specified for that interrupt. The details vary by maker and chip type, but the idea is always the same.
Often the jump point - if nothing is specified - is address zero by default. And often jumping to zero address causes the program to re-initialize from start. That may be what you are seeing.
Remedies:

easy: run with all interrupts disabled. There is always a register bit somewhere that controls global interrupt enable/disable. Once disabled, no interrupts will be generated. But then you won't be able to use any of them either.

proper: See that interrupt generation from all embedded peripherals is set in the proper way, either on or off accordingly to whether the interrupts are desired and properly specified. For every enabled interrupt, you must provide the interrupt handler. This is a piece of code that is specifically tied to the particular interrupt by using a mechanism provided for this purpose in the programming language. Interrupt handlers must be written in a specific way but otherwise they are just procedures like any other. The compiler/linker creates the correct jump instructions once it has sufficient info to associate your procedure with a particular interrupt type.

[ptricks]

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

[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.

[richcj10]

fix and no change...

[amyk]

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?

That is fine but you need to read the value after a reset, since that's when the STKFUL bit will be set if the stack overflow.

[mamalala]

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?

That is fine but you need to read the value after a reset, since that's when the STKFUL bit will be set if the stack overflow.

But then the problem is: what does the compiler generate as startup-code in it's runtime library. It might well be that it already overwrites all that stuff before passing control over to the main program.

Greetings,

Chris

[richcj10]

I don't think that is true. When I program the MCU, I get  00111100. On a normal reboot I don't. This tells me the compiler is not touching this.

I have added notifications when a sup fcn runs. It looks when a reset condition occurs it runs the first three sub fcn's in quick repetitiveness about 5 times. I don't know how the code could do this?
 

[Niklas]

Do you have any spare pins? If you have, then you can try to add some debug signals that you can trigger on with an oscilloscope or logic analyzer.
- One I/O for a startup pulse that is also used as trigger for the oscilloscope.
- Other I/Os for separate functions

The oscilloscope should do a one shot trigger with the trigger point set to about 2 divisions from the right side of the display. By selecting the timebase right you can then get the history. Will the same function crash all the time or is it more random? Kind of oldschool but it works without to much penalty and without a debugger and its related code.

[darrylp]

Standard DOS output of serial data will be 13,10 rather than your 10,13.

Nothing to do with your problem, but end company might like this to follow standards.

[richcj10]

It was bad hardware. I replaced the PIC with a PIC18LF46K22 and it worked fine. go figure. 

[Niklas]

How can you rule out SW bugs so sure if you dont test it with another PIC of the same type? The K and J types are different and now also an LF type. It might be something that is not initiated correctly or an errata on one type of PIC.

[richcj10]

The layout of the board was for the PIC18LF46K22.
We had go to the PIC18F47J13 for more space. The bad part of this chip is it had the Vcore pin.
We had the pin bent up with a 10uF attached. I felt that this was causing issues.