I've a weird problem - reading fuses - mainly the lock fuse to ensure that the device is protected before running code properly.
Chip ATMEGA32A.
If I used the JTAG II debugger, and stop the code just before the function runs, the result is correct.
If I let the code run to a break point just after the read fuse LPM instruction ( or anywhere beyond ) then the result is incorrect.
There are no interrupts running - the three calls to 'boot_lock_get_fuse_bits' is early on in 'main'.
I read lock, high and low fuses.
I noticed this first in a production device having only just implimented the lock check ( even though the fuses were read, the results were not being used ).
Just before the lock bits were read is a conditional block that reads the eeprom. When options were such that the eeprom was read the fuse read was incorrect. If the options ignored the eeprom call, then the result was correct.
I assumed that there was some interaction but cannot see why.
If I insert a reasonable delay before reading the locks then the result is ok.
However - if I try to fix it by moving the code to right after the ports are initialised in main, ( no eeprom activity yet - the problem still exists in the production device ( except when debugging - perhaps because of the halt at 'main' itself. Again this may be because the production device has a bootloader which runs and does a write to the eeprom before entering main.
I can't see why this is occuring - I have another product that reads the fuses fine - although the code is probably sufficiently different ( not yet cross examined ).
I cant see where the LPM is affected by eeprom activity - but perhaps Ive missed something.