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

Data Protection (Fuse fault) reset on PIC18LF27K40

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



Joined: 25 Aug 2004
Posts: 66

View user's profile Send private message

Data Protection (Fuse fault) reset on PIC18LF27K40
PostPosted: Tue Nov 27, 2018 12:49 am     Reply with quote

Hi all,

I'm testing a design with a PIC18LF27K40 in the debugger (MPLAB-X/RealICE) from the cof file.
Every so often I am observing what appears to a processor reset but I'm not sure what is triggering it.

The debugger is stopping at PC:0. I can see certain SFRs have been reset (e.g. TRISx), while others remain unchanged. This is normal for non-POR/BOR resets, so it does appear to be a real reset and not simply a jump to 0. Stack pointer is 0 and no breakpoint was triggered near the top of memory to detect wrap around.

The problem is that PCON0 remains unchanged at 0x3F (the value written when inspecting the reset cause the previous time). According to the datasheet (Table 8-3. Reset Condition for Special Registers), the only reset that jumps to the reset vector but doesn't change PCON0 at all is 'Data Protection (Fuse fault)'. There is no information in the datasheet (or that I can find on the web) as to what this reset type actually is.

So can anyone enlighten me as to what this reset type is and what causes it? Or is there another scenario which leads to the same set of observations?

My next step will be to try and reproduce it outside of the debugger.

Cheers, Ross
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Nov 27, 2018 1:28 am     Reply with quote

You could simply be getting a jump/call to address 0. If (for instance),
something pushes 0 to the stack, and then does a return, you will arrive at
address 0, with no change to the PCON0 register. The debugger automatically
stops at address 0, so this would still give the same behaviour....

You would only get the data protection error, if (for example) you have write
protect enabled on some or all of the ROM, and then attempt to write to this.

Post your fuses.
RossJ



Joined: 25 Aug 2004
Posts: 66

View user's profile Send private message

PostPosted: Tue Nov 27, 2018 8:32 am     Reply with quote

Ttelmah,

I considered a jump to zero rather than a reset. However, as outlined in my original post, there are several clear signs that a true reset has occur. For example, the TRISx registers are all reset to 0xFF, the stack pointer is zero, the reference clock output module has been reset, etc. Too many things are reset to just be coincidence.

Code:
Configuration Fuses:
   Word  1: DFEC   NOEXTOSC RSTOSC_HFINTRC_1MHZ NOCLKOUT CKS NOFCMEN
   Word  2: D73F   MCLR NOPUT NOLPBOR NOBROWNOUT BORV24 ZCDDIS NOPPS1WAY STVREN DEBUG NOXINST
   Word  3: C68A   WDT32768 NOWDT WDTWIN_100% WDTCLK_LFINTRC
   Word  4: FFFF   NOWRT NOWRTC NOWRTB NOWRTD SCANE LVP
   Word  5: FFFF   NOPROTECT NOCPD
   Word  6: FFFF   NOEBTR NOEBTRB


Do you have any idea what 'Data Protection (Fuse fault)' reset might relate to (assuming it is the cause of the reset)? Is this the fuses themselves that are the problem or some data memory that a fuse is protecting? If the later, what memory?

My application does write to EEPROM and a section of program flash well above the actual program (18000-1FFFF). I've reviewed and tested that part of the code and it is functionally correct. It doesn't seem likely that there are stray writes into memory somewhere it shouldn't.

/Ross
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Nov 27, 2018 9:07 am     Reply with quote

Good point.

I notice you have LVP enabled. If this is enabled, noise on the ICSPCLK line,
can cause it to think it is trying to go into a program mode, and this can result
in an unexpected boot behaviour. Are you really using LVP?. Very few
programmers do.
I notice you also have SCANE enabled. This allows the CRC generator to scan
the program memory. Doubt if you need this?.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Nov 27, 2018 9:38 am     Reply with quote

I see you have MCLR enabled. Be sure you've got a good proper pullup on it !
Also NOPUT. I always PUT. That extra few millseconds of 'startup' time really doesn't cost anything yet helps to ensure the PIC gets a good, solid start.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Nov 27, 2018 9:49 am     Reply with quote

Since he has LVP enabled, a 'low' on MCLR, risks being seen as the start of programming, unless there is some pullup on ICSPCLK/ICSPDAT. If he has some form of reset circuit on the MCLR, then 'danger'....
One or the other of the ICSP pins should have a pullup on it.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Nov 27, 2018 11:47 am     Reply with quote

As a further comment, enable the BROWNOUT fuse, and see if anything changes. It is possible to get a physical brownout, which does not occur for long enough to fully trigger the reset hardware. The brownout fuse should mean that the brownout reset bit gets set when this happens.
RossJ



