buserror / simavr

simavr is a lean, mean and hackable AVR simulator for linux & OSX
GNU General Public License v3.0
1.58k stars 368 forks source link

Impossible to load ihex eeprom #505

Closed AndrolGenhald closed 1 year ago

AndrolGenhald commented 2 years ago

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.

AndrolGenhald commented 2 years ago

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.

gatk555 commented 2 years ago

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.

adbancroft commented 2 years ago

Serendipity - I hit the same problem: PR to fix has been submitted.