• AVR Freaks

Hot!POR vs WDT reset oscillator behaviour

Author
bluewave
Senior Member
  • Total Posts : 60
  • Reward points : 0
  • Joined: 2012/05/19 17:24:14
  • Location: Aotearoa
  • Status: offline
2020/10/01 20:22:22 (permalink)
0

POR vs WDT reset oscillator behaviour

Posting this in case of use or interest to others.
PIC16F18345, XC8 v1.44 Pro Mode
 
I am running an 8MHz crystal on OSC1 and OSC2 and have for CONFIG1:
#pragma config FEXTOSC = HS     // FEXTOSC External Oscillator mode Selection bits (HS (crystal oscillator) above 4 MHz)
#pragma config RSTOSC = EXT1X   // Power-up default value for COSC bits (EXTOSC operating per FEXTOSC bits )
 
At all times my scope indicates the oscillator is producing a clean and stable 8MHz waveform.
 
Weirdly (to me), every time my circuit had power applied, it would execute code at double the expected speed (FOSC=16MHz). If I set the circuit to hit a WDT reset after 32s, after the WDT reset, code would execute at the expected speed (FOSC=8MHz). After the reset in each case, the executed code was exactly the same.
 
I printed NOSC and COSC after the resets. This showed that COSC after POR was 0b110 (not the expected 0b111), which combined with the default HFINTOSC value (0b0110), runs the HFINTOSC at 16MHz (causing double speed execution). After the WDT reset, COSC reset to 0b111 and the external 8MHz oscillator was used as expected. Simple solution was to write 0b111 to NOSC in the start up code.
 
But I am a bit puzzled why COSC did not match the CONFIG1 setting after POR, but did after WDT....??
 
 
 
post edited by bluewave - 2020/10/01 20:23:31
#1

