I am having trouble with D-Flash on a mc9s12xeq512caa .
I have a manufacturer build up the board, load an initial program (with a boot loader), test the boards and then pot the boards.
The bootloader is responsible to partition D-Flash the first time the board runs.
The bootloader code is robust and has been proven to function on other similar hardware designs (similar because they also use the 9s12xe.
I am getting a mix of board from the manufacturer that have had d-flash properly partitioned and some that seem to have incorrect partitioning.
When a board has had its d-flash properly partitioned, I can enable RAM emulation, and the d-flash/ram emulation works as I expect it to.
Boards that are not working cannot enable RAM emulation and do not retain their values through a power-cycle.
I am conjecturing it is a problem with partitioning because when I executed a d-flash query, DFPART = 0xffff and ERPART = 0xFFFF .
If I detect that DFPART and ERPART both equal 0xffff, I attempted to issue the partition command (0x20). This command indicates a failure - it returns with a status of 3 (MSGSTAT1 and MSGSTAT0 both equal 0).
I have examined the contents of D-Flash, and it looks like it's all 0xffff 's .
I am not running with a debugger connected.
My questions are :
1. Are there any suggestions on how to diagnose faults or errors associated with d-flash?
2. Is there a way, using software, to reset the board to a factory default state so I can attempt to issue the partition commands with the hardware in the factory default state? (the boards are potted, so there is no way to connect a debugger).
Thanks!
Are you sure you are executing flash partitioning properly? Already partitioned part can be repartitioned only in special mode, which is possible only having BDM debugger. But DFPART = 0xffff and ERPART = 0xFFFF indicate that EEPROM is not yet partitioned and it should be possible to repartition it. Make sure DFLASH is not write protected.
For reference you may try this code, which worked well for me
FSTAT = FSTAT_ACCERR_MASK | FSTAT_FPVIOL_MASK; FCCOBIX = 0; FCCOB = 0x1500; // EEPROM QUERY FSTAT &= FSTAT_CCIF_MASK; while(!(FSTAT & FSTAT_CCIF_MASK)) { } FCCOBIX = 2; if(FCCOB == 0xFFFF) // Is it not partitioned already? { FSTAT = FSTAT_ACCERR_MASK | FSTAT_FPVIOL_MASK; FCCOBIX = 0; FCCOB = 0x2000; // partition FCCOBIX++; FCCOB = 0; //dfprt FCCOBIX++; FCCOB = 1; //epart FSTAT &= FSTAT_CCIF_MASK; while(!(FSTAT & FSTAT_CCIF_MASK)) { } } FSTAT = FSTAT_ACCERR_MASK | FSTAT_FPVIOL_MASK; FCCOBIX = 0; FCCOB = 0x1300; // enable emulation FSTAT &= FSTAT_CCIF_MASK; while(!(FSTAT & FSTAT_CCIF_MASK)) { }
Thank you for teh code snippet. My code base is quite similar.
20 boards or so have been manufactured. They all run the same code. One of the 20 has d-flash/eee Prom/emulation enable problem, the other 19 do not.
It's looking like a defective part or manufacturing process defect/error.
Is there a way to force the micro back to a factory default state?
Are there other registers that can be interrogated for fault status?
Make sure D-flash is blank. Try erasing it.
What does status=3 mean if MSGSTATx are 0? Also what about ACCERR bit? Non zero MSGSTAT would indicate that Dflash is improperly programmed, so that ECC errors are encountered. Erase of whole D-flash should help.
I had some problems with Partitioning D-Flash on S12XEt256 devices. Eventually it was connected with Processor Expert issue.
As I understand you don't use PE's code but anyway maybe this will be of some help for you: