https://sourceware.org/bugzilla/show_bug.cgi?id=27214
Bug ID: 27214
Summary: Outputting hex file with --verilog-data-width 4 uses
incorrect offsets
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: shareef at jalloq dot co.uk
Target Milestone: ---
I'm using the gcc-arm-none-eabi-9-2020-q2-update version of objcopy and trying
to output a hex file for Verilog simulation using $readmemh.
It looks like the --verilog-data-width switch outputs the correct size data
chunks but doesn't update the address offsets.
If using the default options of:
arm-none-eabi-objcopy -S source.o -O verilog source.hex
I can load a byte array using $readmemh with no issue. If I specify the
following:
arm-none-eabi-objcopy -S source.o -O verilog --verilog-data-width 4
source.32.hex
then I get 32-bit words but the indexes don't seem to be updated. When I try
to run the simulator, the array index runs off the end of the array.
Looking at the two output hex files, the first filled address is 0x0 which is
fine. The next region seems to be set to the same value for both data widths
which is obviously broken.
source.32.hex:
@0000265C
ACDDFF7F 01000000
source.hex
@0000265C
AC DD FF 7F 01 00 00 00
--
You are receiving this mail because:
You are on the CC list for the bug.
