Writting to an I2C EEprom inside an Interrupt (Save data at Power-down) [SOLVED]

Projects Programming
1

I'm experiencing an issue in which I try to back up my data at power off.

In order to do so a comparator triggers a low voltage warning to generate an interrupt.

Within the interrupt I have the code:

ISR(INT4_vect)
        {
          FRAMWrite(0x05, 12345);  
        }

and the FRAM function

void FRAMWrite(uint8_t theMemoryAddress, uint16_t u16Byte) 
{
  
    uint8_t lowByte = ((u16Byte) & 0xFF);
    //Serial.println(lowByte);
    uint8_t highByte = ((u16Byte >> 8) & 0xFF);
    //Serial.println(highByte);
    
    Wire.beginTransmission(FRAM_ADDR);
    Wire.write(theMemoryAddress);
    Wire.write(lowByte);
    Wire.write(highByte);
    Wire.endTransmission();
}

The arduino freezes when doing this. In fact it does it with any other interrupt, while attempting to use this function
Is there anything stopping me from using the wire library inside an interrupt? if so how shall I overcome this issue?

PS: The function works OK outside the ISR

2

Can you watch closely at Wire.begintransmission? maybe it disables interrupts (leading to error because it's inside an interrupt :D)
If not, then I came up with 2 iideas/solutions which might work or not:

1.-Forget about interrupt, just read the trigger with digitalread inside main loop(), if you use state machine coding then there would be no need for using interrupts, because you'd be reading very fast the event (don't use delays).

2.- Debounce the external interrupt. Maybe you are triggering many interrupts because of noise or something like that.

3

mart256:
Can you watch closely at Wire.begintransmission? maybe it disables interrupts (leading to error because it's inside an interrupt :D)
If not, then I came up with 2 ideas/solutions which might work or not:

Thanks for your thoughts, care to give some more details?

mart256:
1.-Forget about interrupt, just read the trigger with digitalread inside main loop(), if you use state machine coding then there would be no need for using interrupts, because you'd be reading very fast the event (don't use delays).

I use Direct port manipulation, but still if the code is busy refreshing the TFT I'm afraid I wont be able to save data on time. Worse yet if I happen to save just as the power is lost the data is corrupted.

mart256:
2.- Debounce the external interrupt. Maybe you are triggering many interrupts because of noise or something like that.

A) The opamp has hysterysis, but an interrupt cannot occur while the previous is executing so we can rule that option out.
B) I also happen to have a save on overflow interrupt and same happens. In fact it overflows at startup when resetting TCNT5 to zero on timer 5 configuration and hangs the program right there.

I wrote a loop to only execute after the first overflow

ISR(TIMER5_OVF_vect)
	{
        OVF++;
        if (OVF >1)
        {
        odo_ms++;
        FRAMWrite(0x05, odo_ms);     //Save MSB of current mileage to memory on overflow (every ~ 10Miles) 
        }
        }

But when the timer overflows, kabum :astonished:

4

casemod:
The arduino freezes when doing this. In fact it does it with any other interrupt, while attempting to use this function
Is there anything stopping me from using the wire library inside an interrupt? if so how shall I overcome this issue?

PS: The function works OK outside the ISR

The Wire library uses interrupts. Interrupts are disabled upon entry to an ISR. Solution: Simply have the ISR set a flag variable (e.g. bool), monitor the variable in the mainline (non-ISR) code and when the flag is set, call the FRAMwrite() function.

5

That would defeat the purpose of using interrupts in the first place. Unless is some GOTO kind of operation

6

The Arduino only has one level of interrupt. When any interrupt occurs, interrupts are disabled until the code returns from the interrupt routine. There's no way to use anything else that relies on interrupts from inside an interrupt routine.
You have to do exactly as Jack advised.

Pete

7

el_supremo:
The Arduino only has one level of interrupt. When any interrupt occurs, interrupts are disabled until the code returns from the interrupt routine. There's no way to use anything else that relies on interrupts from inside an interrupt routine.
You have to do exactly as Jack advised.

Pete

OK I know how interrupts work and now I know my problem is the wire library using interrupts itself. That most certainly has identified the problem.

With that said... No I don't need to poll
There are a few I2C libraries that don't rely on interrupts and therefore can run inside one. I can't past in the phone but a quick Google search revealed a few.

Why complicate? Simplex

8

casemod:
That would defeat the purpose of using interrupts in the first place.

I don't see why that would be.

Unless is some GOTO kind of operation

What do you mean?

9

http://arduino.cc/en/Reference/Goto

