Introduction

Introduction

The PIC18 series model models the behaviour well over 100 microcontrollers from Arizona Microchip™. We are constantly updating our model support for this family and you can find the latest list of supported variants on our website at https://www.labcenter.com/buy-vsm/ and selecting the Microchip Logo and clicking on the Information button on PIC18.

Datasheets for these devices can be viewed by clicking on appropriate device name, above. Note that there are a number of Errata datasheets for these devices which are are available directly from Arizona Microchip’s website: http://www.microchip.com/.

Please check the Arizona Microchip website for the latest information and errata on particular devices.

See also

  • Getting Started - Compiler Support and Integration.

  • USB Simulation with Proteus VSM for PIC18

  • Main Limitations

  • Specifying The Processor Clock

  • Model Properties (Alphabetical Index)

  • Run Time Disassembler

This help file last modified 02nd February 2022.


High Level Language Support

HIGH LEVEL LANGUAGE DEBUGGING

The PIC18 model can load program files in many debug formats as well as the exact same hex file that you would program a physical device with. The advantage of using one of the debug formats is that they contain symbolic debug information (source code, variables,etc.) which enables you to not only simulate your system in Proteus but also to single step debug. The following is a summary of supported formats with basic instructions on how to get started.

Proteus VSM Tutorial

VSM Studio IDE

By far the easiest way to get set up for simulating in Proteus is through the integrated VSM Studio IDE. This tool is integrated into the Proteus Design Suite, will detect installed compilers and you can directly download and install additional tools from inside the IDE.

Installed compiled are automatically configured by VSM Studio to produce debugging output suitable for driving Proteus VSM. If however you need to make changes all of the compiler options are made available in the Project Setting dialogue inside VSM Studio.

Once you have written some code and compiled your schematic will automatically be programmed with the firmware. You can then both simulate and single step debug inside VSM Studio. Active popups let you add 'schematic snippets' to VSM Studio so that you can view and interact with the simulation while debugging the source code.

See Also:

VSM Studio Tutorial (New Project)

Schematic Only

If you choose or prefer to work with your own IDE and use Proteus VSM only for simulation then you need to manually tell the schematic microcontroller which program to run. Several debug formats are available and the process in each case is:

  • Produce the required debug file from your compiler.

  • Load this file as the PROGRAM property in the Edit Component dialogue form of the PIC microcontroller.

If in doubt, opt for COFF. Almost all compilers in the PIC world will generate a COFF file when compiling code for PIC18 variants.

IAR UBROF Loader

The UBROF format is owned by IAR Systems and is a common symbolic debug format used across the entire range of IAR compiler products.

UBROF files for the PIC 18 have the extension '.D49' and contain full symbolic debug information including source line address and variable data. To load a UBROF file into the model, you need to tag-and-edit the PIC18 schematic part (to display the Edit Component dialogue form) and then specify the full filename including the D49 extension in the Program File field:

Note that the UBROF file contains absolute paths to the 'C' source files, and problems may arise if the project is moved from one directory to another. The solution is to re-compile the project within IAR workbench.

You must set the linker options to generate UBROF 8 output - Proteus VSM cannot load files that use later versions of the UBROF format.

ByteCraft COD Loader

The COD format is owned by Bytecraft Limited and is a common symbolic debug format used across their full range of cross compilers. It is also supported by the MP-LAB v5 environment and used by other compiler vendors such as CCS and Hitech.

COD files have the extension '.COD' and contain limited symbolic debug information only. To load a COD file into the model, you need to tag-and-edit the PIC18 schematic part (to display the Edit Component dialogue form) and then specify the full filename including the COD extension in the Program File field:

Note that VSM COD file loader is able to extract source line number information only; the documented information concerning variable locations and types is incomplete and we are therefore unable to implement a variables window for this format at this time.

Hitech PICC and PICC Lite

Hitech ‘C’ can now generate output in the Microchip variant of the COFF format as used by MPLAB. The PICC Lite compiler is available as a free download provides an excellent introduction to ‘C’ programming on the PIC.

COFF files contain full source line number and symbolic debug information. To load a COFF file into the model, you need to tag-and-edit the PIC18 schematic part (to display the Edit Component dialogue form) and then specify the full filename including the COF extension in the Program File field:

Note that the COFF file contains absolute paths to the 'C' source files, and problems may arise if the project is moved from one directory to another. The solution is to re-compile the project.

For more information and compiler downloads visit http://www.htsoft.com.

