Proteus Simulator and PIC16F1825 CLKOUT

Discussion in 'Programmer's Corner' started by viki2000, Jan 17, 2017.

  1. viki2000

    Thread Starter Member

    Jun 18, 2013
    11
    1
    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?

    clockout.jpg
     
  2. spinnaker

    AAC Fanatic!

    Oct 29, 2009
    6,852
    3,007
    With no code. No one is going to be able to answer your questions.
     
  3. viki2000

    Thread Starter Member

    Jun 18, 2013
    11
    1
    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:

    #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
     
  4. spinnaker

    AAC Fanatic!

    Oct 29, 2009
    6,852
    3,007
    You mentioned RA4 in your first post but your code toggles RA0. This is confusing.

    Please restate exactly what you are trying to do.
     
  5. JohnInTX

    Moderator

    Jun 26, 2012
    3,361
    1,683
    @viki2000
    I agree with you and your scope, the clock output should be on with the config bits set and port inits that you have. I don't know why Proteus isn't showing that.

    The disparity between your hand-calculated config values and what XC8 generates probably has to do with what XC8 shows for the unused bits in the 14bit config words. When erased, the config bits are '1'. Unused bits should also be '1'. That was not always the case for all PICs and tools. At any rate, the significant bits seem OK for what you want to do. I get the same values when I replicate your config in XC8. The masks for the unused bits in CONFIG1 and CONFIG2 are C000h and C8ECh respectively. If you OR your hand-coded values with those masks, you get what XC8 and the chip's programming reference says is right.

    As for Proteus, I don't know. I'm a wire and solder kind of guy.

    Good luck!

    EDIT: for grins you might try setting TRISA.4 to an input. The CONFIG bits override that in the silicon but maybe Proteus thinks you've set it as a port output bit. You also might monkey with the unused config bits in your Proteus build. Interesting that that thread is locked..
     
    Last edited: Jan 17, 2017
  6. viki2000

    Thread Starter Member

    Jun 18, 2013
    11
    1
    @spinnaker
    Yes, my code toggles RA0 just as simple test program.
    It could have been any other pin except RA4.
    We can use a simple infinite empty loop like:
    while (1);

    The program is not important.
    What I am trying to do is to get the internal oscillation frequency at one pin.
    By setting CLKOUT bit 11 in Configuration Word 1 we are able to obtain at RA4 pin (named also CLKOUT or OSC2) the Fosc/4 which is 8MHz.
    So you see I can get a rectangular signal, a clock signal at pin 3 (RA4) only by redirecting internal oscillator 32MHz divided by 4.
    And is fine with a real clock, but not in simulation with Proteus, at least not with my settings.
    My problem is that technical support from Proteus shown a screenshot proving that works and I have no idea how they did it.


    @JohnInTX
    My problem is to know how the guys from Proteus did it.
    They did not use the virtual digital oscilloscope, but they used a counter/frequency meter and a digital graph with Spice settings.
     
  7. viki2000

    Thread Starter Member

    Jun 18, 2013
    11
    1
    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
     
    JohnInTX likes this.
  8. JohnInTX

    Moderator

    Jun 26, 2012
    3,361
    1,683
    Perfect. Thanks for the update.
     
Loading...