IntEEPROM is blocking and causing slow operation

[jgirard1]

I am using IntEEPROM bean in my MC9S12XA256 application.  I have it set up for a virtual page that is 400 bytes in size.  It all seems to work fine, however, when I use SetPage() function to flush the page to EEPROM, it takes several seconds to accomplish this task and it blocks the entire processor operation during that time.  I was surprised!

I have tried to enable interrupts for the bean, but that only provides an interrupt after the end of the write cycle.  I believe this bean is not written as an interrupt driven process because there are a few while-loop in the WriteSector() function that are causing the blocking when it does the erasing part.

Why does this take such a long time?

Is there a way to make it go faster?

Do I need to write my own EEPROM driver to take full advantage of an interrupt driven process?

Seems like this IntEEPROM bean should already be optimized for more efficient operation.  I'm disappointed.

Thank you.

[KeshavaGN]

Hi jgirard1 ,

EEPROM requires specific time for writing each data.

This time is usually specified in EEPROM datasheet as: Write Cycle Time.

You can not write another data to EEPROM before it completes writing the first data.

With regards,

Keshava G N

[jgirard1]

Of course it takes time to write, which is the cause of my delay.  That was not exactly my question.  The question was related more to the IntEEPROM bean operation, not the EEPROM writing itself.

The question was more specifically, why does it block the whole processor execution and freeze the application during this delay?

If the Processor Expert bean was implemented using full interrupts, taking advantage of the CCIE (Command Complete Interrupt), it could do other tasks while the current EEPROM command executes.  For example, while the Erasing Command executes, the processor could be off running the application code.  Once the EEPROM Erase Command completes, an interrupt would be generated and the EEPROM code could then setup the next command, enabled the next interrupt, go back to executing my code, and so on.

As it stands now, the bean sits in a while-loop to wait for the erase cycle to complete.  This is a very elementary programming approach, especially since there are powerful interrupts available in the processor that could be taken advantage, which would allow normal processor execution to continue while programming occurs in the background.

Basically, I am asking if I am stuck with this half-useful EEPROM bean, or should I create my own?

[iuliantalpiga]

Hi

The  SetPage method was designed to be used for writing chunks of data to EEPROM, instead of writing each byte individually and it's provided for those that don't need or want more control regarding the writing process. I agree that it's implementation could be done better but various scenarios have various needs and current implementation tries to cover as many requirements as possible while remaining simple to use and port on various devices.

In order to implement what you suggest a machine state will be required, and after that the writing might take more time to execute (start-to-finish) then existing implementation and certainly will use more resources  - so it might be not very appealing to other users / scenarios. Contrary, IntEEPROM provides all the building blocks that user might need in order to achieve various needs of different applications.

I don't think you are stuck with this or you have to write your own driver, you can use SetByte/SetWord methods to have more control regarding  the writing strategy that you want. I don't think it's complicated to set a flag in OnWriteEnd event and trigger the next writing to start in your application when the current one has finished. You can even use the generated code from SetPage as inspiration. Please let us know if you have any problems in doing that.

As a general recommendation i would suggest you to try to have the sectors erased before starting the writing, this and a smaller virtual Page size might provide you a shorter execution time without any code change.

Regards,

Iulian

[jgirard1 · Accepted solution]

I had already tried to implement my own state machine using the events from the IntEEPROM and that all worked fine; however, the problem came down to the erase sector part.  The code that was generated from Processor Expert was a while-loop that just waited for the sector to be erased before it moved on to the writing process.  According to the datasheet for MC9S12XA256, the sector erase takes 20ms.  This is exactly how long it showed on my oscilloscope to write each byte--20ms.  During this 20ms, my CPU was frozen in a blocking while-loop.

What I did was just re-wrote the driver myself using a state machine that utilized the nice low-level EEPROM register interrupts that the CPU designers implemented for us real fancy smart software engineers.  That took care of the problem.  Now the EEPROM page is written in the background, as it should, and all is well.  My main loop timing is unaffected now.

[iuliantalpiga]

Hi,

I'm glad to hear that you were able to workaround your problem.

Please remember to update status of the question.

Regards,

Iulian

[vfilip]

Hello,

the example (3) from components typical usage page could also help.

best regards

Vojtech Filip

Processor Expert Support Team

[JimDon]

It could be that you can not read EEPROM while it is being programmed, there fore you must make certain no one else is attempting to read it. There are better ways of doing this to be sure.