simavr
simavr copied to clipboard
Impossible to load ihex eeprom
I'm trying to simulate the atmega328p with ihex firmware and eeprom using simavr -m atmega328p -f 16000000L -ff firmware.hex -ee eeprom.hex -v -v -v
, but it's loading the eeprom as flash and crashing:
Loaded 1 section of ihex
Load HEX flash 00000000, 19148
Loaded 1 section of ihex
Load HEX flash 00000000, 1024
CORE: *** 0006: Invalid Opcode SP=08ff O=0009
CORE: *** 000a: Invalid Opcode SP=08ff O=0007
CORE: *** 03fc: Invalid Opcode SP=08ff O=0044
avr_sadly_crashed
I see here that -ee
sets loadBase
to AVR_SEGMENT_OFFSET_EEPROM
, which is defined here to be 0x00810000
, but in sim_setup_firmware
the check for whether it's loading eeprom or flash is chunk[ci].baseaddr < (1*1024*1024)
, which doesn't account for loadBase
. The ihex format only allows 16 bits for the base address, so the max address is 65535, making it impossible to get simavr to load a file as eeprom instead of flash.
The condition for eeprom checks both the base address by itself and base address + loadBase
, but since this happens after the flash condition which only checks base address, it can't be reached. It's unclear to me why loadBase
isn't used in both conditions, and why the eeprom condition checks both with and without it.
I was able to work around the issue by adding an "Extended Linear Address" at the start of the eeporm file to indicate that the addressing should start at 0x100000:
:020000040010EA
This causes the eeprom to be loaded correctly, but as of yet I haven't figured out if it's possible to get simavr to save modified eeprom back to the file. It would be great to better document the eeprom functionality.
The loading code does not seem to have changed much since eeprom loading was introduced in 5d6254c8da54127276ecdd48069f00f19788693f. Not checking loadBase before loading flash does seem a straightforward bug. I think the reason that the eeprom address check is done both with and without loadBase is to accommodate two sorts of eeprom-containing ihex files: one that respects the convention used by avr-ld with the usual scripts (eeprom start address 0x81000) and one where eeprom contents are based at 0. I guess you have the second sort.
A fix might also handle multiple non-overlapping chunks of both flash and eeprom, and non-increasing addresses in the ihex file.
An option to save eeprom in reloadable form also looks useful.
Serendipity - I hit the same problem: PR to fix has been submitted.