CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Avoid brownout after PIC programming

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Marttyn



Joined: 06 Mar 2015
Posts: 28
Location: Spain

View user's profile Send private message Visit poster's website

Avoid brownout after PIC programming
PostPosted: Fri Mar 27, 2020 7:09 am     Reply with quote

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 Sad

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



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PostPosted: Fri Mar 27, 2020 9:48 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Mar 27, 2020 10:38 am     Reply with quote

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



Joined: 06 Mar 2015
Posts: 28
Location: Spain

View user's profile Send private message Visit poster's website

PostPosted: Mon Mar 30, 2020 2:50 am     Reply with quote

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:
Quote:
Upon exit of Programming mode, the device will
behave as if a POR had just occurred.

I'm using MPAB X. I was looking if there was an option to do the reset automatically after programming.
While programming it would be useful no to do it manually every time.
But while in production, i can not rely that the operator will remember to do the reset after programming from IPE.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Mar 30, 2020 3:02 am     Reply with quote

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



Joined: 06 Mar 2015
Posts: 28
Location: Spain

View user's profile Send private message Visit poster's website

PostPosted: Mon Mar 30, 2020 3:04 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Mar 30, 2020 3:11 am     Reply with quote

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



Joined: 06 Mar 2015
Posts: 28
Location: Spain

View user's profile Send private message Visit poster's website

PostPosted: Mon Mar 30, 2020 9:53 am     Reply with quote

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



Joined: 06 Mar 2015
Posts: 28
Location: Spain

View user's profile Send private message Visit poster's website

PostPosted: Mon Mar 30, 2020 12:29 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group