Proteus Simulator and PIC16F1825 CLKOUT

[viki2000]

I have tested it with PIC16F1825 at 32MHz internal clock.
At CLKOUT pin, OSC2, PORTA, RA4 it supposed to come a rectangular signal with a frequency Fosc/4=8MHz and is not there, the virtual digital oscilloscope does not show it.
I have tested the same HEX code on a real PIC16F1825 and I measured it with a real oscilloscope and I can see the 8MHz CLKOUT signal.
With Proteus I cannot simulate CLKOUT.
I asked directly on Proteus forum and the say is working and they provided the screenshot below, but without virtual oscilloscope and without showing how they did it, what setup and what code was used and they locked the question.
Any idea how they did it?

Because I have tried with several compilers, let’s focus now on one.
Below is the MPLABX with C code for XC8 compiler.
The code used is:

Code: [Select]

    #include <xc.h>
    #include <pic16f1825.h>
    #define _XTAL_FREQ 32000000

    // CONFIG1
    #pragma config FOSC = INTOSC // Oscillator Selection (INTOSC oscillator: I/O function on CLKIN pin)
    #pragma config WDTE = OFF // Watchdog Timer Enable (WDT disabled)
    #pragma config PWRTE = OFF // Power-up Timer Enable (PWRT disabled)
    #pragma config MCLRE = OFF // MCLR Pin Function Select (MCLR/VPP pin function is digital input)
    #pragma config CP = OFF // Flash Program Memory Code Protection (Program memory code protection is disabled)
    #pragma config CPD = OFF // Data Memory Code Protection (Data memory code protection is disabled)
    #pragma config BOREN = ON // Brown-out Reset Enable (Brown-out Reset enabled)
    #pragma config CLKOUTEN = ON // Clock Out Enable (CLKOUT function is enabled on the CLKOUT pin)
    #pragma config IESO = OFF // Internal/External Switchover (Internal/External Switchover mode is disabled)
    #pragma config FCMEN = OFF // Fail-Safe Clock Monitor Enable (Fail-Safe Clock Monitor is disabled)

    // CONFIG2
    #pragma config WRT = OFF // Flash Memory Self-Write Protection (Write protection off)
    #pragma config PLLEN = ON // PLL Enable (4x PLL enabled)
    #pragma config STVREN = OFF // Stack Overflow/Underflow Reset Enable (Stack Overflow or Underflow will not cause a Reset)
    #pragma config BORV = LO // Brown-out Reset Voltage Selection (Brown-out Reset Voltage (Vbor), low trip point selected.)
    #pragma config LVP = OFF // Low-Voltage Programming Enable (High-voltage on MCLR/VPP must be used for programming)

    void main(){
    OSCCON = 0xF0;
    OSCSTAT = 0x00;
    OSCTUNE = 0x00;

    LATA = 0b00000000;
    TRISA = 0b00101110;
    ANSELA = 0x00;
    WPUA = 0b00101110;
    IOCAP = 0x00;
    IOCAN = 0x00;
    IOCAF = 0x00;
    APFCON0 = 0x00;
    APFCON1 = 0x00;

    while(1){
    LATA0=1;
    __delay_us(100);
    LATA0=0;
    __delay_us(100);
    }
    }
    Now let’s focus on the Configuration Bits, because something is strange.
    Configuration Word 1 has address 0x8007 and Configuration Word 2 has the address 0x8008.

    If I go in MPLABX-Windows- Pic Memory Views-Configuration Bits I get for Configuration Word 1 the value 0xC7A4 and for Configuration Word 2 the value DDFF.
    If I open the MPLAB CODE CONFIGURATOR plugin then I get for CONFIG1 the value 0x17A4 and for CONFIG2 the value 0x283
    If I open the datasheet of PIC16F1825 and I set on paper each bit, then I get:

    1) Configuration Word 1:
    Bit13 - FCMEN = 0
    Bit12 - IESO = 0
    Bit11 - !CLKOUTEN = 0
    Bit10-9 - BOREN<1:0> = 11
    Bt8 - !CPD = 1
    Bit7 - ! CP = 1
    Bit6 - MCLRE = 0
    Bit5 - ! PWRTE = 1
    Bit4-3 - WDTE<1:0> = 00
    Bit2-0 - FOSC<2:0> = 100
    Then CONFIG1 = 00011110100100 = 0x7A4

    2) Configuration Word 2:
    Bit13 - LVP = 0
    Bit12 - !DEBUG = 1
    Bit11 - Unimplemented = 1
    Bit10 - BORV = 1
    Bit9 - STVREN = 0
    Bit8 - PLLEN = 1
    Bit7-5 - Unimplemented = 111
    Bit4 – Reserved = 1
    Bit3-2 - Unimplemented = 11
    Bit1-0 - WRT<1:0> = 11
    Then CONFIG2 = 01110111111111 = 0x1DFF

Now I already have a problem.
The Configuration Bits done by hand on paper match the last 3 digits of the Configuration Bits done by MPLABX as 7A4 and DFF, but there is 4th digit is different. And the MPLAB CODE CONFIGURATOR plugin is even worse, maybe is using a mask when the final code is generated, because not all the bits are mentioned.

I tried all configuration bit above in Proteus, starting by “Default” and then all the values above.
I trusted more the values done by hand on paper, because they were also confirmed by FlowCode program as in the attached screenshot.
Here is a link with different screenshots and if more is needed I can provide more:

https://goo.gl/yoqKBb

[wraper]

What I decided like 7 years ago is to not bother with proteus MCU emulation. It's nice when it works but a waste of time when you stumble onto a bug. I prefer debugging the code, not MCU model.

[viki2000]

That is true and a good approach, but how did the Proteus staff did it in that screenshot? What kind of trick/setting did they use?
That is what bothers me to find out, because with the real PIC is nothing to debug, everything works fine on the table and with a real oscilloscope.

[viki2000]

An experienced user from http://www.edaboard.com/thread363345.html gave me the right answer:
"click on the processor select properties to get the Edit component box select advanced properties and select clkout on the drop down menu and select enable"
Here is a link with screenshots:
https://goo.gl/9Il5yC