# Bug report — Enhanced Mid-Range PIC (Pic14e) core: reading `const` data from program memory (flash) returns garbage
## Affected
- **Devices:** `p16F1826`, `p16F1827` (core `Pic14e`).
- **SimulIDE:** *(fill in your version, e.g. 1.1.0-SR1)*.
- **Toolchain that exposes it:** Microchip XC8 (any recent version) compiling for the enhanced mid-range core.
## Summary
On the enhanced mid-range core (`Pic14e`), any firmware that reads a `const` object stored in **program memory / flash** (C string literals, `const` lookup tables, etc.) receives **garbage instead of the real bytes**. The garbage is not random noise — it appears to be SimulIDE's **own internal memory** (the returned bytes spell out fragments of the loaded circuit file), which strongly suggests the CPU model reads from an unimplemented / out-of-range address space and ends up reading host data.
The exact same firmware, compiled the same way, runs **correctly on real 16F1826/16F1827 silicon**. The classic mid-range cores in SimulIDE (e.g. `p16F628A`) run the equivalent firmware **correctly**. Only the `Pic14e` core is affected.
## Smoking-gun evidence
A minimal firmware that only initializes a 4-bit HD44780 LCD and prints a C string literal:
```c
LCD_Print("PIC16F1827"); // string literal lives in program memory
```
displays scrambled characters. Among the scrambled output, the LCD literally shows text such as:
```
...labPos="-16,2
B1" IsBus="false
```
`labPos=` and `IsBus="false"` are **attributes of SimulIDE's own circuit (.sim1) file format**. In other words, the firmware's flash-read returned bytes belonging to SimulIDE's internal data structures, not the program's `const` string. This is the clearest possible indication that the `Pic14e` model is servicing the flash-as-data read from the wrong memory.
## Minimal reproduction
1. Compile the two tiny programs below with XC8 for `16F1826` (or `16F1827`).
2. Wire an HD44780 in 4-bit mode to the MCU (RW to GND). Run each hex.
**Program A — reads a `const` string from flash → FAILS (garbage / leaked internal text):**
```c
static void LCD_Print(const char *s){ while(*s) LCD_Data((uint8_t)*s++); }
...
LCD_Print("PIC16F1827");
```
**Program B — writes the same text as immediate literals, no flash read → WORKS (clean text):**
```c
LCD_Data('P'); LCD_Data('I'); LCD_Data('C');
LCD_Data('1'); LCD_Data('6'); LCD_Data('F');
LCD_Data('1'); LCD_Data('8'); LCD_Data('2'); LCD_Data('7');
```
Program A fails, Program B succeeds — on the *same* MCU model, *same* wiring, *same* clock. The only difference is whether the data comes from program memory (flash) or from immediate `movlw` values.
The same failure hits **any** flash `const`: C string literals, `const uint8_t table[]` accessed by index (e.g. a 7-segment font), the DDRAM row-offset table used by an LCD `SetCursor`, etc.
## Likely root cause
On the enhanced mid-range architecture, program memory is visible in the **data address space** (linear/program-memory addressing). XC8 places `const` objects in program flash and reads them by pointing an FSR at the flash address with the high bit set (the `0x8000`-and-up window) and using `moviw` / `INDFn`. It appears the `Pic14e` CPU model in SimulIDE does not implement reads through this program-memory-visibility window, so `moviw`/`INDF` reads that target the `0x8000+` region fall through to an unmapped/host region and return garbage.
Suggested things to check in the `Pic14e` core:
- FSR/`INDFn` reads where the effective address has bit 15 set (`>= 0x8000`) must be redirected to **program memory** (flash), returning the low byte of the addressed program word.
- `moviw`/`movwi` with FSR in the program-memory window.
- Confirm classic mid-range works because XC8 uses `retlw` tables there (which the model already handles), while enhanced XC8 uses the linear program-memory read (which it seemingly does not).
## Secondary issue found in the shipped data files
While investigating, we found a malformed line in the **shipped** `data/PIC/p16F182x/p16F182x_int.xml` (used by both `p16F1826` and `p16F1827`):
```xml
<interrupt name="T1_OVF" enable="TMR1GIE"flag="TMRGIF" priority="1" vector="0x0004"/>
```
Three problems on this one line:
1. **Missing space** between attributes (`"TMR1GIE"flag`) — not well-formed XML.
2. **`flag="TMRGIF"`** references a bit that does not exist; the register file defines **`TMR1GIF`**.
3. **Duplicate interrupt name** `T1_OVF` — it is also used (correctly) two lines below for the Timer1 overflow (`enable="TMR1IE" flag="TMR1IF"`), which is the one the peripheral raises.
Corrected line (this is the Timer1 *gate* interrupt, so it should have a distinct name):
```xml
<interrupt name="T1_GATE" enable="TMR1GIE" flag="TMR1GIF" priority="1" vector="0x0004"/>
```
## Impact
Any enhanced-core firmware that uses string constants or lookup tables (i.e. almost anything with an LCD, a 7-segment font, menu text, etc.) cannot be simulated on `p16F1826`/`p16F1827`, even though it is correct and runs on real hardware.
## Workaround on the firmware side (not a fix)
Emitting all LCD/7-seg text as immediate character writes and replacing `const` lookup tables with `switch` statements (which compile to `retlw`) avoids the flash read entirely and works in SimulIDE. This is only a workaround for the simulator; the proper fix is to implement program-memory-as-data reads in the `Pic14e` core.