Crownhill Proton Development Suite

Crownhill’s Proton Development Suite supports source level debugging with Proteus VSM. The PIC18 model loads the BASIC program itself and also the LST file produced by the compiler in order to establish the memory address of source code lines and program variables.

To load a compiled program file into the model, you need to tag-and-edit the PIC18 schematic part (to display the Edit Component dialogue form) and then specify the full filename including the BAS extension in the Program File field:

Note that the list file can contain absolute paths to the BASIC source files, and problems may arise if the project is moved from one directory to another. The solution is to re-compile the project within the Proton Development Suite.

For more information go to http://www.picbasic.org.


MAIN LIMITATIONS

The PIC 18 model has a number of key limitations:

  • The External Memory Interface (EMI) of devices such as the PIC18F8X20 is not modelled. These devices can only be modelled when the PMx configuration bits select the Microcontroller Mode (MC) mode of operation. Specifically, the Microprocessor Mode (MP), Microprocessor with Boot Block Mode (MPBB) and Extended Microcontroller Mode (EMC) modes are not supported.
  • Power Managed Modes is not modelled. Specifically, the use of IDLEN and SCS/SCSx bits in the OSCCON register to switch oscillator sources and the behaviour of the SLEEP command is not modelled. The SLEEP command always puts the processor in to full sleep mode.

    This limitation is largely due to poor documentation on how the power managed modes actually affect peripherals.
  • Brown-out detection and High-Low Voltage Detect (HLVD) is not modelled.
  • The Internal/External Switch Over (IESO configuration bit) and the Fail Safe Clock Monitor (FSCM configuration bit) are not modelled.
  • All external signal timing is approximate and is generally accurate to one instruction cycle.
  • The ECAN module of the PIC18F6680 and PIC18F6685 is not currently modelled.
  • The SPP (Streaming Parallel Part) of the USB variants is not currently modelled.
  • Isochronous USB transactions in the USB variants is not currently modelled.
  • RELEASE bit effects and Brown-out wakeup from Deep Sleep mode are not modelled.
  • The external programming interface (PGC/PGD pins) are not modelled.
  • The DMA features for SPI2 PGD pins are not modelled.

The model generates a warning or error whenever an attempt is made to use an un-modelled feature of the device.

Additionally, In the PIC18FxxQ10 and xxK40 variants

  • ICSP programming is not supported
  • Fail-Safe Clock Monitor is not modelled
  • GPIO input threshold control is not implemented
  • SPI transfer over VSPI uses FOSC-based clocking only
  • I2C SDA Hold Time Selection bit is not implemented
  • PPS does not validate an incorrect remapping


Model Properties (Alphabetical Index)

MODEL PROPERTIES

The PIC model can be configured via a number of properties, described below.

Not all properties are meaningful for a given PIC device and only those properties that are meaningful for a particular device will be shown on that device’s Edit Component dialogue form.

Alphabetical list of all properties

Undocumented model properties

_________________________________________________________________________________________

Dialogue Form Field : Program File

Default Value : (None)

Units/Type : Filename

Applies To Devices : All

This property specifies the name of the program file that will be loaded into the model and must include a file extension that identifies what sort of file is being loaded. At the time of writing, the support extensions are:

.HEX The file is Intel Hex format.

.D49 The file is IAR UBROF format.

.UBF The file is IAR UBROF format.

.COD The file is or ByteCraft COD format.

.BAS The file is or Crownhill Proton Development Suite format.

Note that with Intel Hex files you will only get assembly level debugging support if you have used a some sort of data extraction to (DDX) to extract information from an associated list file in to our own SDI format. A tool, MPASMDDX.EXE, is supplied which will process an MPASM list file and produce suitable output. For other assemblers you will need to create a similar tool – please contact Labcenter Electronics for information on the format of SDI files.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Processor Clock Frequency

Default Value : 4M

Units/Type : Hertz

Applies To Devices : All

This property specifies the clock frequency of the processor when the FOSCn configuration bits specify an external oscillator mode (LP, XT, HS, RC, EC, ECIO, HSPLL or RCIO).

For a more information see Specifying The Processor Clock format

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Dump SFR Values On Reset?

Default Value : No

Units/Type : Boolean

Applies To Devices : All.

If this property is defined Yes then the PIC model will dump the values in all Special Function Registers (SFRs) to the simulation log whenever the model is reset.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Force ADC Breakpoint at Sample Time?

Default Value : No

