EEPROM Write

[elecLear78]

Hi All,

I have this doubt if i am doing an EEPROM write operation or read operation do I need to disable all the interrupts (including any serial data coming) as I heard that eeprom write and read or slow operations. In case if i disable interrupts will there not be any serial data loss. Please help me to understand this concept i am really confused.

 

[ronsimpson]

is the EEPROM inside the micro? or external. What micro? (more information )

 

[Joe G]

I turn off my interupts during eeprom read and writes as I do for I2C. jic, better safe than not

 

[atferrari]

What the datasheet says explicitly?

 

[Triode]

It depends on the microcontroller. I recently implemented EEPROM read/write on a PIC18F46K80 and the data sheet said to disable interrupts for a write, then turn them back on. Check what the sheet for your device says.

 

[elecLear78]

Thank you all for the replies. The EEPROM is external and the micro is Freescale S12x and 16 bit controller. In case if I disable my interrupts there is a possibility that the serial data which is coming continuously may be missed. Should I not consider this? Or my software design should be robust so that these two activities not happen parallel. please advise.

 

[Jon Wilder]

A PIC has a two level UART receive buffer. The UART can hold two bytes in the buffer and be shifting a 3rd one into the receive shift register at the same time. Overrun does not occur unless the stop bit of the 3rd byte is received without the buffer being read at least once.

Assuming you're communicating at the standard 9600bps and 8N1 format (8 data bits, No parity, 1 stop bit), each received byte would have a total of 10 bits (1 start, 8 data, 1 stop) and would be received at a rate of 1.04mS per byte ((1 / 9600bps) * 10 bits = 1.04mS per byte).

This means that it would take 3.12mS for 3 bytes to shift in and cause buffer overrun. The EEPROM read/write cycles happen much faster than this (within microseconds). Unless your data rate is some really high number, it should be safe to disable interrupts temporarily while executing an EEPROM read/write even with continuous serial data. If one byte gets received during the read/write operation, the PC will immediately jump to the receive interrupt handler upon re-enabling interrupts.

 

[elecLear78]

Yes I am getting little bit. I still have some other questions i will start them as new threads. Thank you for the quick replies and clear explanation.

 

[atferrari]

If one byte gets received during the read/write operation, the PC will immediately jump to the receive interrupt handler upon re-enabling interrupts.

What, prima facie, seems to invalidate your precaution of disabling interrupts? Could you please elaborate?

 

[Ian Rogers]

Just to be clear.... EEprom read doesn't need interrupts disabled... The reason internal EEprom write require you to disable interrupts is because the write COULD fail if interrupted... External EEprom writes are completely separate and have their own housekeeping..

The only time I write to internal EEprom is to calibrate or store important info... This is usually one time writes and won't affect serial data anyway!!!

If the Serial communication is setup correctly the any packets lost should be re-transmitted anyway!!!

 

[Jon Wilder]

What, prima facie, seems to invalidate your precaution of disabling interrupts? Could you please elaborate?

Not at all. The trick here is to prevent the interrupt from happening DURING the write cycle. Having a received byte waiting in the buffer will cause the micro to interrupt when interrupts are enabled AFTER the write cycle has completed.

The point of disabling interrupts is to prevent interrupts from occurring DURING the write cycle. They can happen all they want AFTER the write cycle.

Just to review...you can have 2 received bytes waiting in the buffer and a 3rd one shifting into the shift register before a buffer overrun occurs. At 9600bps, it takes just over 2mS for the micro to have received two bytes in the buffer. The write cycle occurs much faster than this so at most you will only have 1 byte waiting by the time your write cycle completes and interrupts are re-enabled, which makes the possibility of buffer overrun a non-issue unless you're writing many bytes at once.

 

[Wade Hassler]

Thank you all for the replies. The EEPROM is external and the micro is Freescale S12x and 16 bit controller. In case if I disable my interrupts there is a possibility that the serial data which is coming continuously may be missed. Should I not consider this? Or my software design should be robust so that these two activities not happen parallel. please advise.

But it's an external EEPROM? I don't think an SX12 would care about an external device.. I'm confused.
Don't most EEPROMs have some kind of 'ready'-signal/-register that you can periodically check, or a maximum-write-time spec that you can observe?

 

[Ian Rogers]

Don't most EEPROMs have some kind of 'ready'-signal/-register that you can periodically check, or a maximum-write-time spec that you can observe?

No! They usually ask for 5~10mS between writes for houskeeping purposes..

The NON I2C ones may... But I've never used them...

 

[Wade Hassler]

No! They usually ask for 5~10mS between writes for houskeeping purposes..

The I2C devices will not ack an address until they finish writing, or you can wait 5-10mS.
SPI devices have a busy-bit in the status register.
So, I guess you meant "Yes!" ?

 

[Ian Rogers]

The I2C devices will not ack an address until they finish writing, or you can wait 5-10mS.
SPI devices have a busy-bit in the status register.
So, I guess you meant "Yes!" ?

I have never polled for an ack.... I have never really needed that speed.. As sequential writing can be done as a block, I have always used that... But we digress....

 

[Jon Wilder]

I always poll for an ack. I also run a 1 second timer that interrupts and issues an EEPROM I/O error if ack is not received within that 1 second and terminates the write or read.

 

[Ian Rogers]

I always poll for an ack. I also run a 1 second timer that interrupts and issues an EEPROM I/O error if ack is not received within that 1 second and terminates the write or read.

Don't get the wrong idea... I poll for ack after each command to ensure correct operation... I just don't poll for the busy ack...

 

[Jon Wilder]

Ah yes.

I only poll for ack when sending the hardware address byte (i.e. the control byte) just to make sure I can get the hardware to acknowledge the master device. Once it acknowledges the control byte, I send the register address bytes followed by the data bytes, polling the SSPIF interrupt flag between each byte so I know when each sequence completes.

 

[Wade Hassler]

WRT the original question: if the EEPROM is external, you don't need to disable interrupts.
If it's internal, then you must read the data-sheet. Sometimes a write to non-volatile memory disables some/all of the rest of the memory.