Re: [Simulavr-devel] Problem with reading EEPROM in simulavr

[Petr Hluzín]

On 6 November 2011 22:49, Marek Pietrzak <address@hidden> 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