PIC16 MICROPROCESSOR MODEL

Introduction

The PIC16 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 http://www.labcenter.lan/products/vsm/pic16.cfm

Datasheets for these devices can be viewed by placing and editing the device on the schematic and then clicking on the datasheet button from the resulting Edit Component dialogue form. The letter suffix for individual part indicates revisions of the part and we have modelled devices based on a particular revision. For example, the original PIC16C63 only had a basic synchronous serial port (BSSP) but the later PIC16C63A revision incorporates a master synchronous serial port (MSSP).

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

See Also:

  • Getting Started - Compiler Support and Integration.
  • Model Properties (Alphabetical Index)
  • Explanation of Warning Messages
  • Run Time Disassembler

This help file last modified 30th November 2012


HIGH LEVEL LANGUAGE SUPPORT

The PIC16 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.

See Also:

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 compilers 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 in your own IDE and use Proteus VSM only for simulation then several debug formats are available. The process in each case is to produce the required debug file from your compiler and then to 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 PIC16 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 have the extension '.D39' and contain full symbolic debug information including source line address and variable data. To load a UBROF file into the model, you will need to set the program property with the full filename and extension. e.g.

PROGRAM=MYFILE.D39

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.

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 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 will need to set the program property with the full filename and extension. e.g.

PROGRAM=MYFILE.COD

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 this time.

Hitech PICC

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 COF file into the model, you will need to set the program property with the full filename and extension. e.g.

PROGRAM=MYFILE.COF

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.

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

Crownhill Proton Plus

The Crownhill Proton Plus PIC BASIC compiler supports source level debugging with Proteus VSM. The PIC16 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 will need to set the program property with the full filename and '.BAS' extension. e.g.

PROGRAM=MYFILE.BAS

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 PIC Basic Plus.

For more information goto http://www.picbasic.org.

If your compiler does not produce a supported format, remember that you can still use the HEX file as the program property. This will limit debugging capabilities but will simulate just fine.


Properties

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

Program File

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Program File | (None) | Filename | All

This property specifies the name of the program file that will be loaded into the model. The file can be in Intel Hex (.HEX), IAR UBROF (.D39) , ByteCraft COD (.COD) , Microchip Compatible COF (*.COF) or Crownhill Proton Plus (*.BAS) format. The file extension must be specified as this is used to determine the format of the program file.

Processor Clock Frequency

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Processor Clock Frequency | 1M | Hertz | All

This property specifies the clock frequency of the processor. For reasons of efficiency, the clock circuitry (external or internal) is not simulated and the clock rate of the processor is determined solely by this value. This value corresponds to the Q clock frequency, referred to as FOSC in the PIC documentation; the instruction clock is one quarter of this value.

Note that although no clock circuitry is modelled you may still need to set the oscillator type in the configuration word if you want the PIC model to model start-up and wake-up delays.

Program Configuration Word

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Program Configuration Word | 0x3FFF | 14-Bit Integer | All

This property specifies an initial configuration word for the PIC processor.

The configuration word is a set of bits burnt in to program memory location 2007h. The value of this property specifies an initial value for the configuration word but this will be over-ridden by any value specified for location 2007h in the program code (hex) file.

Use this property to supply a configuration word where your Intel Hex file doesn’t contain one.

Note that the meaning of the bits within the configuration word is specific to the PIC device.

Randomise Program Memory

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Randomise Program Memory? | No | Boolean | All

By default the processor’s program memory is initialised to all 1’s (i.e. 3FFFh in every location) 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.

Randomise Data Memory

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Randomise Data Memory? | Yes | Boolean | All

By default, at ‘power-up’, the General Purpose Registers of the processor are initialised with random values.

When this property is assigned No these registers are instead initialised with zeros (i.e. 00h in every location).

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

Model PIC Start-Up Delays?

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Model PIC Start-Up Delays? | No | Boolean | 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 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 at both power-up and on wake-up from sleep.
  2. If the PWTE bit is enabled 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 word) are modelled.

Model PIC Wake-Up Delays?

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Model PIC Wake-Up Delays? | No | Boolean | 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.

Force ADC Breakpoint at Sample Time?

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Force ADC Breakpoint at Sample Time ? | No | Boolean | Devices with 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.

