PIC program runs fine on debugger, but not solo in part

[Bob D.]

I'm working on a program for the PIC18F27Q10 with MPLAB X IDE v5.50 and the PICkit 4. It's running fine on the debugger, but not solo in the part. I did a production build, and programmed the part with it. I can tell the program is running because it is responding to a button push and lighting an LED when it should. I think the problem is that TMR1 is not counting pulses on RC0, but again it's working in debugger mode.

I wonder if the extra code the debugger adds in, is initializing something I missed in the main code. Or maybe the debugger is giving the chip a good reset, where my hardware isn't?

Any thoughts on this?

Bob D.

 

[Bob D.]

Out of desperation, I started playing with the configuration bits and stumbled onto the solution. I set PWRTE from OFF to ON, and the part is now running correctly without the debugger. (#pragma config PWRTE = ON) This enables some kind of reset delay. I must confess that I don't understand what half the configuration bits do. I find the documentation is a bit sketchy on a lot of things.

Bob D.

 

[nsaspook]

Normally there is a little RC delay on the MCLR pin to allow for VDD and clocking circuits to settle. Make sure the MCLR has a proper reset circuit on it.

https://ww1.microchip.com/downloads/en/AppNotes/00000607C.pdf

 

[Nigel Goodwin]

I was thinking of this thread earlier

I was working on my Li-Ion charging routines, using buck/boost hardware - and I choose to unplug my PK4 from the board. Immediately things started to go 'funny', and I wondered what I'd done to the code to 'break it' as it was fine previously. The PK4 is set to power the PIC during programming, and afterwards - as sometimes I work without the buck/boost board been powered.

Anyway, I was fairly busy, so I thought - I'll look at it later, and check that thread on the forum.

One of the things I was 'busy' with was assembling another buck/boost board - so once finished, I hooked it to a different (but identical PIC board) and a different battery, and all worked fine. So I thought I'd try unplugging the PK4 - and all still worked fine.

After a couple of seconds I realised why - the batteries were different - the failing one was a 16.8V 4S1P pack, and the working one just a 4.2V 1S1P pack - in both cases charging current was set to 1.040A. So the 16.8V battery was taking a LOT more current from the supply feeding it, and obviously hitting the current limit it was set to - and the resultant dip was resetting the PIC - leaving the PK4 connected kept the PIC supply from dipping, so no issues.

So a slightly different reason, but a very similar situation to the one in this thread - so PSU is well worth checking in such cases.