FlashEEPROM Write fault on dsPIC33 – NVMSRCADR not set
Posted: Mon Oct 05, 2026 4:16 pm
Hi FC Team,
I think Ive found a fault in the FlashEEPROM component when used with a dsPIC33EV256GM102.
I called upon 'Uncle Claude' and smashed though a series of test on hardware and it thinks it found the issue and a possible solution.
Cheers, J. I got lost early into the investigation so apologies if claude is talking bull. and whilst his report is comprehensive, its possibly a bit waffle, disregard at your discretion.
Uncle Claude says....
Environment: Flowcode v11.0.2.17, licence 15266180. FlashEEPROM component 4.0, PIC16BIT_CAL_FLASH.c rev 1.0 (08/08/2022), XC16 1.26, DFP 1.5.388.
Symptom: FlashEEPROM Write either resets the controller or stores the wrong data without flagging an error, so a later Read returns values that were never written. In our dsPIc based project this caused a reset after every save, and the wrong state was restored.
Cause: MX_FLASH_WriteInstructionRow (MX_FLASH_TYPE 1) loads 64 TBLWT latches and then starts a row program (NVMOP 0010). On this device the row program takes its data from RAM at NVMSRCADRH:NVMSRCADRL and ignores the latches. The CAL never sets NVMSRCADR, so:
- At its reset value of 0, the write raises an NVM Address Error soft trap (INTCON3 NAE = 1, NVMCON = 0x6102, i.e. WRERR + URERR). Without a trap handler, this appears as an IOPUWR reset.
- If it is left pointing at RAM, flash receives whatever that RAM contains. On test, the component stored another buffer's contents at 0x2800 with no error flag.
The page erase and Read routines work correctly.
Fix, tested on hardware: the MX_UINT32 Data[] array is already in the uncompressed row format, so pointing NVMSRCADR at it and removing the TBLWT loop works:
This gave 64/64 correct words in 1.41 ms with no errors. Looping the existing MX_FLASH_WriteInstruction (double-word) over the row also works. Other dsPIC33E / PIC24E parts that use MX_FLASH_TYPE 1 are probably affected in the same way.
Attached:
- FlowcodeTeam_FlashEEPROM_Report.md: full report with register dumps, terminal logs and some smaller observations (TBLPAG not restored, no WRERR/URERR checks, 24-bit truncation).
I think Ive found a fault in the FlashEEPROM component when used with a dsPIC33EV256GM102.
I called upon 'Uncle Claude' and smashed though a series of test on hardware and it thinks it found the issue and a possible solution.
Cheers, J. I got lost early into the investigation so apologies if claude is talking bull. and whilst his report is comprehensive, its possibly a bit waffle, disregard at your discretion.
Uncle Claude says....
Environment: Flowcode v11.0.2.17, licence 15266180. FlashEEPROM component 4.0, PIC16BIT_CAL_FLASH.c rev 1.0 (08/08/2022), XC16 1.26, DFP 1.5.388.
Symptom: FlashEEPROM Write either resets the controller or stores the wrong data without flagging an error, so a later Read returns values that were never written. In our dsPIc based project this caused a reset after every save, and the wrong state was restored.
Cause: MX_FLASH_WriteInstructionRow (MX_FLASH_TYPE 1) loads 64 TBLWT latches and then starts a row program (NVMOP 0010). On this device the row program takes its data from RAM at NVMSRCADRH:NVMSRCADRL and ignores the latches. The CAL never sets NVMSRCADR, so:
- At its reset value of 0, the write raises an NVM Address Error soft trap (INTCON3 NAE = 1, NVMCON = 0x6102, i.e. WRERR + URERR). Without a trap handler, this appears as an IOPUWR reset.
- If it is left pointing at RAM, flash receives whatever that RAM contains. On test, the component stored another buffer's contents at 0x2800 with no error flag.
The page erase and Read routines work correctly.
Fix, tested on hardware: the MX_UINT32 Data[] array is already in the uncompressed row format, so pointing NVMSRCADR at it and removing the TBLWT loop works:
Code: Select all
NVMCON = 0x4002; NVMCONbits.RPDF = 0;
NVMSRCADRL = (MX_UINT16)Data; NVMSRCADRH = 0;
NVMADR / NVMADRU = Address; __builtin_disi(5); __builtin_write_NVM(); while (NVMCONbits.WR);Attached:
- FlowcodeTeam_FlashEEPROM_Report.md: full report with register dumps, terminal logs and some smaller observations (TBLPAG not restored, no WRERR/URERR checks, 24-bit truncation).