Generate Q Clock on CLKOUT Pin?

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Generate Q Clock on CLKOUT Pin ? | No | Boolean | All

When assigned Yes the model will generate an instruction clock of period Fosc/4 on the OSC2/CLKOUT pin. Note that this will increase the load on the simulator.

Watchdog Timer Period

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Watchdog Timer Period | 18e-3 (18m) | Seconds | All

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

The default value is the nominal 18ms 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.

ADC RC Clock Period

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
ADC RC Clock Period | 4e-6 | Seconds | Devices with 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.

ADC Minimum Acquisition Time

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
ADC Minimum Acquisition Time | 20e-6 | Seconds | Devices with 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.

ADC Sample Delay

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
ADC Sample Delay | 100e-9 | Seconds | Devices with 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.

Code EEPROM Write Delay

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Code EEPROM Write Delay | 10e-3 | Seconds | Devices w/ EEPROM Code Mem

This property specifies the time delay between the start of a write to EEPROM memory (usually by setting the WR bit active) and the time the data is actually written to the EEPROM and the EEIF interrupt bit being 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.

Data EEPROM Write Delay

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Data EEPROM Write Delay | 10e-3 | Seconds | Devices w/ EEPROM Data Mem

This property specifies the time delay between the start of a write to internal EEPROM data memory (usually by setting the WR bit active) and the time the data is actually written to the EEPROM and the EEIF interrupt bit being 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.

Port Pin Low-High Delay

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Port Pin Low-High Delay | 0 | Seconds | 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.

The PIC model performs all port pin transitions synchronous to the start of the instruction cycle plus a delay. This property specifies this delay for a low-to-high transition of the pin.

The default value of zero means that where an instruction causes a transition on an output pin the transition occurs at the very start of the same instruction cycle.

Port Pin High-Low Delay

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Port Pin High-Low Delay | 0 | Seconds | All

This property is similar to the PORTTDLH property above except that it specifies the delay for a high-to-low pin transition.

Initial contents of data EEPROM

Dialogue Form Field | Default Value | Units/Type | Applies to Devices
Initial contents of data EEPROM | (None) | Filename | Devices w/ EEPROM Data Mem

Some PIC devices (e.g. PIC16F83 and PIC16F84) support EEPROM data memory. The PIC model fully implements this functionality 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).


PROPERTIES INDEX

The following is a complete list of all properties supported by the PIC16 model:

  • ADC Minimum Acquisition Time
  • ADC RC Clock Period
  • ADC Sample Delay
  • Code EEPROM Write Delay
  • Data EEPROM Write Delay
  • Force ADC Breakpoint at Sample Time
  • Generate Q Clock On CLKOUT Pin
  • Initial contents of data EEPROM
  • Model PIC Start-up Delays
  • Model PIC Wake-up Delays
  • Port Pin High-Low Delay
  • Port Pin Low-High Delay
  • Processor Clock Frequency
  • Program Configuration Word
  • Program File
  • Randomise Data Memory
  • Randomise Program Memory
  • Watchdog Timer Period


RUN TIME DISASSEMBLER

The PIC16 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:

The disassembly evaluates addresses using the current values of the RP0, RP1 bits (the bank select bits for a direct address) and IRP bit (the bank select bit for an indirect address). Thus the address shown in the run time disassembly is the ‘real’ address that the instruction will be use and may be different to the register/address shown in the source code. For example, the source code:

BCF STATUS, RP1

BSF STATUS, RP0

…

MOVWF PORTA

actually moves the W register in to the TRISA register (as bank 1 is currently selected).

Where the destination of an instruction is the INDF (indirect) register the indirect address is disassembled and displayed as follows:

MOVWF INDF:0x0070

BSF INDF:INTCON,GIE

The first example shows the move of W to the INDF register where the indirect address (taking account of the IRP bit) evaluates to 0x0070. The second example shows setting a bit seven of the INDF register which (again, taking account of the IRP bit) evaluates to the address of the INTCON register. As bit 7 of the INTCON register is the GIE bit this is shown literally.

Where the destination of an instruction is the read or write of general purpose register that actually maps to another bank this is shown as follows:

MOVWF 0x01FF (0x00FF)