Units/Type : Boolean

Applies To Devices : Devices with the ADC peripheral.

The nature of the analogue simulation means that it runs in small time steps and that the voltage on a node is only known at fixed time intervals. The time step changes dynamically during simulation to ensure accuracy is maintained.

In general any ADC conversion operation in the PIC will result in a sample point (in time) that lies inside such an analogue ‘step’ and the PIC model uses linear interpolation to calculate the voltage at the required ADC sample time. This is more than accurate enough for most purposes since the analogue simulator ensures that nothing much interesting will have occurred ‘

inside’ the time step.

However, if this property is set to Yes then the PIC model will force an analogue computation at the required sample time. This may improve accuracy but the simulation load will increase since an extra analogue simulation is performed.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Model PIC Start-up Delays?

Default Value : No

Units/Type : Boolean

Applies To Devices : All

In normal operation the PIC has a number of built-in delays at power-on reset and on wake-up from sleep:

1. If the PIC is configured (by its configuration words) to use its built-in RC oscillator as the processor clock then the Oscillator Start-up Timer (OST) produces a 1024 Q-clock cycle delay at both power-up and on wake-up from sleep.

2. If the PWRTEN bit is enabled (the bit is active low) in the configuration word then a further 72ms delay is introduced at power-up.

By default the PIC model does not model these delays as they serve no useful purpose for most simulations. However if this property is assigned Yes then all power-up start-up delays (where configured by the configuration words) are modelled.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Model PIC Wake-up Delays?

Default Value : No

Units/Type : Boolean

Applies To Devices : All

In normal operation where a PIC is configured (by its configuration word) to use its built-in RC oscillator as the processor clock then the Oscillator Start-up Timer (OST) produces a 1024 Q-clock cycle delay when the processor comes out of sleep.

By default the PIC model does not model this delay as they serve no useful purpose for most simulations. However if this property is assigned Yes then the OST wake-up delay is modelled.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Generate Q-clock On CLKOUT Pin?

Default Value : No

Units/Type : Boolean

Applies To Devices : All

When assigned Yes the model will generate an instruction clock of period Fosc/4 on the RA6/OSC2/CLKO pin.

Note that if the model is configured (via the configuration words) to use this pin as I/O (e.g. the FOSCx bits specify an RCIO oscillator) then trying to enable an output clock will cause a warning to be issue in the simulation log.

The generation of an instruction frequency clock may significantly load the simulator with a corresponding drop in simulation performance.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Halt on HALT Instruction?

Default Value : No

Units/Type : Boolean

Applies To Devices : All

The MPASM assemblers from Arizona Microchip™ will assemble the HALT instruction as op-code 0001h. On a real PIC this executes as a NOP (no-operation) instruction.

If this property is assigned Yes then the execution of a HALT instruction will halt the simulation with a suitable message in the simulation log.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Treat Warnings As Errors?

Default Value : No

Units/Type : Boolean

Applies To Devices : All

By default, unusual behaviour or execution of the model will result in one or more warnings being placed in the simulation log file. These do not affect the simulation run and will not be reported until the end of the simulation.

If this property is assigned Yes then any warning generated by the model will be issued as an error so causing the simulation to be halted at the point the warning is issued.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Randomize Program Memory?

Default Value : No

Units/Type : Boolean

Applies To Devices : All

By default the processor’s program memory is initialised to all 1’s (i.e. FFh in every byte) before the program code is loaded.

When this property is assigned Yes then the processor’s program memory is instead filled with random values before the program is loaded.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Randomize Data Memory?

Default Value : No

Units/Type : Boolean

Applies To Devices : All

By default, at ‘power-up’, the data memory (General Purpose Registers) of the processor are initialised with zeroes.

When this property is assigned Yes these registers are instead initialised with random values.

Note that the Special Function Registers (e.g. STATUS, INTCON, TRISA, etc.) are not affected by this property. These registers are always initialised to their correct power-up values as defined by the PIC datasheets.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Randomize Stack Addresses?

Default Value : No

Units/Type : Boolean

Applies To Devices : All

By default, at ‘power-up’, all stack locations of the processor are initialised with zeroes.

When this property is assigned Yes these locations (with the exception of the first) are instead initialised with random values. The zero’th stack location is always zero as this is a function of the PIC hardware.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Warn If Executing Illegal Op-codes?

Default Value : Yes

Units/Type : Boolean

Applies To Devices : All

When assigned Yes (the default), this property causes the model to issue warnings for any attempt to execute an illegal op-code (that is, a program location containing a value that does not decode to a specific PIC instruction). As per the PIC documentation all such op-codes execute as a no-operation (NOP) instruction.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Enable Watchdog Timer?

Default Value : Yes

Units/Type : Boolean

Applies To Devices : All

By default the watchdog timer is enabled disabled purely through the normal PIC control bits: the WDTEN bit in the configuration memory and/or the SWDTEN bit in the WDTCON register.

However, it sometimes useful to be able to quickly override the normal device behaviour. If this property is assigned No then the watchdog timer is disabled regardless of either the settings of the configuration words and/or any runtime setting of the SWDTEN bit.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Code/IDLOCs Memory Erase Delay

Default Value : 2E-3 (2m)

Units/Type : Seconds

Applies To Devices : Devices with EEPROM code memory

This property specifies the time delay for the erase of program or user IDLOCs memory.

The erase cycle is instigated by programming the EECON1 register. Once the erase cycle begins, processor execution stalls for the specified delay.

The default value is the nominal 2ms specified by the PIC documentation. However as the period varies from one device to another as well as with temperature it may be useful to specify an alternative period.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Data EEPROM Write Delay

Default Value : 10E-3 (10m)

Units/Type : Seconds

Applies To Devices : Devices with EEPROM data memory

This property specifies the time delay for the write of a value to the EEPROM data memory.

The write cycle is instigated by programming the EECON1 register and requires the specified time to perform the write succesfully. At the end of the write delay period, the WR bit will be cleared the EEIF interrupt bit set. If the write process is interrupted (for example, by processor reset) the WERR bit will be set.

The default value is the nominal 10ms specified by the PIC documentation. However as the period varies from one device to another as well as with temperature it may be useful to specify an alternative period.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : ADC RC Clock Period

Default Value : 4E-6 (4ì)

Units/Type : Seconds

Applies To Devices : Devices with the ADC peripheral.

This property specifies the period of the PIC model’s Analogue-to-Digital Converter (ADC) module’s RC clock. The value must be in seconds.

The PIC documentation states that this clock will normally have a period between 2ìs and 6ìs and so the default value is 4ìs.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : ADC Minimum Acquisition Time

Default Value : 20E-6 (20ì)

Units/Type : Seconds

Applies To Devices : Devices with the ADC peripheral.

This property specifies the minimum acquisition time for the PIC’s Analogue-to-Digital Converter (ADC) module. The value must be in seconds.

The PIC model does not model the behaviour of an incorrectly acquired analogue input but issues a warning whenever the minimum acquisition time has not been met.

The default value is rule-of-thumb approximation based on likely temperature, capacitance, etc.

Note that the minimum acquisition time may be greater than the value specified here as a result of additional delays specified in the documentation.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : ADC Sample Delay

Default Value : 100E-9 (100n)

Units/Type : Seconds

Applies To Devices : Devices with the ADC peripheral.

This property specifies the delay between the setting of the GO/DONE bit and the disconnection of the holding capacitor from the analogue input. This is the time point at which the PIC model measures or approximates the voltage on the analogue input.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Watchdog Timer Timebase

Default Value : 4E-3 (4m) / 18E-3 (18m)

Units/Type : Seconds

Applies To Devices : All

This property specifies the period of the PIC model’s watchdog timer clock.

The default value is the nominal value for the device specified in the PIC documentation. This is usually 18ms for the older devices with a 8-to-1 post-scaler and 4ms for newer devices with a 32768-to-1 post-scaler. However as the period varies from one device to another as well as with temperature it may be useful to specify an alternative period.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Port Delay From Start Of Instruction

Default Value : 3 * Q-clock period

Units/Type : Seconds

Applies To Devices : All

With the real PIC device port pin transitions occur on a particular Q-clock cycle and therefore part way through an instruction cycle. The actual pin timing depends on the pin, the module that is driving it, as well as the electrical characteristics of the circuit.

This property specifies the delay from the start of an instruction cycle to a port pin changing as a result of a change in the LAT or TRIS bits for the port. The value only applies to normal port operations – port pins configured for use by a peripheral will use alternative timing.

The default value places the port pin transition in the third Q cycle of the instruction.

Back to Alphabetical list of all properties.

_________________________________________________________________________________________

Dialogue Form Field : Initial Contents Of Data EEPROM

Default Value : (None)

Units/Type : Filename

Applies To Devices : Devices with EEPROM data memory

