Peter, I tested the last version and it seems to work ok at first glance. If you want a program to reproduce the problem and check it again, it can be something like this:
#include <avr/eeprom.h> int main(void) { uint8_t* addr = 0; uint8_t test = eeprom_read_byte(addr); while(1); } Regards, Marek On Sun, 2011-11-13 at 18:04 +0100, Petr Hluzín wrote: > On 6 November 2011 22:49, Marek Pietrzak <marekp...@gmail.com> wrote: > > Hi, > > > > Recently I added a call to eeprom_read_byte from avrlibc to my project > > but it results in AvrDevice::Step returning -1. This is wrong I believe. > > I turned on trace output which resulted in the following: > > > > ../Debug/lcmeter.elf 0x12fc: __eerd_byte_m8 > > CPU-waitstate > > 0 > > 0 > > ../Debug/lcmeter.elf 0x1300: __eerd_byte_m8+0x2 OUT 0x1f, > > R25 EEAR=0x0 > > 0 > > ../Debug/lcmeter.elf 0x1302: __eerd_byte_m8+0x3 OUT 0x1e, > > R24 EEAR=0x0 > > 0 > > ../Debug/lcmeter.elf 0x1304: __eerd_byte_m8+0x4 SBI 0x1c, 0 > > EECR=0x1 EEPROM: Read = 0x0 > > 0 > > ../Debug/lcmeter.elf 0x1304: __eerd_byte_m8+0x4 > > CPU-waitstate > > 0 > > ../Debug/lcmeter.elf 0x1306: __eerd_byte_m8+0x5 CPU-Hold by > > IO-Hardware 0 > > 0 > > ../Debug/lcmeter.elf 0x1306: __eerd_byte_m8+0x5 CPU-Hold by > > IO-Hardware -1 > > -1 > > > > The number after "CPU-Hold by IO-Hardware" is the actual cpuCycles, so > > it turns at some point negative and of course simulation returns as if > > there was a breakpoint. > > > > Marek > > Hi Marek > > Thanks for the report. The sequence of event is probably: > > If EEPROM or Flash operation was in progress (i.e. virtual > Hardware::CpuCycle() returned nonzero) then: > 1) "CPU-waitstate" was printed zero or more times (correct) > 2) `cpuCycles' eventually became 0 (correct) > 3) Hardware::CpuCycle() returned nonzero (correct) > 4) "CPU-Hold by IO-Hardware " was printed (correct) > 5) instruction was not executed (correct) > 6) `cpuCycles' was decremented causing it to be <0 (bug) > 7) AvrDevice::Step() returned -1 and simulation was terminated. > > Do you have a small program to reproduce the behavior? > > If I understood the bug correctly then it should be fixed in > http://git.savannah.gnu.org/cgit/simulavr.git/commit/?id=81f0742ad5cb847f8cf8ef1be4b4e6b1ee354285 > _______________________________________________ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel