simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug in simulavr 1.1.0 for devices with little RAM?


From: Georg-Johann Lay
Subject: Bug in simulavr 1.1.0 for devices with little RAM?
Date: Sun, 24 Mar 2024 12:23:30 +0100
User-agent: Mozilla Thunderbird

I am using SimulAVR 1.1.0 to run the AVR-LibC test suite and am
hitting the following problem where it seems that the simulator
is behaving different than the hardware:

Take the C test case eeprom-5.c:

#include <stdlib.h>
#include <avr/eeprom.h>

#define ADDR ((void*) 10)

void test0 (void)
{
  eeprom_write_word (ADDR, 0x1234);

  //__asm ("clr r27");
  if (eeprom_read_word (ADDR) != 0x1234)
      exit (__LINE__);
}

int main (void)
{
  test0 ();
  return 0;
}

This writes 0x1234 to EEPROM and then reads it back again.
Compile with (the Compiler and LibC versions don't matter;
you can use avr-gcc v5.4 or v14 makes no difference):

$ avr-gcc -mmcu=attiny2313 -Os eeprom-5.c -o eeprom-5.elf

$ simulavr -d attiny2313 -T __stop_program -f eeprom-5.elf -C core_avr_dump.core -m 60000000000

WARNING: file /home/john/xgnu/source/simulavr/libsim/rwmem.cpp: line 235: Invalid write access to IO[0xaa18]=0x34, PC=0x7a WARNING: file /home/john/xgnu/source/simulavr/libsim/rwmem.cpp: line 235: Invalid write access to IO[0xaa19]=0x12, PC=0x7a
Run finished.  Terminated at 6822750 ns (simulated) and
27292 cpu cycles

The test case fails because the returned value from eeprom_read_word
does not equal 0x1234.

The eeprom_read_word implementation only sets the low byte (R26) of
the RAM address (which points to the register file).  The high address
is not set because ATtiny2313's RAM ends before 0x100 (RAM extends from
0x60 to 0xe0).  As far as I understand, the hardware of such devices
just ignores the high byte of addresses when it reads/writes RAM.

The test case above works when there is a "clr r27" prior to the
eeprom_read_word call, but the current AVR-LibC implementation of
assumes there is no need to set the hi8 part of the RAM address.

Is this a bug in SimulAVR ?
Or AVR-LibC making wrong assumptions on how the hardware behaves?


Johann



reply via email to

[Prev in Thread] Current Thread [Next in Thread]