Joined: 25 Aug 2004
Posts: 66

View user's profile Send private message

PostPosted: Wed Nov 28, 2018 3:15 am     Reply with quote

Thanks all for the suggestions.

First up, I've found a possible explanation as to how a reset may occur that doesn't change the PCON0 bits. Manually resetting the PIC via the MPLAB-X debug toolbar does just that. A true reset occurs but doesn't identify as any particular type of reset (probably by design). This doesn't explain WHY the resets occur, but does hint that the debugger may be causing them. I ran the circuit overnight without the debugger, and no resets occurred.

Regarding the points made about the fuse settings...

    1. I am using LVP (partly to avoid exposing the rest of the circuit to Vpp and also because it's the only method supported on the 18J chips I also use). My circuit has a strong (10K) pull-up on MCLR and the MCLR/PGC/PGD connect only to a Tag-Connect header a few mm away (no other components). My circuit has a very low power consumption and would likely not prevent Vpp from raising the main supply rail. I've not included additional isolation components.

    2. As there is no circuit to drive MCLR low and a 10K pull-up, the risk of a glitch keeping MCLR low for long enough (hundreds of us) and for the correct 32 bit pattern to clock in on PGC/PGD due to noise... seems extremely minimal. The point about preventing PGC/PGD from floating (esp. if MCLR can be driven low) is a good one and something I hadn't previously considered. I'd only considered driving these pins low during execution, which doesn't help while held in reset. I'll keep it in mind in future.

    3. SCANE is enabled as I verify (CRC) the code integrity at boot up. I may use the PMD module to disable the scanner (and other unused modules), but will leave this until the end. I imagine the savings are marginal and I'm not chasing nAs.

    4. PUT is only disabled because of debugger restrictions. It is certainly enabled in the production build.

    5. VERY GOOD POINT about enabling BOR. I haven't currently enabled it because the compiler is missing a fuse symbol for the voltage I wish to use. But I can certainly use another value for now. I normally would have BOR enabled, this was an oversight on my part (brownouts are always an excellent candidate for unexplained resets). I'll enable it and see if things improve.

I'll let you know how things progress.

/Ross

Question p.s. Any idea what a 'Data Protection (Fuse fault)' reset might be? Question
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Nov 28, 2018 5:31 am     Reply with quote

Re 2.

You don't have to generate the sequence. The sequence is needed to actually
make programming happen, but it 'enters' the start of the programming
behaviour as soon as the MCLR/ICSPCLK initial pattern is seen. It then sits
waiting for the 'unlock' pattern, but is now out of the normal code execution
path.
I've seen chips give an 'unexplained' restart, when this happens, and then the
unlock is not seen....

As I said, you get this restart, if you attempt to write to code protected memory.
RossJ



Joined: 25 Aug 2004
Posts: 66

View user's profile Send private message

PostPosted: Sun Dec 02, 2018 6:16 pm     Reply with quote

Thanks Ttelmah. Good point.

After making a few changes (enabling BOR and improving the connections to the battery), I've not observed the spurious/anonymous reset since. I also only saw it with the debugger. I was also using a dodgy clip lead from the battery (the wire was only crimped onto the clip and not actually soldered... making a poor and unreliable connection -- something I'll need to fix in my lead collection). Possibly the lead caused the reset but the way the debugger interacted with it and the absence of BOR, lead to no PCON0 bits being changed.

So all good now... and a little wiser.

Still don't know what a 'Data Protection (Fuse fault)' reset is though. I may have to ask over on the Microchip forum.

Cheers, Ross
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Dec 03, 2018 1:45 am     Reply with quote

Don't get me wrong, but you are not getting a data protection (fuse fault)
reset.

You decided that this was what you were getting, since it is the only reset on
your chip that leaves PCON0 unchanged. However what you were actually
having was a debugger communication issue, that resulted in the chip
resetting with PCON0 unchanged.....
RossJ



Joined: 25 Aug 2004
Posts: 66

View user's profile Send private message

PostPosted: Mon Dec 03, 2018 3:09 am     Reply with quote

I totally agree!

I always expected there to be more than one way to reach this 'non-indication' (no flags set/cleared). As you say, the Data Protection (Fuse Fault) is the only scenario mentioned in the datasheet, but I have also reproduced the same behavior with the MPLAB-X toolbar reset button. The later clearly makes more sense, especially since I have only observed the problem in the debugger.

In my last post, I only mentioned the Data Protection (Fuse Fault) because I still don't know what it is or even if it can be generated by this part. It may even be a documentation error. It helps to know what causes every type of reset in order to avoid them. And I'm curious.

Thanks for the help (and prompt responses).
/Ross
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