RetroBSD

2.11BSD operating system for microcontrollers
It is currently Sun Oct 20, 2019 9:11 pm

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Watchdog problems
PostPosted: Sun Jul 20, 2014 10:09 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Serge, I'm having problems with the watchdog on the PIC32MX795, and I was wondering if you had any insight into it.

I am putting the chip into sleep mode (OSCCONSET=0x10) and enabling the watchdog (1.024 second delay), then using "wait" to go to sleep.

The chip NMIs and jumps to _reset, with RCON set to 0x18 as I would expect. I then "eret" as the manual tells me to, and my program carries on from where it went to sleep.

Then it gets back to the wait instruction again. It goes back to sleep, as it should, until the watchdog NMIs again. This time though when it jumps to _reset RCON is set to 0x10 instead of 0x18.

If I use idle mode instead of sleep it all works fine, with RCON always set to 0x14.

Have you ever heard of anything like this before?

My _reset vector looks like this:
Code:
_reset:
        la      k0, RCON        # Load address of RCON register

        lw      k1, 0(k0)       # Get contents of the register
        and     k1, k1, 0x18    # We are only interested in 0x18
        sub     k1, 0x18        # Subtract 0x18
        beqz    k1, _ret_nmi    # and if the result is 0 (i.e., equal to 0x18) then branch.

        lw      k1, 0(k0)       # Same again but looking for 0x14.
        and     k1, k1, 0x14
        sub     k1, 0x14
        beqz    k1, _ret_nmi
        nop

        la      k0, _startup
        jr      k0                      # Jump to startup code
        nop

_ret_nmi:
        lw      k1, 0(k0)
        and     k1, 0xFFE3
        sw      zero, 0(k0)
        eret

I need to re-write the _ret_nmi to use RCONCLR really to make it tidier. Just need to remember the order of the set/clr/inv offsets sometime...

Setting sleep mode and the watchdog is done like this:
Code:
    // Standard unlock sequence
    SYSKEY = 0x0;
    SYSKEY = 0xAA996655;
    SYSKEY = 0x556699AA;
    OSCCONSET = 0x10; // Enable sleep mode
    SYSKEY = 0x0;

    WDTCONSET = 1<<15; // Turn on

and I go to sleep with:
Code:
    WDTCONSET = 0x01; // Kick the dog!
    uint32_t i = disableInterrupts(); // We don't want any old interrupt waking us up
    asm volatile("wait");
    restoreInterrupts(i);

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: Watchdog problems
PostPosted: Sun Jul 20, 2014 10:52 pm 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA
Well, I never tried to enable SLEEP mode myself... But I would assume that on NMI exception the SLEEP mode gets disabled, and after "eret" it's not reenabled automatically by wait instruction. This can explain why on second NMI the bit RCON[3] is zero. I would propose to try to re-enable SLEEP mode after wait instruction (in a loop, I guess).


Top
 Profile  
 
 Post subject: Re: Watchdog problems
PostPosted: Sun Jul 20, 2014 11:22 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Already thought of that one and no, it makes no difference. Also if you think about it, it won't be doing that.

Sleep is OSCCON<4> set, then a wait instruction.
Idle is OSCCON<4> cleared, then a wait instruction.

So, if OSCCON<4> were being cleared, the wait would do an idle, not a sleep, in which case RCON would be 0x14, not 0x10.

It's like the NMI is forgetting it's in a wait on the second operation, but only when sleeping, not when idling. And if something else were terminating the wait the dog would get kicked again before it had a chance to NMI, so the reset would never happen.

It's the fact that it works fine on the first NMI but not on the second that puzzles me. It's the same code.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: Watchdog problems
PostPosted: Mon Jul 21, 2014 12:08 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Ok, I have just solved it.

I just wrote a small program in MPLAB-X that works perfectly, so I disassembled it and took a look at the reset vector it generated.

It was completely different to how the manual says you should do it!

Code:
bfc00000:   401a6000    mfc0    k0,c0_status
bfc00004:   7f5a04c0    ext k0,k0,0x13,0x1
bfc00008:   13400005    beqz    k0,bfc00020 <_no_nmi>
bfc0000c:   00000000    nop
bfc00010:   3c1a9d00    lui k0,0x9d00
bfc00014:   275a02a8    addiu   k0,k0,680
bfc00018:   03400008    jr  k0 <_nmi_handler>
bfc0001c:   00000000    nop

9d0002a8 <_nmi_handler>:
9d0002a8:   401a6000    mfc0    k0,c0_status
9d0002ac:   3c1bffbf    lui k1,0xffbf
9d0002b0:   377bffff    ori k1,k1,0xffff
9d0002b4:   035bd024    and k0,k0,k1
9d0002b8:   409a6000    mtc0    k0,c0_status
9d0002bc:   42000018    eret

It's not looking at RCON at all, but instead looking at C0 to see if it was an NMI that happened - and if so do an eret.

So it seems to be a case of "do what I do, not what I say" ...!

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: Watchdog problems
PostPosted: Mon Jul 21, 2014 1:17 am 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA
So it was not NMI caused by watchdog, but something different?
Generally, Status.NMI bit is always reliable for detection of NMI event.


Top
 Profile  
 
 Post subject: Re: Watchdog problems
PostPosted: Mon Jul 21, 2014 8:56 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
It was NMI, and it must have been caused by the wachdog (RCON<4> is set), but for some unknown reason it wasn't always setting RCON<3> when it should have been. Inspecting C0 status seems to be a more reliable way of doing it. I think the watchdog is the only source of NMIs on the PIC32 isn't it?

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: Watchdog problems
PostPosted: Mon Jul 21, 2014 12:30 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Matt and Serge,

Nice work :). Can't wait to try fuse.

Wiz


Top
 Profile  
 
 Post subject: Re: Watchdog problems
PostPosted: Mon Jul 21, 2014 8:48 pm 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA
majenko wrote:
It was NMI, and it must have been caused by the wachdog (RCON<4> is set), but for some unknown reason it wasn't always setting RCON<3> when it should have been. Inspecting C0 status seems to be a more reliable way of doing it. I think the watchdog is the only source of NMIs on the PIC32 isn't it?
From the datasheet, it seems like only watchdog can cause NMI on MX series. On MZ, there are more sources, like DMT, SWNMI or FSCM.
wiz wrote:
Nice work :). Can't wait to try fuse.
All the changes are in the repository. Just update your sources and rebuild the utility:
Code:
cd /Your/Path/retrobsd
git pull
cd tools/fsutil
make
./fsutil --mount ...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


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 post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission