All emulation header boards have a special -ME2 device mounted on them. In some cases the -ME2 silicon has errata, i.e., the device does not operate as expected due to silicon issues.
When the input threshold control for RE0 is configured for TTL, the CCP3 capture input is ignored. This applies to silicon revision C0 of the devices listed below.
Work-around: Use ST Threshold.
Hardware Breakpoint Issue
When using this emulation header with C language or Assembly language code, hardware breakpoints will not function past memory locations 0x3FF for the emulated devices listed below.
- PIC16F1936, PIC16LF1936
- PIC16F1937, PIC16LF1937
- Software breakpoints for these four parts could be used (with the caveat that software breakpoints do not offer the advanced capability of hardware breakpoints).
- Any function(s) that need to be debugged with hardware breakpoints could be explicitly (and temporarily) located in the program memory area below 0x400 until the function is properly debugged, as shown in Example 1 and 2 below.
Example 1: In C language for the MPLAB® XC8 C compiler, this can be done with the @ address construct as follows, which will locate function_1 at program memory base address 0x200.
Example 2: In assembly language for the MPASM™ assembler, this can be done with the CODE directive as follows, which will locate function_1 at program memory base address 0x200.
Trigger In/Halt during Multi-Cycle Instruction Processing
For some -ME2 devices, the arrival of a trigger-in/HALT event during processing of a multi-cycle instruction may cause the emulator to fail to properly execute/complete the instruction before coming to a HALT. This applies to the following -ME2 products:
Microchip Technology acquires Atmel