In this example, the W register is being moved to location 0x01FF - an address in bank 3. On this particular PIC device, bank 3 addresses are mapped to bank 2 and thus the ‘real’ destination is address 0x00FF.

Note that register mapping is shown literally, so the source code line:

MOVWF 0x010A

is disassembled as:

MOVWF PCLATH

(PCLATH can be addressed at 0x000A, 0x008A, 0x10A and 0x018A)


WARNING MESSAGES

The PIC model may issue a warning message when it detects illegal or ambiguous behaviour. The display of messages is controlled by the values of various Model Properties.

An alphabetical list of all warnings issue by the model are listed below.

ADC conversion clock period <period> is possibly invalid for device clock frequency.

The period of the currently selected ADC clock (ADCSx bits in the ADCON1 register) is possibly out of sepecification for the PIC device. According to the PIC documentation, for correct A/D conversions, the A/D conversion clock (TAD) have a minimum period (conversion time per bit) of 1.6ms.

The PIC model will still perform the conversion as though a valid clock had been selected.

ADC conversion started before 'wait' time has expired following previous conversion or channel change.

An attempt has been made to start a new A/D conversion without waiting the necessary time since the end of a previous conversion. According to the PIC documentation, following the completion or abortion of a A/D conversion there must be 2*TAD (where TAD is the A/D conversion time per bit) delay before the start of a new conversion cycle.

The PIC model will still start the conversion cycle as though the wait time had been met.

Address for read/write of EEPROM data memory (<address>) is outside of the memory (<size> bytes) - address has been wrapped. / Address for read/write of program memory (<address>) is outside of the memory (<size> words) - address has been wrapped.

The address for the read or write of either data EEPROM or program EEPROM memory is not within the size of the memory. As per the PIC documentation, the read or write operation continues with a wrapped memory address.

Attempt to execute illegal opcode (<opcode>) - NOP executed.

An attempt has been made to execute an instruction op-code that does not decode to any known PIC instruction. The value of PC and the op-code itself are indicated. The model executes a no-operation (NOP) instead.

Attempt to read unimplemented memory location <address> ignored.

An instruction has attempted to read a memory location that is not implemented on the PIC device. The model reads a value of zero instead.

Attempt to set EECON1<WR> without 0x55/0xAA sequence to EECON2 has been ignored.

An attempt has been made to begin a write operation on the code or data EEPROM without having first performed a write of 55h and Aah to the EECON2 register. This sequence is required to avoid accidental writes to the code or data EEPROM memory and is documented in the PIC datasheets.

Attempt to write program EEPROM <address> not allowed - memory <start>-<finish> is marked as protected in configuration word.

An attempt has been made to write to the program EEPROM memory at an address that is marked as protected by the flash program memory code protection bits (CPx) in the PIC configuration word.

Attempt to write program EEPROM not allowed - WRT bit in configuration word not set.

An attempt has been made to write to the program EEPROM memory when the flash program memory write enable bit (WRT) in the PIC configuration word is set.

Attempt to write to data EEPROM <address> not allowed - CPD bit in configuration word is not set.

An attempt has been made to write to the data EEPROM memory when the data EEPROM code protection bit (CPD) in the PIC configuration word is set.

Attempt to write to EECON2 without EECON1<WREN> set ignored.

The PIC documentation does not state what (if anything) happens if the sequence for writing the program or data EEPROM memory is not followed exactly.

In order to ensure reliable software development the PIC model ignores writes to the EECON2 register when the WREN bit in the EECON1 register is not set.

Attempt to write unimplemented memory location <address> with <value> ignored.

An instruction attempted to write data to a memory location that is not implemented on the PIC device. The model simply ignores the write operation.

Cannot set EECON1<WR> without first setting EECON1<WREN> in a previous instruction.

An instruction has written the EECON1 register and set the WR bit without the WREN bit being already set. The PIC documentation states that the WREN bit must already be set in a prior instruction before the WR bit is set. Note that setting both WREN and WR in the same instruction is not allowed either.

Configuration word bits <bits> (bits <bitrange>,<value>) and <bits> (bits <bitrange>,<value>) should be identical.

The configuration word contains different bit values in bit locations that are supposed to be identical. The message indicates the bits that are different.

Data written SSPBUF whilst MSSP (in master mode) is active - data has been ignored.

An attempt has been made to write data to the synchronous serial port receive/transmit buffer (SSPBUF) whilst the MSSP is currently receiving/transmitting data. This is a meaningless operation since, at the end of the operation, the received byte is transferred in to the SSPBUF so overwriting any value stored there.

Indirect write of <data> to address <address> is itself an indirect write.

An instruction attempted to write data to the IND (indirection register) register when the FSR register (the indirection address register) addresses the IND register. Such a write operation would be recursive and so does not occur.

OPTION instruction is deprecated for PICxxxxx.

The OPTION instruction has been executed for a PIC processor that doesn’t support the instruction.

For backward compatibility this instructions is implemented by the model. The instruction moves the W register to the OPTION register regardless of any current bank selection.

PC (<address>) is outside program memory for GOTO/CALL instruction. / PC (<address>) is outside program memory for current instruction.

The new value of PC for the current GOTO, CALL or other instruction is an address outside the PIC’s code memory. As per the PIC documentation, the PC register will wrap around the code memory.

PORTA<pin> is not configured as a analog input / PORTE<pin> is not configured as a analog input.

An ADC conversion is about to take place on a channel pin that is not configured as an analogue input. Whilst the PIC documentation states that conversion of a digital input is allowed it doesn’t state what happens for a conversion on a pin that is a digital output. The PIC model will continue with the conversion and will yield a result based on the voltage of the analogue node the pin is connected to.

SPBRG register written with SYNC and BRGH bits both set - this is illegal.

The serial port baud rate generator register SPBRG has been written with the SYNC and BRGH bits in the TXSTA register both set. This is an illegal condition. The PIC model sets the serial baud rate as though only the SYNC bit were set.

Stack overflow executing CALL instruction. / Stack overflow pushing return address of interrupt.

A CALL instruction has been executed or an interrupt cycle has commenced when there isn’t sufficient space on the PIC’s hardware stack to hold the return address. As per the documentation the stack pointer is wrapped so that the return address is pushed on to the stack at the first stack position.

Stack underflow executing RETLW instruction. / Stack underflow executing RETURN instruction. /Stack underflow executing RETFIE instruction.

A RETLW, RETURN or RETFIE instruction has been executed when there is no return address currently held on the PIC’s hardware stack. As per the documentation, the model pops the first entry of the stack (a random value or the value remaining from a previous operation) as the return address and wraps the stack pointer to the end of the stack.

TRISA instruction is deprecated for PICxxxxx. / TRISB instruction is deprecated for PICxxxxx. / TRISC instruction is deprecated for PICxxxxx.

The TRISA, TRISB or TRISC instruction has been executed for a PIC processor that doesn’t support the instruction.

For backward compatibility these instructions are implemented by the model. The instructions move the W register to the TRISA, TRISB or TRISC register respectively regardless of any current bank selection.

Unsupported mode (<mode>) selected in SSPCON.

A value has been written to the SSPCON that selects an MSSP mode that is not modelled by the PIC model.

USART pin '<pin>' is required to be an input but corresponding TRISC bit defines it as an output.

The USART has been configured such that the named PORTC pins is required to be an input but the TRISC register is currently defining that pin as an output.

Voltage references for ADC conversion yield a 0V range (V+ = <V>, V- = <V>).

Depending on the current analogue-to-digital conversion mode the positive voltage reference is either the VREF+ pin or the VDD pin and the negative voltage reference is either the VREF- pin or the VSS pin. This warning indicates that the current voltages as indicated yield a zero range.

Write to ADCON0 register selects ADC channel <channel> - there is no such channel on the PICxxxx device.

A value has been written to the ADCON0 register that selects an ADC channel that is not available on the PIC device. The PIC model will perform a conversion operation on an invalid channel but will always return a value of zero.

Write to EECON1 sets both EECON1<RD> and EECON1<WR> simultaneously. This is ambiguous - both bits will be considered clear.

An instruction has written the EECON1 register such that both the RD and WR bits are being set simultaneously. This is an ambiguous operation and the PIC model behaves as though neither bit is set.

Write to PCLATH register may result in future values of PC that outside of program memory on PICxxxxx device.

A value has been written to the PCLATH register that may result in future values of PC going outside the program memory of the current PIC device.


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