The PIC model fully implements the data EEPROM functionality of the PIC 18 devices including the persistence of EEPROM data between simulation runs. The mechanism works as follows:

1. The very first time a simulation is run on a new design, the PIC data EEPROM is initialised to all 1’s (that is, all locations read FFh).

2. If the Initial contents of EEPROM property is not blank the specified file is opened as a binary file and it’s contents are used to initialise the PIC data EEPROM. If the file contains less data than the EEPROM size then the remaining data EEPROM bytes remain initialised as all 1’s. If the file contains more data than the EEPROM size then the excess data in the file is ignored.

3. At the end of a simulation the contents of the PIC data EEPROM (including any changes made to it by the executed PIC code) are preserved by ISIS and saved with the design if the design is saved.

4. For all subsequent simulations the PIC data EEPROM is re-initialised with the data saved at the end of the previous simulation.

It is important to note that the PIC data EEPROM is only initialised (first to all 1’s and then from any specified data file) for the first simulation run; thereafter the memory is always re-initialised from the previous simulation run’s data. You can use Reset Persistent Model Data command on the Debug menu in ISIS to reset the persistent model data for all models (not just the PIC model).

Back to Alphabetical list of all properties.


MODEL PROPERTIES INDEX

The following is a list of all properties available when editing a PIC18 schematic part:

ADC Minimum Acquisition Time

ADC RC Clock Period

ADC Sample Delay

Code/IDLOCs Memory Erase Delay

Data EEPROM Write Delay

Enable Watchdog Timer?

Force ADC Breakpoint at Sample Time?

Generate Q-clock on CLKOUT Pin?

Halt on HALT Instruction?

Initial Contents Of Data EEPROM

Model PIC Start-up Delays?

Model PIC Wake-up Delays?

Port Delay From Start Of Instruction

Processor Clock Frequency

Program File

Randomize Data Memory?

Randomize Program Memory?

Randomize Stack Addresses?

Treat Warnings As Errors?

Watchdog Timer Timebase

There are also a number of ‘undocumented ’ that may be useful to advanced users.


RUN TIME DISASSEMBLER

The PIC18 series model includes a run-time disassembler. The model disassembles the current instruction (that is, the instruction at the current value of PC, the next instruction to be executed) and displays the disassembly at the top of its ‘Registers’ pop-up.

This runtime disassembly has a number of useful functions:

  • Addresses and bit names are always shown textually for clarity.
  • The disassembly evaluates addresses using the access bit, BSR register, etc. Thus the address shown in the run time disassembly is the ‘real’ address that the instruction will use and may be different to the register/address shown in the source code.
  • Where the destination of an instruction is one of the indirection registers (e.g. INDF0) the indirect address is determined and displayed in brackets:

    MOVWF INDF0 (0x0070)BSF INDF0 (INTCON),GIE

    The first example shows the move of W to the INDF register where the indirect address (taking account of the INDF register) evaluates to 0x0070. The second example shows setting a bit seven of the INDF0 register which (again, taking account of the register value) evaluates to the address of the INTCON register. As bit 7 of the INTCON register is the GIE bit this is shown literally.
  • · When extended instruction mode (the XINST bit in configuration memory is enabled) GPR locations in the access bank memory locations are shown disassembled from the FSR2 base address. For example, if FSR2 is 0x0100 then the instruction:

    MOVWF 0x10,F

    will be shown disassembled as:

    MOVWF 0x0110,F
  • The GIE/GIEH and PEIE/GIEL bits are displayed according to the current state of the interrupt priority enabled (IPEN) bit. When interrupt priorities are enabled these bits displayed as GIEH and GIEL and, when disabled, as GIE and PEIE.
  • Where the processor is about to execute a return from subroutine, the return address is shown.
  • Where the processor is held in reset, this is shown.
  • Where the processor is held in power-down sleep mode, this is shown.
  • Where the current instruction doesn’t execute (because the processor is executing a forced no-operation cycle, for example, as part of servicing an interrupt) this is shown.


SPECIFYING THE PROCESSOR CLOCK

See the summary

The PIC model determines the oscillator mode according to the FOSCn configuration bits:

  • The older PIC devices (e.g. the PIC18F452) have a eight oscillator modes: LP, XT, HS, RC, EC, ECIO, HSPLL (also known as HS4) and RCIO. All of these modes specify an external clock source from some sort of clock circuitry connected to the OSC1/CLKI pin as well as, possibly, the OSC2 pin.
  • The newer PIC devices (e.g. the PIC18F1220) have an additional two additional modes: INTIO1 and INTIO2. Both of these modes specify the use of an internal clock source, selected via a value in the OSCCON register.

