Avoid brownout after PIC programming

[Marttyn]

Hi!
My program check the restart cause so it can resume program in case it was due to a brownout restart.
Programming the PIC (with PICKIT 4) cause the PIC to report a brownout restart just after programming.

Does anyone knows how to know if the brownout was caused because of programming, or if its a "real" brownout during program run?

This is giving me problems, because the circuit is connected to a terminal, and need to pass some test after programmed.
But this test are being "jumped", because the brownout restart dont trigger the terminal test routine

The circuit is being powered externally, so no real brownout is being produced i think.

Also being able to send some restart signal from the programmer would help.

Any idea?

[jeremiah]

Three things:
1. A lot of chips have errata explaining that they have problems reporting an accurate restart cause. Check your chips errata and see if this is the case.

2. Not all chips use a similar method of indicating the restart cause and CCS still tries to use the same method of parsing it for all chips. I would recommend reading the register directly and comparing that to the data sheet rather than rely on the CCS define

3. Getting the restart cause MUST be the first thing you do in your main. There are various things that can cause those bits to change as soon as you start executing code. If you are waiting until later to do so, move it to the first line of your main (not in a function call either).

[Ttelmah]

What programming environment are you using?.
CCS ICD with the Pickit driver, MPLAB, etc. etc..
I must admit when using ICSP, I always hardware reset afterwards.
Problem is that restart_cause detection is dependant on a pattern of
bits, that I'd not be at all surprised to see having unexpected values
after the chip is programmed....
The CCSLoad environment, does offer an option to reset the chip,
but not sure if this can be used with the Pickit driver.

[Marttyn]

Thanks!
Looked at the errata of 12F1840, but seems not to have problems with restart cause.
When checking STATUS and PCON register, first instruction of all, it also seems that a brownout occurred.
Although, as per the datasheet:

[Ttelmah]

Can you stick something like a scope on the supply line?.
Is there some possibility that you genuinely are getting a brownout
when the chip is being programmed?. How is power generated?.

[Marttyn]

During confinement will be difficult, but not impossible. I will try to check if a brownout is really happening.
But I'm powering the circuit from external power supply, so this should not be the case anyway.

[Ttelmah]

Yes, but just wondering if the behaviour when programming might trigger
a problem.
You have the chip sitting for a long time not actually 'running', but with the
supply 'on'. Pins floating?. Any possibility a peripheral starts up, and
draws exceptional power?. How are RA0 & RA1 actually connected?. Anything
else on these?.
You see where I am 'coming from'?.

[Marttyn]

As far as I'm able to check with a pocket oscilloscope and "hand probing" i don't see any real brownout.

From the multiple possibilities of a startup, its quite difficult to differentiate a POR from a BOR. Specially for all those "unchanged" and "unknowns" bits.

I'm getting this values at startup:
Status: 0x1C (0b 0001 1100)
PCON: 0x0E (0b 0000 1110)

Which kind of look like a BOR in the datasheet (page 64):
http://ww1.microchip.com/downloads/en/DeviceDoc/40001441F.pdf

PS: circuit is only PIC and a 24xx i2c external memory. Don't draw more than a few milliamps.

[Marttyn]

Ok, I'm giving up. I've found alternate solution. Not proud, but works.
My problem was that communication was not quite working after initialization. And the data sent over TX pin was corrupt, at least the first bytes.
I was trying to find a solution, because if brownout was detected, the program tried to resume before BOR.
Adding about 100uS delay after restart, TX serial communication can be sent without corruption.
I was trying to avoid the delay on a brownout with the restart_cause(). But i will have to deal with it.