• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PIC32MX EEPROM emulation

Status
Not open for further replies.
My background is 15 years with PIC12-18's and I am now moving to a PIC32MX795F512L for a specific project but how on earth do you get the EEPROM emulation to work at 0xBD008000 as the notes suggest ???

Data EEPROM in these devices must be THE worlds worst thing I have ever come across with Microchip.

Help please....
 

Noggin

Member
Actually I found the Emulated EEPROM in the PIC32 to actually be quite nice. I'm not sure exactly what problem you are having. Are you trying to specify the address to be at 0xBD008000 or are you under the impression that you have to make it be at that address? In general, you just need to compile the code, include the header file, and make the calls. The emulated EE will just go wherever it can (it just has to be on a page boundary.) You'll need to call the function DataEEInit() once when the processor starts up. Also, you need to write to the emulated EEPROM before you can read from it.

I have code around here somewhere where I was able to figure out how to specify the location for the emulated EEPROM. This is useful if you want to place the emulated EE in a specific location if your application will have a bootloader. If you need that, I'll see if I can dig up the code.
 
Noggin - thank you for your reply. I was not under the impression that 0xBD00800 had to be declared but it seems that BMXPUPBA has to be, depending on the actual PIC32MX used.

I have tried running the DEE emulation on a PIC32MX795F512L but it fails on execute every time when you execute line if(DataEEWrite(DEEdata,DEEaddr))....

I am now using the Microstick 2 EVB to evaluate the DEE using a PIC32MX250F128B and it still fails in debug mode.

All I want to do is to store 2 or maybe 4 bytes of non-volatile configuration data that is calculated from the program and one input sensor.
 
Noggin - to show my simple evaluation code:

// call initialization function before any DEE related functions
DataEEInit();


DEEaddr = 0;
DEEdata = 0x75757575;
DataEEWrite(DEEdata,DEEaddr); // <<< ---- write error flag set after calling here !

DEEdata = 0x00; // clear the variable
DEEdata = DataEERead(&value, 0); // read data back to confirm
 

Noggin

Member
BMXPUPBA is a register in the MCU and is defined in the appropriate header file. I don't think you need to do anything with it. I did find a forum post elsewhere which someone said they could set the BMXPUPBA register to a different value that would allow them to set the location of where the EE data is stored. However, I used a different method that involved modifying the linker script to create a dedicated area in flash for storing EE data. I don't think we need to get into that unless you determine that you want that and then only after you get the EE working.

Ok, so I'm looking at an old project I did a few years back on a PIC32MX360F512. In my startup routines, I do call DataEEInit() then SYSTEMConfigPerformance( GetSystemClock() ); and don't do anything fancy other than that. I've found that not calling SYSTEMConfigPerformance causes odd things to happen, but it might be worth adding that in.

It looks like the functions you are calling should be working. Check your map file, where is eedata_addr getting placed? It MUST be on a page boundary for the EE emulation to work. The library should be doing that for you when it declares the storage area as const unsigned int eedata_addr[NUM_DATA_EE_PAGES][NUMBER_OF_INSTRUCTIONS_IN_PAGE] __attribute__ ((aligned(4096)))={0};

I've also added a c file to this post. Try adding this to your project. I don't remember the exact cause, but there was either a batch of processors or a silicon change that affected timing when writing to flash. The result was that our units were failing to bootload. The attached c file corrected the issue I think by modifying the timing. This was a year or two ago so the specifics are hazy.
 

Noggin

Member
Another thing to consider is that the emulated eeprom libraries may be overkill. The benefit of the emulated eeprom is that it implements wear leveling for you. If all you were doing was storing a bit of configuration data that rarely changes, you could roll your own routines for storing information in specific locations. But this is another beast in itself as you have to modify the linker scripts and I think it should be easier to get the EE emulation stuff working.

Oh... this might be important as well. The only compilers to date that I've used with the PIC32 is MPLAB C32 1.10b and earlier.
 
@Noggin - thank you for your input here, I really appreciate it.

The eedata_addr as listed in the map file for the test program in my PIC32MX250F128B is 0x9D001000 as:

.rodata 0x9d001000 0x1000
.rodata 0x9d001000 0x1000 dee_emulation_pic32.o
0x9d001000 eedata_addr

I guess this might change when I get the read and write routines to work without errors in my PIC32MX795F512L instead of the test in PIC32MX250F128B

The inclusion of the nvm_operation_lib.c does nothing to resolving the problems as it seems never to be used. Do I have to change the extension or just include it in the #includes at the beginning of the program?
 
Another thing to consider is that the emulated eeprom libraries may be overkill. The benefit of the emulated eeprom is that it implements wear leveling for you. If all you were doing was storing a bit of configuration data that rarely changes, you could roll your own routines for storing information in specific locations. But this is another beast in itself as you have to modify the linker scripts and I think it should be easier to get the EE emulation stuff working.
Noted, but as I just need to store a couple of bytes that get written upon an initial configuration of the project (example - encoder pulses per mm of guillotine cutter bed) the rest of the time these values are simply read out on power up.

The main task is to know exactly where these bytes are being saved so that the values can be read out in a DataEERead(unsigned int *data, unsigned int addr) routine.
 
Noggin - another update. After reading the AN1095 DEE Emulation DS01095D dated 2011 page-14 I changed a couple of the relevant defines:

// User defined constants
//=======================
// total number of 32-bit data
#define DATA_EE_SIZE (32) // was (680)
// total number of pages reserved
// for the operation
#define NUM_DATA_EE_PAGES (2) // was (3)

// Internal constants
//===================
// maximum erase cycle per page
#define ERASE_WRITE_CYCLE_MAX (1000)
// number of 32-bit word instructions per page
#define NUMBER_OF_INSTRUCTIONS_IN_PAGE (512) // was (1024)
// the point where address starts
#define DATA_OFFSET (1000) // was (1360)
// total page size in bytes
#define PIC32MX_PAGE_SIZE (NUMBER_OF_INSTRUCTIONS_IN_PAGE*4)

and now I don't get any "page corrupt" or "write error" flags getting set but my test "write" then "read" still does not work :)

Even if I get MPLAB to display the memory it still does not show the 0x00007575 that I wrote.

// call initialization function before any DEE related functions
DataEEInit();

DEEaddr = 0x00;
DEEdata = 0x7575;
// unsigned int DataEEWrite(unsigned int data, unsigned int addr);
value = DataEEWrite(DEEdata,DEEaddr);

DEEdata = 0x00; // clear the variable to test that the READ routine actually works !

// unsigned int DataEERead(unsigned int *data, unsigned int addr);
DEEdata = DataEERead(&value, 0x00);
 

Noggin

Member
You don't want to change those defines. The only one that I think is acceptable to change is the NUM_DATA_EE_PAGES and it should only be increased, not decreased.

I've put together a test project to use with the simulator, but it looks like the simulator doesn't support flash operations as it hangs when the NVM operation starts. I also do not have a PIC32 device available at the moment to test this on, but I would expect it to work. The project is attached.
 
Last edited:

Noggin

Member
Oops, sorry. You don't need that file, just delete that #include line.
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top