Hot!PIC32MZ will not reset

Author
dshepperd
New Member
  • Total Posts : 13
  • Reward points : 0
  • Joined: 2017/02/12 10:56:58
  • Location: 0
  • Status: offline
2017/09/13 12:14:24 (permalink)
0

PIC32MZ will not reset

I am using a PIC32MZ2048EFG144. Sometimes (a little less than 50% of the time) it will not reset from either a software reset or a watchdog timeout. I can't tell what it is trying to do after the reset; it's tough to debug at that point. I can verify it gets to the software reset and I can verify it will get a watchdog timeout. Then nothing. I can reset the processor with an external MCLR and that always works. Just the internally produced reset seems to be having trouble, but only sometimes.
 
Any ideas?
 
Thanks in advance.
 
 
#1

8 Replies Related Threads

    qhb
    Superb Member
    • Total Posts : 6257
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: PIC32MZ will not reset 2017/09/13 13:14:59 (permalink)
    3 (1)
    What software are you running?
    Something produced with Harmony, or standalone?
    It sounds a bit like the startup code is making some incorrect assumption about register values on startup.
     
    #2
    dshepperd
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2017/02/12 10:56:58
    • Location: 0
    • Status: offline
    Re: PIC32MZ will not reset 2017/09/13 14:39:46 (permalink)
    0
    It is via Harmony.
     
    I guess the question is more to the tune of what is different exactly between a hardware reset, as in an assert of MCLR, and a software induced reset be it a watchdog timeout, deadman timeout or an actual software reset?
     
    The assert of MCLR wakes up the processor every time no matter what. Letting the watchdog timeout only sometimes works. I'm certain the MCU is actually reset when the watchdog kicks so it has to be failing in the startup code somehow. What puzzles me is pressing the reset button makes it execute the exact same startup code in either case (as far as I know) and that always works.
     
    I'm not sure the relevant Harmony source code is available to see exactly what the startup code does. I will browse around for a while. I'm inclined to think they only gave us .o and .a files for any of this stuff. I wonder if the startup code is looking at a bit in a register to see where it came from and that makes it do something I don't want it to do? That bit is set/clear only on a hardware reset which makes the startup code happy. If I knew what bit that was, I might be able to set/clear it before doing the soft reset.
    #3
    Michael.W.Mann
    Super Member
    • Total Posts : 235
    • Reward points : 0
    • Joined: 2011/01/24 09:58:24
    • Location: Chandler, Arizona
    • Status: offline
    Re: PIC32MZ will not reset 2017/09/13 14:50:39 (permalink)
    3 (1)
    The RCONbits structure, from the devices SFR .h file, can give you insight as to what the device is reporting at bootup.  You can dump this out a USART at bootup and understand what is happening.
     
    typedef union {
    struct {
    unsigned POR:1;
    unsigned BOR:1;
    unsigned IDLE:1;
    unsigned SLEEP:1;
    unsigned WDTO:1;
    unsigned DMTO:1;
    unsigned SWR:1;
    unsigned EXTR:1;
    unsigned :1;
    unsigned CMR:1;
    unsigned DPSLP:1;
    unsigned :5;
    unsigned VBAT:1;
    unsigned VBPOR:1;
    unsigned :8;
    unsigned BCFGFAIL:1;
    unsigned BCFGERR:1;
    unsigned :1;
    unsigned HVDCORE:1;
    };
    struct {
    unsigned :29;
    unsigned HVD1V8R:1;
    };
    } __RCONbits_t;

    Michael W. Mann
    Principal Applications Engineer
    MCU32 Applications, Microchip
    #4
    dshepperd
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2017/02/12 10:56:58
    • Location: 0
    • Status: offline
    Re: PIC32MZ will not reset 2017/09/13 16:09:31 (permalink)
    0
    Thanks, I think it's a Catch-22. And, yes, I've already been dumping numerous registers, RCON among them along with some special memory during the boot process just to see what they are and were. However...
     
    It won't start, so none of my code runs so I can't see why it isn't running (doesn't even make it to main()).
    I press reset after which it runs perfectly and the RCON register has a single bit set, bit 0, as expected with no history.
     
    BTW, when it does work, either bit 4 is set because it was reset by a WDT or bit 6 is set because it was reset by a SWR, just as it is supposed to. When it doesn't work, who knows what bits are set.
     
    I think what I have to do is grab control at the start, at BFC00000, before it does anything at all, stash away the contents of particular suspect registers in a FIFO in SRAM (not bss) then resume execution with the Harmony code. If it hangs, I can press reset and it will do that same thing again but continue to run. Then I can dump  the contents of the FIFO to see what might be different between the two events.
     
    Which one or more of those zillions of registers might be causing me this trouble? Maybe I just punt and put all the registers in a FIFO, if I can find the room, then do a diff. I wonder if that will show me anything.
    #5
    aschen0866
    Super Member
    • Total Posts : 4175
    • Reward points : 0
    • Joined: 2006/01/08 22:18:32
    • Location: San Diego
    • Status: offline
    Re: PIC32MZ will not reset 2017/09/14 08:15:59 (permalink)
    3 (1)
    _on_reset() is a weak function where you can inject some simple C code right after reset. _on_bootstrap() is another weak function where you can inject code after C startup but before main(). 
     
    I would try to see if there is an available port pin where you can set it low in _on_reset() and then set it high in _on_bootstrap(). If you can see a pulse on your scope, then the C startup code must have run successfully.
     
    Do you have all the exception handlers implemented? Typically if the code hits an exception while running the startup module, it will hit _bootstrap_exception_handler(). If it is not implemented, I believe the default is a reset anyway.
     
    #6
    dshepperd
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2017/02/12 10:56:58
    • Location: 0
    • Status: offline
    Re: PIC32MZ will not reset 2017/09/14 13:51:18 (permalink)
    0
    What I am trying to do is get a live update working. Sometimes it works. Sometimes it doesn't.
     
    My FIFO scheme seems to have highlighted a potential failure. The OSCCON register, contrary to what it says in the datasheet, evidently is not always being set from the config bits on an WDT or SWR reset. Sometimes it is and sometimes it isn't. A POR or EXTR reset evidently always does set the OSCCON register to the bits from the config flags. Maybe it is sometimes failing to read the config bits properly on a WDT or SWR just after they have been freshly written?
     
    FYI: When it hangs, the OSCCON register is set to 00206108 within a few instructions of beginning execution at BFC00000. That value looks illegitimate to me. After a POR or EXTR reset, the OSCCON register starts as 00201120. In either case my config flags are:
     
    3:C7FF0000 2:FFF9B198 1:5F6BFCB9 0:FFFFF7D7 (NOTE: after a fresh IDE download, config 0 is FFFFF7D3 and it is recorded as POR).
     
    I stuff those config bits in the FIFO too at every boot just to see they are what they are supposed to be and they always show the same values.
     
    My next attempt is to just smack the OSCCON register to 00201120 as the very first thing at startup before letting it do anything else.
     
    Yesterday just after I got the FIFO code installed and working, it performed 10 live updates in a row without hanging. I gave up for the day. I thought maybe it was a case of "A watched pot". This morning it hung on the second attempt. It must just be a bad luck or random thing.
    #7
    dshepperd
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2017/02/12 10:56:58
    • Location: 0
    • Status: offline
    Re: PIC32MZ will not reset 2017/09/15 20:51:08 (permalink)
    0
    I might have stumbled upon the cause of the problem. I will know for certain after much more testing.
     
    My hardware uses an external oscillator routed through the PLL (NOS/COS == 2). The external oscillator can be turned off with an output (to save battery while sleeping) and I'm pretty certain an MCU reset, since it clears all the LAT pins, turns that device off. It seems the processor can recover from that event by automatically switching to the FRC once it notices there is no clock but this must work only sometimes? I can catch it starting up with the COS bits in the OSCCON register having a value of 2 which seems pretty odd to me. My FNOS config bit was set to SPLL (value of 1) by default by Harmony and I didn't bother to change it so I'd expect it to always start with a COS of 1. And indeed, when it starts with a COS of 1 it always works. When it started with a COS of two it tended to hang (but not always; oddly, it often wasn't a COS of even 2 but of 6, an illegal value). I still don't know what it is doing when it hangs; I couldn't figure that out. It did always startup but it didn't get very far. It might have immediately caught an exception (within a few instructions at startup), but I was unable to catch and record it.
     
    So my fixes, if one were to call them that, is to immediately fix the OSCCON register contents at startup (make sure the clock is set to FRC [value==0]) no matter what the current value is, hoping it runs long enough to do that chore. Set the FNOS config option to 0 to make sure it starts wanting the FRC at boot. And, for now, make sure to switch the clock to FRC before issuing the software reset. So far, that seems to have made it work. I'll need to run it a couple hundred times to be certain since it has worked for a string of 10 times once before.
     
    The application does the mechanics of switching from the internal to external clock later in the startup sequence.
     
    I am going to revisit the notion of using an external oscillator at all. The internal PLL is probably plenty good enough for my application even though it might not be quite as accurate. Recovering from a reset either hardware or software is pretty important for my application. Sometimes even an MCLR wouldn't wake it up; only an actual power cycle would do it. It might be safer to only use internal clocks.
     
    Not ready to call this solved just yet. But I think I'm getting closer.
    #8
    RISC
    Super Member
    • Total Posts : 4631
    • Reward points : 0
    • Status: offline
    Re: PIC32MZ will not reset 2017/09/16 05:02:12 (permalink)
    0
    Hi,
    I suggest that you implement a PIC32 exception handler. It will directly tell you what was the cause of the reset and it can even tell you the line of code which generated the reset.
    PIC32 core has a register called EPC which stores the address of the instruction which generated an exception.
    By looking at disassembly listing you can easily trace back to the C source line ;=)
    There is indeed a mechanism to switch from external oscillator to internal oscillator, but this mechanism can be controlled by the configuration bits (use it or not). In general it is best to use it just in case something goes wrong with the external clock / XTAL so that the CPU can recover from this condition
    Regards
    #9
    Jump to:
    © 2017 APG vNext Commercial Version 4.5