Data Protection (Fuse fault) reset on PIC18LF27K40

[RossJ]

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]

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]

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.

[Ttelmah]

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]

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]

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]

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]

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

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

[Ttelmah]

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]

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]

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]

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