Hello,
I now have to disable the interrupts to use EEPROM read and write. What is the reason for this? For flash writes I can understand since the code executes from flash, but for EEPROM, and especially for EEPROM reads... Is there a workaround? Is it a NEW COMPILER BUG? I didn't do it with the last project and it worked 110%. Without it, the EEPROM is almost entirely useless.
Answers by reply only please.
Nick
I now have to disable the interrupts to use EEPROM read and write. What is the reason for this most likely an atomicity issue OR if the EPROM is SPI it might be timing out when you have heavy interrupt activity OR something that can not be deterined by the sparse info you give
Is it a NEW COMPILER BUG? very unlikely
Answers by reply only please. what does that mean? how can you answer by anything but replying
Erik
Your code has bugs:
They could be bugs in your interrupt handlers, which mess-up your "EEPROM" routines;
They could be bugs in your "EEPROM" routines not (properly) coping with interrupts;
Or both!
"Is it a NEW COMPILER BUG?"
Extremely unlikely.
Or neither.
I use a FINITE-STATE MACHINE (FINITE-STATE AUTOMATON). It might be something you have heard of. All transitions are verified as correct.
AND I do not even use INTERRUPTS! This is why I think something else is wrong. Why must I disable them now?
So why are you enabling them?
my 'skeleton' code that start every project includes the following
@int0 error(0);
@int1 error(1);
...
@intn error(n);
that producces an instant error if some external event unexpectedly fire an interrupt and thus makes the reason for things like your problem instantly diagnosed
PS the above is a result of experiencing a problem like yours
Erik,
Many thanks. You identified my problem and explained it very nicely.
Much better than the other respondent.