EEPROM and interrupts together seems to cause processor out to lunch

Hello Benjamin,,

Are you using ROM API's when doing EEPROM Operation?

Regards

Amit

Hi Amit,

No, we are using the function directly, not the ROM equivalent. Isn't there an errata out on the ROM versions?

-Ben

Hello Ben,

Yes, there is an Errata on the ROM Version and that is what I wanted to first check.

Now the EEPROM Program API call programs the Block and Offset and then uses the EERDWRINC address to program the new word. Every write to the EERDWRINC register commits the operation, after which it waits for EEWORKING to get clear and moves to the next word.

AFAIK, the EEPROMProgram can be interrupted

Regards

Amit

Hi Amit,

At this point, I've confirmed that the function being called in the interrupt handler is another TivaWare function. The interrupt is calling ROM_ADCSequenceDataGet(ADC1_BASE, 0, values);

where values is an array to temporarily store the data values.

At this point, with my main loop calling EEPROMProgram, and my interrupt handler calling ROM_ADCSequenceDataGet, the processor goes off into the weeds and never continues operation.

Is this a known issue? If not, can someone attempt to reproduce it? 

Thanks,

Ben

Hello Ben,

Yes, this is the exact issue with TM4C129 rev-2 devices. The rev-3 devices have this fixed. So in the meantime the ROM_ADC API call must be replaced by ADC API call from Flash

Regards

Amit

Hi Amit,

I have to say, the previous wording of this errata (and your question above) made it sound like the ROM_EEPROM* functions were the only functions affected. The new wording of the errata seems to indicate that any ROM functions will cause this issue.

Can you confirm this? Any usage of ROM functions whatsoever, even for things unrelated to EEPROM, will cause the problem to occur?

Thanks,

Ben

Hello Amit,

I am now running into a similar problem as Ben. I am using both the USB driver library and the EEPROM. Sometimes my program never returns from EEPROMProgram and the USB stops functioning. My guess is that the problem is related to this errata (USB interrupt occurs during Program). I am using MAP_ calls throughout my program, so I undefined TARGET_IS_TM4C129_RA1 thinking that this would force the program to use the Flash based functions. But this didn't solve the problem. I notice that all through the USB driver, the MAP_ calls are also used. Do I need to recompile the USB driver so it doesn't use ROM?

My problem goes away if I disable interrupts during the EEPROM Program operation. How do I verify that my program is using the Flash vs the ROM versions?

Thank you,

Isaac

Hello Issac,

Yes, please recompile the USB and the main driverlib files.

Regards

Amit

Amit,

I think I have successfully recompiled usblib and driverlib. I also removed the #define TARGET_IS_TM4C129_RA1 from my project and removed all #include "rom.h", so I think that my project is running all code from Flash. When I debug and look at disassembly it looks like this true.

Unfortunately the problem persists - even with interrupts disabled (just less frequently). I added output to a GPIO around the EEPROMProgram and found the the USB reports an error when the Program Time is long (30 ms). I see in the EEPROM electrical characteristics that this is how long it takes when a copy to the copy buffer is required. This is probably because interrupts are disabled for too long.

So I re-enabled interrupts and find that the problem is still there - just intermittent - even when program time is on the order of 300-400 us. I do notice that on in the failure case the GPIO is not pulled low quickly, but rather it has a decay time.

After a failure I am able to disconnect my PC-side program from the USB port, reconnect it, and continue communications without restarting the M4.

GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, 1);
retVal = EEPROMProgram(dataBuffer, eePtr, length);
GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, 0);

Hello Issac,

Then it may not be the same issue if ROM API's are not being called. Secondly since the GPIO is configured in Push Pull, it cannot decay unless it has been configured as a Input, which may suggest that a reset event may be occuring and the program restarting. The behavior of the GPIO would be the same if you remove the power to the device as well. Can you confirm that?

Regards

Amit

Hi Amit,

Yes. It appears that the program is restarting. As evidenced by that decay and that after the "decay" event I attempt to pause the debugger and get this message: CORTEX_M4_0: Trouble Halting Target CPU.

I removed the USB from my program. Now I have single task running that programs the same word of eeprom every 3 seconds. About 20-30% of the time a CPU reset occurs during the EEPROMProgram function

Hello Issac,

How much decoupling cap is there on the VDD and VDDC and also did you try to check the SYSCTL.RESC register to see what is the source of the the reset?

Regards

Amit

How much decoupling cap is there on the VDD and VDDC and also did you try to check the SYSCTL.RESC register to see what is the source of the the reset?

That hint might be on the right track.

I suggest to watch the MCU supply voltage (V_DD) during EEPROM write, physically as close as possible to the MCU pins.

EEPROM (and Flash) require about 9V for programming, and this voltage is generated on-chip by switched-capacitor converters. This, in turn, pulls some extra current. For other, smaller MCUs, I measured a current of a few milliamps for a single EEPROM cell. If this pushes your board over the edge (brown-out), there is a problem in your power supply/decoupling.

Yes, I think you are on the right track. I am using the EK-TM4C1294XL LaunchPad for development.

I'm monitoring the Reset Cause register and it is 0x4 = SYSCTL_CAUSE_BOR. 

Hello Issac,

Since the BOR Threshold is higher than a POR, you may want to turn the BOR as a reset source to BOR as interrupt source. This can be done by clearing the respective bit field in SYSCTL.RESBEHAVCTL register

Though this is not the final solution, it would be good to see if the device still goes down to a POR condition.

Regards

Amit

Thanks for the clues, it turns out the problem was caused by my current meter. I checked the spec and the meter has a 5 ohm resister when measuring these low currents.

I had two problems:

1. Calling ROM functions while EEPROM was active. I solved this by removing ROM functions from my program and recompiling the USB library to not use ROM functions.

2. BOR caused by current meter on JP2 of evaluation kit. I switched the meter to a higher current mode, which uses a .1 ohm resister and the BOR stopped.

Thanks!

Hello Issac,

Nice work... Glad to see you back on track..

Regards

Amit