• AVR Freaks

Hot!Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handling

Author
GlennP
Super Member
  • Total Posts : 833
  • Reward points : 0
  • Joined: 2009/03/29 15:04:55
  • Location: El Paso County, CO, USA
  • Status: offline
2020/07/04 01:33:29 (permalink)
0

Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handling

I'm waiting for Silicon, so I'm using the Simulator.  For far, it seems much more accurate for the 16-bit world compared to the 8-bit world.  But ...
 
I normally stop the CPU when there is nothing to do.  The logic below (or a close variant of it) has been saving me micro-amps for years - mostly on 8-bit CPUs.  But under the simulator (haven't tried silicon yet - next week for the last four chips in Microchip's inventory), the CPU never restarts after the Idle state is entered - even thought two timer interrupts are pending and enabled.
 
It runs fine as shown below (Idle removed via comment).  But when I have the Idle call enabled, the simulation stops - forever.
 
There was a recent thread about the simulator and interrupts, but that was resolved and didn't involve Idle.  This is not a high priority as it's working without the Idle call and the silicon is due soon.  But I thought getting this in the Forum might save someone else some trouble and might help the simulator along.
 
MPLabX 5.40, XC16 1.50, Win10Pro.
 
GP
 

//  If Nothing Ready on First Test,
//  Perform Test Again with Interrupts OFF.
    if ((IntrTaskReadyMask | SftrTaskReadyMask) == 0) {
    //  Perform Test on IntrTaskReadyMask with Interrupts OFF.
        INTERRUPT_GlobalDisable();
        if (IntrTaskReadyMask == 0) {
    //      Idle(); // CPU Stops, Clocks Run.
        }
        INTERRUPT_GlobalEnable();
    }

#1

13 Replies Related Threads

    GlennP
    Super Member
    • Total Posts : 833
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/11 02:27:43 (permalink)
    +4 (4)
    I confirmed the code (including the call to Idle) works with Silicon.
     
    So I conclude this is indeed a simulator bug.
     
    GP
    #2
    GeorgePauley
    Moderator
    • Total Posts : 1268
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/13 09:50:24 (permalink)
    +1 (3)
    Thanks Glenn, bug report written.  Not sure when we'll get around to this. 
    #3
    GlennP
    Super Member
    • Total Posts : 833
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/13 21:19:05 (permalink)
    +1 (1)
    George:
     
    Good to hear (bug report entered).  If I hear it's fixed, I'll retry my code with the simulator.  But I've got silicon and I'm proceeding apace.
     
    GP.
    #4
    JackZhao
    Super Member
    • Total Posts : 87
    • Reward points : 0
    • Joined: 2013/02/13 16:16:09
    • Location: 0
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/14 14:50:17 (permalink)
    +2 (2)
    Hi Glenn,
     
    We tried to work on this issue. We did a simple test which was setting the T1IE field in IEC0 and T1IF field in IFS0 in the variable window after executing the "PWRSAV #1" (this is how we trick Simulator to trigger a Timer1 interrupt). It went into the ISR and started executing instructions. It seems like the interrupt should work during power saving. Maybe the Simulator Timer peripheral does not work will the Simulator interrupt handler correctly. If you could give us a simple project which will replicate your issue, we could be in the same page. This will help us solving this issue.
     
    Thanks,
    Jack
    #5
    GlennP
    Super Member
    • Total Posts : 833
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/15 01:10:25 (permalink)
    +1 (1)
    Jack:
     
    That's good news.  As soon as I've filed my three (!!!) income tax extensions, I'll see if I can pare down the code to something digestible.  And verify the problem exists in my trimmed-down example.
     
    I will note that the Timer1 ISR is written in assembler.  It wasn't at first, but the timer fires every 3.3 uSeconds and it was taking more than 2 uSeconds before I hand-coded it.  But since the project still works in Silicon and still fails in the Simulator, I think the ISR itself is not the issue.
     
    I should add that the Simulator hits a breakpoint in the ISR once.  But I think that's expected because the "main" has likely not yet hit the Idle call.
     
    Edit 1: I just verified that the ISR is hit before the call to Idle.
     
    Expect something late the 15th or sometime the 16th, MDT.
     
    GP.
    post edited by GlennP - 2020/07/15 01:30:09
    #6
    GlennP
    Super Member
    • Total Posts : 833
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/15 11:56:48 (permalink)
    +1 (1)
    Update: Sent Jack a PM with a small project in a "ZIP.TXT" file.  GP.
    #7
    JackZhao
    Super Member
    • Total Posts : 87
    • Reward points : 0
    • Joined: 2013/02/13 16:16:09
    • Location: 0
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/20 10:03:25 (permalink)
    +2 (2)
    Hi Glenn,
     
    Thank you for the project. Now we understand the issue you reported. Our Simulator only covered the case that "If the assigned priority level for the interrupt source is greater than the current CPU priority, the device will wake-up and the CPU exception process will begin. Code execution will continue from the first instruction of the ISR.". We didn't cover the case that "If the assigned priority for the interrupt is less than or equal to the current CPU priority, the device will wake-up and continue code execution from the instruction following the PWRSAV instruction that initiated Idle mode.". In your project, you disabled global interrupt before entering idle mode (When the GIE bit is cleared, it causes the Interrupt Controller to behave as if the CPU’s IPLx bits are set to 7 and disables all interrupts except the traps), which is the case we didn't cover yet. We are working on a fix for this issue. We will let you know when the fix is ready.
     
    Regards,
    Jack
    #8
    GlennP
    Super Member
    • Total Posts : 833
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/20 10:38:53 (permalink)
    0
    Jack:
    +1
     
    Great.  Glad to help.
     
    I had to do the final test with interrupts off - otherwise a change in the Interrupt Task Ready Flag could sneak in between my test and the Idle.  That, in the words of Raymond Chandler, would be The Big Sleep.
     
    I assume the fix will be part of a general MPLabX release, so either make a mention of it in the release notes or post something here.
     
    Glenn
    #9
    dan1138
    Super Member
    • Total Posts : 3841
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/20 12:42:14 (permalink)
    0
    Glen,
     
    Do you suspect that this simulator issue would affect any of the dsPIC33 and PIC24 devices that use the same interrupt controller architecture, or could it be confined to only the new type that has the GIE bit?
    #10
    GlennP
    Super Member
    • Total Posts : 833
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/20 23:58:51 (permalink)
    0
    Dan,
     
    I can read Jack's explanation either way, but my sense is it applies no matter how the IPL bits get set to 7.
     
    OTOH, maybe it would have been discovered much earlier if it had been there for the earlier devices.
     
    In the end, Jack would have to answer.
     
    Do you have any experience that makes you think you hit the simulator bug with earlier devices?
     
    Glenn
     
    PS. I like the GIE bit as it seems quicker to set and clear.  But I don't understand what happens to IPLx bits when you set it.  Does it somehow revert to the "pre bclr GIE state"?  I didn't find a mention in the documentation, but I'm notoriously bad at finding stuff in the 16-bit family docs because everything is split between the device and the family docs.  I need to test it but my code doesn't do that in an ISRs so I'd have to manufacture a test.
     
    Edit (Update): I did manufacture a test (clearing and setting GIE in an ISR) and clearing the GIE does not change the IPL bits in the SR.  Nor does setting the GIE bit do anything to the SR's IPL bits.  I guess clearing GIE just makes the interrupt controller "behave as if" the IPLbits = 7.    Simplest for us and, as far as I could find, not documented (except Jack mentioned it above).  That could be at least partially responsible for the Simulator issue.
     
    I would note that the phrase "behaves as if" was something my Quantum Mechanics instructors (esp. Tony French) said all the time when describing the various spooky aspects of QM.
    post edited by GlennP - 2020/07/21 00:58:22
    #11
    JackZhao
    Super Member
    • Total Posts : 87
    • Reward points : 0
    • Joined: 2013/02/13 16:16:09
    • Location: 0
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/21 09:45:35 (permalink)
    +2 (2)
    Hi Glenn,
    Yes, the GIE behavior is described in the dsPIC33/PIC24 family reference manuals ([link=http://ww1.microchip.com/downloads/en/DeviceDoc/dsPIC33-PIC24-FRM,-Interrupts-DS70000600E.pdf]http://ww1.microchip.com/...rrupts-DS70000600E.pdf[/link] (page 25)). In Note 1, it says "The GIE bit does not modify the CPU’s IPLx bits."
     
    Hi Dan,
    I got my initial conclusion by reading the family reference manuals and the Simulator interrupt handling code. After I started working on the fix for this issue, I got deeper and found that actually the GIE implementation had issue for power saving modes which means this issue should not affect the devices which do not have GIE.
     
    Regards,
    Jack
     

    #12
    dan1138
    Super Member
    • Total Posts : 3841
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/23 16:08:29 (permalink)
    +1 (1)
    JackZhao
    Hi Dan,
     
    I got my initial conclusion by reading the family reference manuals and the Simulator interrupt handling code. After I started working on the fix for this issue, I got deeper and found that actually the GIE implementation had issue for power saving modes which means this issue should not affect the devices which do not have GIE.
     
    Regards,
    Jack

    I just stumbled on this as the only controller I have with the GIE bit is the PIC24FJ256GA702.
     
    While testing this watchdog behavior in the simulator I found that watchdog timeout is never asserted for the PIC24FJ256GA702 when the controller is in sleep mode.
     
    I am using this test code:
    /*
     * File:   main.c
     * Author: dan1138
     * Target: PIC24FJ256GA702
     * Compiler: XC16 v1.41
     * IDEP MPLABX v5.40
     *
     *                        PIC24FJ256GA702                    
     *              +--------------:_:--------------+            
     *  ICD_VPP --> :  1 MCLR               VDD  28 : <-- PWR    
     *     SDA2 < > :  2 RA0/RP26           VSS  27 : <-- GND    
     *          < > :  3 RA1/RP27      RP15/RB15 26 : < > LED    
     *  DBG_TXD < > :  4 RB0/PGD1      RP14/RB14 25 : < >        
     *  DBG_RXD < > :  5 RB1/PGC1      RP13/RB13 24 : < >        
     *     SDA2 < > :  6 RB2/RP2/SDA2  RP12/RB12 23 : < >        
     *     SCL2 < > :  7 RB3/RP3/SCL2  RP11/RB11 22 : <*>        
     *      GND - > :  8 VSS           RP10/RB10 21 : <*>        
     *          < > :  9 RA2/OSCI           VCAP 20 : <-- 10uF   
     *          < > : 10 RA3/OSCO           VSS  19 : <-- GND    
     *          < > : 11 RB4/RP4       SDA1/RB9  18 : < > SDA1   
     *          < > : 12 RA4           SCL1/RB8  17 : <*> SCL1   
     *      3v3 --> : 13 VDD      INT0/RP7 /RB7  16 : <*>        
     *  ICD_PGD <*> : 14 RB5/PGD3      PGC3/RB6  15 : <*> ICD_PGC
     *              +-------------------------------+            
     *                           DIP-28                          
     *           * Indicates 5.5V tolerant input pins.           
     *
     * Created on July 23, 2020, 11:28 AM
     *
     * Description:
     *
     *  This application is to test sleep mode behavior using the simulator tool.
     *
     *  We are specifically look to find out if the simulation will wake when an
     *  external asynchronous event occurs with an interrupt priority that is
     *  blocked by the current setting of the IPL level in the STATUS register.
     *
     *  Only the internal oscillators are used.
     *
     *  Setup the sleep timeout period to about 8 seconds.
     *
     *  Detected wake up events are:
     *
     *      Power-On-Reset
     *      High to low transition of the INT0 input
     *      High to low transition of the MCLR input
     *      Sleep timeout period
     */
    #pragma config BWRP = OFF, BSS = DISABLED, BSEN = OFF, GWRP = OFF
    #pragma config GSS = DISABLED, CWRP = OFF, CSS = DISABLED, AIVTDIS = OFF
    #pragma config BSLIM = 0x1FFF, FNOSC = FRC, PLLMODE = PLL4X, IESO = OFF
    #pragma config POSCMD = NONE, OSCIOFCN = ON, SOSCSEL = OFF
    #pragma config PLLSS = PLL_PRI, IOL1WAY = OFF, FCKSM = CSECMD
    #pragma config WDTPS = PS2048, FWPSA = PR128, FWDTEN = ON, WINDIS = OFF
    #pragma config WDTWIN = WIN25, WDTCMX = WDTCLK, WDTCLK = LPRC, BOREN = OFF
    #pragma config LPCFG = OFF, DNVPEN = ENABLE, ICS = PGD3, JTAGEN = OFF
    #pragma config ALTCMPI = DISABLE, TMPRPIN = OFF, SOSCHP = OFF, ALTI2C1 = ALTI2CEN
    #include "xc.h"
    #include <stdio.h>
    /*
     * Define USE_IPL_TO_DISABLE_INTERRUPTS to see how
     * the simulator responds to an external interrupt
     * request when user interrupts are all masked with
     * this method.
     *
     * Define USE_GIE_TO_DISABLE_INTERRUPTS to see how
     * the simulator responds to an external interrupt
     * request when user interrupts are all masked with
     * this method.
     *
     * To see how the simulator works with the user
     * interrupts unmasked leave them undefined.
     */
    //#define USE_IPL_TO_DISABLE_INTERRUPTS
    //#define USE_GIE_TO_DISABLE_INTERRUPTS
    #define FSYS        (32000000L)
    #define FCY         (FSYS/2)    /* Instruction Cycle Frequency */
       
    #define UARTNUM     2               //Which device UART to use
       
    #define BAUDRATE    9600L
    #define USE_HI_SPEED_BRG            //Use BRGH=1, UART high speed mode
       
    //UART Baud Rate Calculation *******************************************************
    #ifdef USE_HI_SPEED_BRG
        #define BRG_DIV 4L
    #else
        #define BRG_DIV 16L
    #endif
       
    #define BAUDRATEREG    ( ((FCY + (BRG_DIV * BAUDRATE / 2L)) / (BRG_DIV * BAUDRATE)) - 1L)
    #define BAUD_ACTUAL    (FCY/BRG_DIV/(BAUDRATEREG+1))
       
    #define BAUD_ERROR          ((BAUD_ACTUAL > BAUDRATE) ? BAUD_ACTUAL-BAUDRATE : BAUDRATE-BAUD_ACTUAL)
    #define BAUD_ERROR_PRECENT  ((BAUD_ERROR*100L+BAUDRATE/2L)/BAUDRATE)
       
    #if (BAUD_ERROR_PRECENT > 3)
        #error "UART frequency error is worse than 3%"
    #elif (BAUD_ERROR_PRECENT > 2)
        #warning "UART frequency error is worse than 2%"
    #endif
       
    //UART Configuration ***************************************************************
    #define UARTREG2(a,b)     U##a##b
    #define UARTREG(a,b)    UARTREG2(a,b)
       
    #define UxMODE      UARTREG(UARTNUM,MODE)
    #define UxBRG       UARTREG(UARTNUM,BRG)
    #define UxSTA       UARTREG(UARTNUM,STA)
    #define UxRXREG     UARTREG(UARTNUM,RXREG)
    #define UxTXREG     UARTREG(UARTNUM,TXREG)
    #define UxMODEbits  UARTREG(UARTNUM,MODEbits)
    #define UxSTAbits   UARTREG(UARTNUM,STAbits)
    #define UxTX_IO     UARTREG(UARTNUM,TX_IO)
    /*
     * Select UART as the default standard I/O port
     */
    int __C30_UART = UARTNUM;
    /*
     * Initialize this PIC
     */
    void PIC_Init(void)
    {
        unsigned short ClockSwitchTimeout;
        /*
         * Disable all interrupt sources
         */
        __builtin_disi(0x3FFF); /* disable interrupts for 16383 cycles */
        IEC0 = 0;
        IEC1 = 0;
        IEC2 = 0;
        IEC3 = 0;
        IEC4 = 0;
        IEC5 = 0;
        IEC6 = 0;
        IEC7 = 0;
        __builtin_disi(0x0000); /* enable interrupts */
        ANSA   =  0x0000; /* Set for digital I/O */
        ANSB   =  0x0000; /* Set for digital I/O */
       
        _NSTDIS = 1;    /* disable interrupt nesting */
           
        TRISA   = 0xFFFF;
        TRISB   = 0x7FFF;
        CLKDIV  = 0x0000; /* set for FRC clock 8MHZ operations */
        /*
         * At Power On Reset the configuration words set the system clock
         * to use the FRC oscillator. At this point we need to enable the
         * PLL to get the system clock running at 32MHz.
         *
         * Clock switching on the 24FJ family with the PLL can be a bit tricky.
         *
         * First we need to check if the configuration words enabled clock
         * switching at all, then turn off the PLL, then setup the PLL and
         * finally enable it. Sounds simple, I know. Make sure you verify this
         * clock setup on the real hardware.
         */
        LATBbits.LATB15 = 1;    /* turn on LED for debug */
        /* Spin wait so LED can be seen */
        for(ClockSwitchTimeout=60000; ClockSwitchTimeout;--ClockSwitchTimeout) Nop();
           
        if(!OSCCONbits.CLKLOCK) /* if primary oscillator switching is unlocked */
        {
            /* Select primary oscillator as FRC */
            __builtin_write_OSCCONH(0b000);
            /* Request switch primary to new selection */
            __builtin_write_OSCCONL(OSCCON | (1 << _OSCCON_OSWEN_POSITION));
            /* wait, with timeout, for clock switch to complete */
            for(ClockSwitchTimeout=10000; ClockSwitchTimeout;--ClockSwitchTimeout) if (OSCCONbits.OSWEN == 0) break;
            /* Select primary oscillator as FRCPLL */
            __builtin_write_OSCCONH(0b001);
            /* Request switch primary to new selection */
            __builtin_write_OSCCONL(OSCCON | (1 << _OSCCON_OSWEN_POSITION));
           
            /* wait, with timeout, for clock switch to complete */
            for(ClockSwitchTimeout=10000; ClockSwitchTimeout;--ClockSwitchTimeout) if (OSCCONbits.OSWEN == 0) break;
            /* wait, with timeout, for the PLL to lock */
            for(ClockSwitchTimeout=10000; ClockSwitchTimeout;--ClockSwitchTimeout) if (OSCCONbits.LOCK) break;
           
            /* at this point the system oscillator should be 32MHz */
        }
        LATBbits.LATB15 = 0;    /* turn off LED for debug */
    }
    /*
     * Process flags in the RCON register
     *
     * Returns Power On Reset state:
     * 0 = Power On Reset
     * 1 = Reserved for Deep sleep wake up
     * 2 = MCLR reset
     * 3 = Watchdog timeout reset, never in deep sleep
     * 4 = Wake from sleep
     * 5 = Wake from idle
     * 6 = Software reset instruction
     */ 
    unsigned short RCON_Event(void)
    {
        unsigned short Result;
       
        if(RCONbits.POR)
        {
            Result = 0;
            RCONbits.POR = 0;
            RCONbits.BOR = 0;
            RCONbits.EXTR = 0;
            RCONbits.SWR = 0;
            RCONbits.WDTO = 0;
        }
        else if(RCONbits.BOR)
        {
            Result = 0;
            RCONbits.BOR = 0;
            RCONbits.POR = 0;
            RCONbits.EXTR = 0;
            RCONbits.SWR = 0;
            RCONbits.WDTO = 0;
        }
        else if(RCONbits.EXTR)
        {
            Result = 2;
            RCONbits.EXTR = 0;
            RCONbits.SWR = 0;
            RCONbits.WDTO = 0;
        }
        else if(RCONbits.WDTO)
        {
            Result = 3;
            RCONbits.WDTO = 0;
        }
        else if(RCONbits.SWR)
        {
            Result = 6;
            RCONbits.SWR = 0;
        }
        else if(RCONbits.SLEEP)
        {
            Result = 4;
            RCONbits.SLEEP = 0;
        }
        else if(RCONbits.IDLE)
        {
            Result = 5;
            RCONbits.IDLE = 0;
        }
        else
        {
            Result = 0;         /* assume we are a Power On reset */
            RCONbits.POR = 0;
        }
        return Result;
    }
    /* 
     * Handler to catch INT0 interrupt
     */ 
    void __attribute__((interrupt,no_auto_psv)) _INT0Interrupt(void)
    {
        IFS0bits.INT0IF = 0;    /* clear request flag */
        while(!UxSTAbits.TRMT);
        printf("  INT0 event\r\n");
        while(!UxSTAbits.TRMT);
    }
    /*
     * Setup INT0 external interrupt
     */
    void INT0_Init(void)
    {
        ANSELB &= ~(1<<7);      /* make pins digital I/O */
        TRISB  |=  (1<<7);      /* make pin an input */
        CNPUBbits.CNPUB7 = 1;   /* enable weak pull-up on INT0/RP7/RB7 */
        INTCON2bits.INT0EP = 1; /* negative edge */
        IPC0bits.INT0IP = 4;    /* select priority level 4 */
        IFS0bits.INT0IF = 0;    /* clear request flag */
        IEC0bits.INT0IE = 1;    /* enable interrupt source */
    }
    /* 
     * SETUP UART: No parity, one stop bit, polled
     */ 
    void Uart_Init(void)
    {  
        /* Unlock Registers */
        __builtin_write_OSCCONL(OSCCON & ~_OSCCON_IOLOCK_MASK);
        _U2RXR = 0b0000001;   /* U2RXD RP1/RB1 */
        _RP0R  = 0b0000101;   /* U2TXD RP0/RB0 */       
        /* Lock Registers */
        __builtin_write_OSCCONL(OSCCON | _OSCCON_IOLOCK_MASK);
        UxMODEbits.UARTEN = 1;      //enable uart
        UxBRG = BAUDRATEREG;
       
    #ifdef USE_HI_SPEED_BRG
        UxMODEbits.BRGH = 1;    //use high speed mode
    #else
        UxMODEbits.BRGH = 0;    //use low speed mode
    #endif
       
        UxSTA = 0x0400;  //Enable TX
    }  
    /*
     * Main Application
     */
    int main(void)
    {
        unsigned short ResetType;
        unsigned short WakeType;
        unsigned short Temp;
       
        PIC_Init();
        Uart_Init();
        INT0_Init();
        ResetType = RCON_Event();
        if ((ResetType == 0) || (ResetType == 2))
        {
            /* Spin wait for UART TX output initialization glitch to settle */
            unsigned int SpinWait;
            for(SpinWait=60000;SpinWait;SpinWait--) Nop();
        }
       
        if (ResetType == 0)
        {
            printf("\r\n  Power on reset, hello there\r\n");
        }
        else if (ResetType == 2)
        {
            printf("  MCLR reset\r\n");
        }
        else if (ResetType == 3)
        {
            printf("  WDT timeout reset\r\n");
        }
        else if (ResetType == 4)
        {
            printf("  WDT wake from sleep\r\n");
        }
        else if (ResetType == 5)
        {
            printf("  WDT wake from idle\r\n");
        }
        else if (ResetType == 6)
        {
            printf("  Software reset\r\n");
        }
    #if defined(USE_IPL_TO_DISABLE_INTERRUPTS)
        _NSTDIS = 0;        /* enable interrupt nesting */
        SRbits.IPL = 7;     /* Disable user interrupts */
        _NSTDIS = 1;        /* disable interrupt nesting */
        printf("  Interrupts disabled using IPL\r\n");
    #elif defined(USE_GIE_TO_DISABLE_INTERRUPTS)
        INTCON2bits.GIE = 0;
        printf("  Interrupts disabled using GIE\r\n");
    #else
        printf("  Interrupts are enabled\r\n");
    #endif
       
        /* Main application loop */
        for(;;)
        {
            while(!UxSTAbits.TRMT);
            IFS0bits.INT0IF = 0;    /* clear request flag */
            /* enter sleep  */
            asm("disi #4");
            asm("nop");
            asm("nop");
            asm("nop");
            asm("nop");
            asm("pwrsav #0");
            Temp = RCON;
            WakeType = RCON_Event();
            printf("AppLoop, WDT wake from sleep, type %u, RCON=%04X\r\n", WakeType,Temp);
        }
       
        return 0;
    }

    This code works as expected in real hardware.
     
    Is this another simulator bug?
     
    If not could you perhaps tell me where I've gone wrong?
    post edited by dan1138 - 2020/07/23 16:11:23
    #13
    JackZhao
    Super Member
    • Total Posts : 87
    • Reward points : 0
    • Joined: 2013/02/13 16:16:09
    • Location: 0
    • Status: offline
    Re: Simulator vs. Idle (PWRSAV #1) on dsPIC33EP64MC202 - Seems to Prevent Interrupt Handli 2020/07/24 11:06:39 (permalink)
    +2 (2)
    Hi Dan,
     
    Thank you for reporting this issue and the test project. I confirmed that this is a Simulator bug. Since Simulator finds all the CONFIGs and SFRs that are required for a certain WDT peripheral, it thinks PIC24FJ256GA702 has this type of WDT. For the WDT in PIC24FJ256GA702, it has "If the FWDTEN[1:0] Configuration bits are ‘11’ (unprogrammed), the WDT is always enabled, regardless of the SWDTEN bit setting.". But the implementation of that WDT, which Simulator thinks PIC24FJ256GA702 has, doesn't handle case '11' for FWDTEN[1:0]. For this reason, the WDT is off with the default setting incorrectly which makes it look like watchdog timeout is never asserted. I will create an SSR for this issue, and hopefully we could get on with it soon.
     
    Regards,
    Jack
    #14
    Jump to:
    © 2020 APG vNext Commercial Version 4.5