10

casemod:

[quote author=Jack Christensen link=topic=266698.msg1881074#msg1881074 date=1410695635]

casemod:
Unless is some GOTO kind of operation

What do you mean?

http://arduino.cc/en/Reference/Goto
[/quote]

LOL yes I am well aware what a GOTO is, I didn't understand why it was a necessity here.

11

LOL yes I am well aware what a GOTO is, I didn't understand why it was a necessity here.
[/quote]

My loop is often busy printing to a TFT, which takes time. And often power is lost before I am able to save any data.
I need to jump straight into the save action, although the goto doesn't work inside an ISR, or at least the compiler is being picky with it.

12

why not just save to the EEPROM each time your variable changes, or some regular frequency with which you are comfortable?

detecting the power loss and writing fast seems like too late, no?

13

BulldogLowell:
why not just save to the EEPROM each time your variable changes, or some regular frequency with which you are comfortable?

detecting the power loss and writing fast seems like too late, no?

Very likely that I am writing just as power is lost and I get a corrupted memory. It doesn't seem any better.

14

casemod:
Very likely that I am writing just as power is lost and I get a corrupted memory. It doesn't seem any better.

why is so likely that you are writing at th emoment you lose power? are you experiencing some hardware issue that causes power to drop out?

Anyway, you could create a circular buffer in EEPROM that can get you back to the last healthy write. If you are writing to EEPROM a lot, the circular buffer will help you dilute the effects on any single memory location, too.

15

BulldogLowell:

casemod:
Very likely that I am writing just as power is lost and I get a corrupted memory. It doesn't seem any better.

why is so likely that you are writing at th emoment you lose power? are you experiencing some hardware issue that causes power to drop out?

Anyway, you could create a circular buffer in EEPROM that can get you back to the last healthy write. If you are writing to EEPROM a lot, the circular buffer will help you dilute the effects on any single memory location, too.

I could also use a backup source such as a Li-ion cell. The point is that its much more appealing and cheap, hardware wise, to just use a "no interrupts" library and write with an interrupt. At this point I dont care what happens elsewhere on the code.

I have a guaranteed 50ms before the switching regulator cuts power. Why should I mess around and complicate my life?

The device can be powered off at any time by the user

16

casemod:
I have a guaranteed 50ms before the switching regulator cuts power. Why should I mess around and complicate my life?
The device can be powered off at any time by the user

right, I thought you sad that the TFT writes were affecting your ability to effectively make the write to EEPROM.

the battery option seems like a great place to start.

If you are interested in the EEPROM circular buffer, an example is attached. I have a rain sensor attached to a home automation device and save to EEPROM the 5 day history of rain events. My home automation controller uses that history to make a decision whether to water my lawn. In the case of a power cycle, the device retrieves the history from EEPROM and will update that back to the HA server. The EEPROM in this device is updated hourly.

I didn't use a battery backup because the heat/humidity at this house is very high and the batteries don't last or corrode. I supply power directly from an outlet, the sensor transmits rain events via NRF24 radio.

RainGauge.ino (8.36 KB)

17

BulldogLowell:

casemod:
I have a guaranteed 50ms before the switching regulator cuts power. Why should I mess around and complicate my life?
The device can be powered off at any time by the user

right, I thought you sad that the TFT writes were affecting your ability to effectively make the write to EEPROM.

No, I meant that the TFT writes do usually take more than 50ms, so depending where the loop is being executed at the time the interrupt is triggered I may or not have enough time to act upon it. Its actually an FRAM so no issues with EEPROM write delays.

18

All done.

Figured out interrupt or not, the wire library is a waste of time, so I tough I should post to avoid someone wasting time in future

This is the original function:

void FRAMWrite(uint8_t theMemoryAddress, uint16_t u16Byte) 
{
      uint8_t lowByte = ((u16Byte) & 0xFF);
    Serial.println(lowByte);
    uint8_t highByte = ((u16Byte >> 8) & 0xFF);
    Serial.println(highByte);
    
    Wire.beginTransmission(DEVICEADDRESS);
    Wire.write(theMemoryAddress);
    Wire.write(lowByte);
    Wire.write(highByte);
    Wire.endTransmission();
}

And this is the function with the I2C master library:

void FRAMWrite(uint16_t theMemoryAddress, uint16_t u16Byte) 
{
    I2c.write(FRAM_ADDR, theMemoryAddress, u16Byte);
}

Its so simple it gave me a headache trying to figure it out!

And it works inside the ISR XD

19

Nice solution.