Re: EEPROM usage

[Christo Crause]

The contents of EEPROM is stored in a specific section in the executable file.  This is in a separate address space so it cannot be stored in the same hex file as the executable code.  Try passing your compiled code (bug.obj) as input to run_avr, it should extract the necessary information from the applicable sections in the file.  You can also study MakeFile.common (lines 145 - 170) to see how the makefile compiles the tests and examples.

On Tue, Nov 13, 2018 at 7:50 AM Aurélien Vallée <vallee....@gmail.com> wrote:

I am trying to understand how to use simavr to run my units tests.

I cannot make a simple example to work, I guess I'm just missing something, but would really like to understand why. I'm using simavr latest master as of 2018-11-13.

Here is my simple program, inspired from the tests:

#ifndef F_CPU
#define F_CPU 8000000
#endif
#include <avr/io.h>
#include <stdio.h>
#include <avr/interrupt.h>
#include <avr/eeprom.h>
#include <avr/sleep.h>


#include "avr_mcu_section.h"


uint32_t value EEMEM = 0xdeadbeef;


static int uart_putchar(char c, FILE *stream) {
    if (c == '\n')
        uart_putchar('\r', stream);
    loop_until_bit_is_set(UCSR0A, UDRE0);
    UDR0 = c;
    return 0;
}


static FILE mystdout = FDEV_SETUP_STREAM(uart_putchar, NULL, _FDEV_SETUP_WRITE);


int main()
{
    stdout = &mystdout;


    uint32_t c = eeprom_read_dword((void*)&value);
    printf("Read from eeprom 0x%08lx -- should be 0xdeadbeef\n", c);
    eeprom_write_dword((void*)&value, 0xcafef00d);
    c = eeprom_read_dword((void*)&value);
    printf("Read from eeprom 0x%08lx -- should be 0xcafef00d\n", c);
    sleep_cpu();
}

I expect value to populate in the EEPROM with value 0xdeadbeef when I simulate. However, that's not what I observe:

$ avr-gcc -I../simavr/simavr/sim/avr -Os -mcall-prologues -Wall -std=c99 -mmcu=atmega88 bug.c -o bug.obj
$ avr-objcopy -R .eeprom -O ihex bug.obj bug.hex
$ ../simavr/simavr/run_avr --mcu atmega88 --freq 8000000 bug.hex


Loaded 1 section of ihex
Load HEX flash 00000000, 1836
Read from eeprom 0xffffffff -- should be 0xdeadbeef..
Read from eeprom 0xcafef00d -- should be 0xcafef00d..

The initial value of value in the EEPROM is 0xffffffff !

However, when I use the tests (atmega88_example.c) with its build chain, it seems to work as expected, which means there should be something wrong in my way to build or run the example.

Any clue?

--
You received this message because you are subscribed to the Google Groups "simavr" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simavr+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aurélien Vallée]

I actually just found out why, and that's really stupid on my side.

$ avr-objcopy -R .eeprom -O ihex bug.obj bug.hex

I was actually stipping the eeprom from the hex file.

So sorry for this,

--

Aurélien Vallée
Phone +33 9 77 19 85 61

[Christo Crause]

You are indeed correct.  It seems that avr-objcopy adds 0x810000 to the eeprom address, this is how simavr knows to put the data in eeprom.  Note that if you use one of the macros from avr_mcu_section.h then an output section named .mmcu is created.  If I generate a hex of the atmega88_example.axf file using avr-objcopy without excluding sections then the .mmcu section's data is dumped to starting address 0x910000, which is also interpreted by simavr as eeprom data. In this case the eeprom data is then unexpectedly overwritten by the data in .mmcu from the hex file. When passing the elf file as input to simavr this problem is avoided.