µC EEPROM Library - MxV MicroController Emulation

The MxV µC library simulates an EEPROM sub-system of a typical microcontroller.  The library provides an interface to the simulated EEPROM used for:

•Configuration of EEPROM size

•Static offset adjustment to ease integration with memory-mapped EEPROM

•Flashing and dumping of EEPROM from Motorola S-record (sometimes called S19) or Intel hex ASCII files

•Reading and writing of binary data

•On-disk persistence of EEPROM data

This is how it works:

•The EEPROM emulation uses a binary file on the PC's hard-disk to represent the non-volatile EEPROM data.

•The data is stored in the file eeprom.mxe located in the MxVMC's solution folder (SUT by default).

•Each MxVMC has its own eeprom.exe file.

•SUT EEPROM read and write operations are translated to PC file read and write operations.

•Flash and dump operations use the EEPROM read and write routines to convert between the binary data and an ASCII format (Motorola S-record or Intel hex file).

•Motorola S-record types S1, S2, and S3 are supported.

•The .mxe file has an 8-byte header consisting of the 4-character string "MXE\26" and a 4-byte length (little-endian).

•The "MXE\26" prefix is in-place so a type/cat/ascii read of the file produces the user-friendly string "MXE" instead of printing garbage and beeping - using a text-editor to modify this file will truncate its contents (\1A (26) is the ASCII end-of-file marker)!

•The 4-byte length is the configured size of the EEPROM.  It is possible for the emulation library to capture writes outside of the normal EEPROM bounds which are stored as bytes past this configured size.

•The format of the eeprom.mxe file may change in future releases of MxVDev.

As with all MxV µC sub-systems, the EEPROM sub-system must be initialized before it is used. To initialize the EEPROM sub-system, add a call to:

void MxVuC_EEPROM_Initialize(void)

in your application initialization code or in:

void SUT_Init(void)

in the 'AppIF.c' file.

 
MxVuC_EEPROM_Device MxVuC_EEPROM_Open(mxvU32 length, mxvU32 base_address);

Opening the EEPROM creates the eeprom.mxe file on disk.  If the file exists and the sizes match, the contents are left as-is.  If the file does not exist, then all of the data bytes are initialized to 0xFF.  The offset initialized here is subtracted off subsequent read and write operations to map to the location in the eeprom.mxe file.  For example, if the target's EEPROM was memory-mapped and located at address 0x8000, then we use 0x8000 as the offset when opening the EEPROM for emulation. The emulated EEPROM is not memory-mapped and indexing starts at 0.

The MxVuC_EEPROM_Flash function is used to set EEPROM to an initial state and is usually done prior to a test sequence. This could be used to set up a configuration for the VMC based on actual calibrations from a vehicle EEPROM dump.

The MxVuC_EEPROM_Dump function is used to read the final state of EEPROM. It is typically done after completion of a to a test sequence. After testing, the dumped EEPROM data could be used to program an actual part for testing in the vehicle.

Use the parameters to specify Intel hex or S-record file format.

enum MxVuC_EEPROM_FileType {

  MxVuC_EEPROM_INTEL_HEX = 0,

  MxVuC_EEPROM_S_RECORD = 1,

};

mxvBool MxVuC_EEPROM_Flash(MxVuC_EEPROM_Device, const char* file_path, enum MxVuC_EEPROM_FileType);

mxvBool MxVuC_EEPROM_Dump(MxVuC_EEPROM_Device, const char* file_path, enum MxVuC_EEPROM_FileType);

Typically once the EEPROM is opened it is flashed with a known-working-good .hex file to ensure consistent simulation behavior.  The flashing process can be handled two ways:

•Broken out as a separate task to allow test-cases to control when (and if) EEPROM flashing occurs

•Placed into the SUT_Init task to guarantee the EEPROM is always flashed the same way

Currently, dumping the EEPROM is best achieved by using a variable length message that contains the dump file name along with a message signal-handler to actually dump the EEPROM.  EEPROM dumps can then be scheduled and configured in the test cases so multiple dumps can be captured for various test-cases.

The MxVuC_EEPROM_Read and MxVuC_EEPROM_Write functions are typically used by the application code during a test.

//Return true on success, false if the operation fails and sets a MxVuC_FatalError

mxvBool MxVuC_EEPROM_Read(MxVuC_EEPROM_Device, unsigned char* dest, mxvU32 offset, mxvU32 length);

mxvBool MxVuC_EEPROM_Write(MxVuC_EEPROM_Device, const unsigned char* src, mxvU32 offset, mxvU32 length);

These two binary read and write routines need to be integrated with the target code.  These routines return false if any portion of the read or write is outside the configured EEPROM length.

You can access the EEPROM buffer directly by creating an EEPROM_DATA Signal. This enables you to view the EEPROM data during a test, but it does not simulate normal EEPROM reading.

Add a line similar to the following to the PortDefs array in the AppIF.c file:

 {"EEPROM_DATA",  &EEPROM_DATA,  OP_MES,  MM_EEPROM_LENGTH*MMBYTE, 0, 0, 1, 0,  MMNULL,   MMNULL, 1, UNSIGNED},

This creates a message output port on the VMC Transform. See the AppIF.c file in the TurnDoor sample project for an example. After you build the MSVS project, you can export the port, and add the Signal to TestCases.