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