5 Replies Related Threads

    Mysil
    Super Member
    • Total Posts : 3785
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: offline
    Re: POR vs WDT reset oscillator behaviour 2020/10/15 06:59:53 (permalink)
    +1 (1)
    Hi,
    Mistakes can happen in silicon hardware design, as well as in software code.
     
    While it might be possible to create an example corresponding to description above,
    an actual working example, demonstrating the phenomen, would be more useful.
     
    In MPLAB X there is a 'Package' facility to collect all files needed to restore a project:
    In 'Projects'panel, upper left part, point to root of project tree, and right-click for a pop-up menu,
    click  'Package'
    It will create a .zip file with files needed to restore and debug the project.
     
        Mysil
    #2
    mbrowning
    USNA79
    • Total Posts : 1810
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: POR vs WDT reset oscillator behaviour 2020/10/15 07:55:02 (permalink)
    0
    As Mysil said - actual code would clarify if FSCM is enabled, but this sounds like Fail-Safe Clock Monitor is being triggered due to slow oscillator startup on powerup (2ms delay if FSCM is enabled). You can check if the OSFIF bit is set after power up which would tell you for sure. Any other reset would go back to the external oscillator and since it's already running by then it doesn't trigger the FSCM again.
     
    This probably explains COSC being 110, but Section 7.4.2 says that the fail-safe clock is HFINOSC at 1MHz so there's a bit of mystery if FSCM is the culprit.
    #3
    Howard Long
    Super Member
    • Total Posts : 836
    • Reward points : 0
    • Joined: 2005/04/04 08:50:32
    • Status: offline
    Re: POR vs WDT reset oscillator behaviour 2020/10/15 13:09:38 (permalink)
    0
    It looks OK to me.
     
    8MHz crystal, 2x22pF to ground.
     


    // PIC16F18345 Configuration Bit Settings
    // 'C' source line config statements
    // CONFIG1
    //#pragma config FEXTOSC = OFF // FEXTOSC External Oscillator mode Selection bits (Oscillator not enabled)
    #pragma config FEXTOSC = HS // FEXTOSC External Oscillator mode Selection bits (HS (crystal oscillator) above
    //#pragma config RSTOSC = HFINT1 // Power-up default value for COSC bits (HFINTOSC (1MHz))4 MHz)
    #pragma config RSTOSC = EXT1X // Power-up default value for COSC bits (EXTOSC operating per FEXTOSC bits )
    //#pragma config CLKOUTEN = ON // Clock Out Enable bit (CLKOUT function is enabled; FOSC/4 clock appears at OSC2)
    #pragma config CLKOUTEN = OFF // Clock Out Enable bit (CLKOUT function is disabled; I/O or oscillator function on OSC2)
    #pragma config CSWEN = OFF // Clock Switch Enable bit (The NOSC and NDIV bits cannot be changed by user software)
    #pragma config FCMEN = OFF // Fail-Safe Clock Monitor Enable (Fail-Safe Clock Monitor is disabled)
    // CONFIG2
    #pragma config MCLRE = ON // Master Clear Enable bit (MCLR/VPP pin function is MCLR; Weak pull-up enabled)
    #pragma config PWRTE = OFF // Power-up Timer Enable bit (PWRT disabled)
    //#pragma config WDTE = OFF // Watchdog Timer Enable bits (WDT disabled; SWDTEN is ignored)
    #pragma config WDTE = SWDTEN // Watchdog Timer Enable bits (WDT controlled by the SWDTEN bit in the WDTCON register)
    #pragma config LPBOREN = OFF // Low-power BOR enable bit (ULPBOR disabled)
    #pragma config BOREN = OFF // Brown-out Reset Enable bits (Brown-out Reset disabled)
    #pragma config BORV = LOW // Brown-out Reset Voltage selection bit (Brown-out voltage (Vbor) set to 2.45V)
    #pragma config PPS1WAY = OFF // PPSLOCK bit One-Way Set Enable bit (The PPSLOCK bit can be set and cleared repeatedly (subject to the unlock sequence))
    #pragma config STVREN = ON // Stack Overflow/Underflow Reset Enable bit (Stack Overflow or Underflow will cause a Reset)
    #pragma config DEBUG = OFF // Debugger enable bit (Background debugger disabled)
    // CONFIG3
    #pragma config WRT = OFF // User NVM self-write protection bits (Write protection off)
    #pragma config LVP = ON // Low Voltage Programming Enable bit (Low Voltage programming enabled. MCLR/VPP pin function is MCLR. MCLRE configuration bit is ignored.)
    // CONFIG4
    #pragma config CP = OFF // User NVM Program Memory Code Protection bit (User NVM code protection disabled)
    #pragma config CPD = OFF // Data NVM Memory Code Protection bit (Data NVM code protection disabled)
    // #pragma config statements should precede project file includes.
    // Use project enums instead of #define for ON and OFF.
    #include <xc.h>
    #define _XTAL_FREQ 8000000
    void main(void)
    {
    LATBbits.LATB6=0;
    TRISBbits.TRISB6=0;
    WDTCONbits.WDTPS=0b01100; // 0b01100 => 4s
    __delay_ms(1000);
    WDTCONbits.SWDTEN=1;
    while (1)
    {
    LATBbits.LATB6=1;
    __delay_ms(1);
    LATBbits.LATB6=0;
    __delay_ms(1);
    }
    return;
    }

     

    Attached Image(s)

    #4
    bluewave
    Senior Member
    • Total Posts : 60
    • Reward points : 0
    • Joined: 2012/05/19 17:24:14
    • Location: Aotearoa
    • Status: offline
    Re: POR vs WDT reset oscillator behaviour 2020/10/15 13:30:25 (permalink)
    0
    Interesting! I will strip down to minimum code / circuit I can, then upload and update.
    #5
    bluewave
    Senior Member
    • Total Posts : 60
    • Reward points : 0
    • Joined: 2012/05/19 17:24:14
    • Location: Aotearoa
    • Status: offline
    Re: POR vs WDT reset oscillator behaviour 2020/10/16 15:23:39 (permalink)
    0
    MBrowning suggestion that it involves the FSCM and slow startup is right. One thing I didn't mention - I was using too high capacitance on my 8MHz crystal (2 x 33pF on an 18pF crystal) as that was what I had handy. This will give my oscillator a slightly slow startup (depending on stray cap).
     
    I have built the circuit on breadboard as per Howard Long. Running Howard's code above, except for changing FCMEN as described below. I can replicate the problem as follows:
     
    FCMEN=OFF, 2 x 33pF ---- POR speed 8MHz
    FCMEN=ON, 2 x 33pF ----  POR speed 16MHz
    FCMEN=OFF, 2 x 15pF ---- POR speed 8MHz
    FCMEN=ON, 2 x 15pF ----  POR speed 8MHz
     
    Revision ID of my silicon is 2044
    post edited by bluewave - 2020/10/16 15:30:00
    #6
    Jump to:
    © 2020 APG vNext Commercial Version 4.5