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 -- Petr Hluzin _______________________________________________ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