Where the FOSCn configuration bits specify an external clock source, the PIC model ignores any circuitry connected to the OSC1/CLKI and OSC2 pins and instead uses Processor Clock Frequency property value (specified by tagging and editing the PIC device on the schematic) to configure an internal clock. This is done for efficiency - attempting to simulate an external clock generating millions of clock edges per second is inefficient and slows the simulation down dramatically.

The value specified for the Processor Clock Frequency should be the same as the clock frequency that would be applied to the CLKI pin of the real device. For most oscillator modes the value of this property is the same as the Q-clock frequency, referred to as FOSC in the PIC documentation. For the HSPLL oscillator configuration, the Q-clock frequency will be taken as four times the value specified so mimicking the internal PLL behaviour of the real device.

Where the FOSCn configuration bits specify an internal clock source, the PIC model ignores any circuitry connected to the OSC1/CLKI and OSC2 pins as well as the Processor Clock Frequency property and instead uses values in the OSCCON and OSCTUNE registers to determine the Q-clock frequency.

The instruction clock frequency is always one quarter of the Q-clock frequency.

Again, for efficiency, the processor doesn’t generate a Q-clock on the CLKOUT pin unless the Generate Q-clock On CLKOUT Pin property is set to Yes.

Note that whilst clock circuitry connected to the OSC1/CLKI and OSC2 pins is ignored, these pins will be modelled as normal port pin(s) (on appropriate devices) for the appropriate oscillator mode. For example, setting the FOSCn bits to specify an ECIO oscillator mode means that circuitry connected to the OSC1/CLKI pin is ignored but that the RA6/OSC2 pin will behave as normal port pin.

To summarise:

  • If the FOSCn configuration bits specify the oscillator mode to be LP, XT, HS, RC, EC, ECIO, or RCIO then the processor clock frequency is taken from the Processor Clock Frequency field. The Q-clock frequency will be the frequency specified and the instruction clock frequency will be one quarter of it.
  • If the FOSCn configuration bits specify the oscillator mode to be HSPLL (also known as HS4) then the processor clock frequency is taken from the Processor Clock Frequency field. The Q-clock frequency will be four times the frequency specified and the instruction clock will be same as the value specified.
  • If the FOSCn configuration bits specify the oscillator mode to be INTIO1 or INTIO2 then the Processor Clock Frequency is ignored (it should be left blank) and the Q-clock and instruction clock frequencies are determined purely by the values in the OSCCON and OSCTUNE registers.

The simulation log always indicates the clock frequency the processor is running at.


Bad or Unsupported Program

Bad or Unsupported PROGRAM Property

The program filename extension is missing or is of an unsupported type. The supported extensions are

  • HEX
  • COF
  • COD
  • D39 (UBROF)
  • BAS.

See Also:

High Level Language Support


Program Property Not Specified

In order to load your program into the PICMicro™ microcontroller model, you must enter the compiled program filename into the PROGRAM field of the edit component dialog form. The program filename will be a HEX, COF, COD, UBROF or BAS file.

See Also:

High Level Language Support


Proteus USB Simulation

USB SIMULATION WITH PIC18

Introduction

Proteus VSM USB simulation represents the worlds first schematic based embedded USB simulation engine and is currently supported with the following microcontroller variants:

PIC18F2450, PIC18F2455, PIC18F2458, PIC18F2550, PIC18F2553, PIC18F4450, PIC18F4455, PIC18F4458, PIC18F4550, PIC18F4553.

Datasheets for these devices can be viewed by clicking on appropriate device name, above. Note that there are a number of Errata datasheets for these devices which are are available directly from Arizona Microchip’s website: http://www.microchip.com/.

Please check the Arizona Microchip website for the latest information and errata on particular devices.

USB Simulation in Proteus is enabled by installing the Labcenter USB drivers and then using one of the supported USB microcontrollers. Analysis and debugging of USB traffic is enabled via the purchase of the USB Transaction Analyser – a seperately licensed product.

For example, if you had a licence for Proteus VSM for PIC18 then you would be able to enable USB simulation and could simulate PIC18 USB designs. In order to monitor or debug USB communications however, you would need to purchase the Proteus USB Transaction Analyser.

See also

Getting Started : USB Simulation