#3559 Buggy output in Motorola SREC Format (Z80)

[mi-chi]

Toolset Snapshot build #13890:
SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502 TD- 4.2.14 #13890 (MINGW64)

The Motorola SREC (.s19) format shows some weird output - as opposed to the Intel HEX (.ihx) format from the linker. Tested with Z80 code.

Example code ("data.c"):

int value1 = 7;
int value2 = 9;

void main(void)
{
    value1 *= 2;
}

Code is compiled with:
sdcc -mz80 -c data.c
Linked with (one for Intel HEX, one for Motorola SREC):
sdldz80 -i out data.rel
sdldz80 -s out data.rel

The compiler output (data.lst) file shows that the following areas are used:

• _INITIALIZED: reservation to hold 2 * 16 bit values for value1 and value2, (ASM ".ds" instruction).
• _CODE: 13 bytes (0x0D)
• _INITIALIZER: 2 * 16 bit constants for the initialization of value1 and value2.

Without defining any area-addresses, the linker places the code at address 0x0000 - 0x000C, 13 bytes, the runtime values (initialized) at 0x000D - 0x0010, 4 bytes, and the constants for the initialization at 0x0011 - 0x0x0014, 4 bytes.

I'm showing the Intel HEX output first, as a reference on how the output should look. For better visualization, I added some spaces and a header, where BC = byte count, ADDR = destination address, RT = record type, followed by data. The last byte is the checksum

LN   BC ADDR RT DATA ... CHECKSUM
01: :0D 0000 00 FD210D00FDCB0026FDCB0116C9 32
02: :04 0011 00 07000900 DB
03: :00 0000 01 FF

The code is placed at 0x0000, 0x0D bytes
The constant initializer data is placed at 0x0011, 4 bytes
The reserved memory for the variables (ASM ".ds") is ignored, so they are uninitialized.

The Motorola S19 format has various flaws. Again, for better visualization, I added some spaces and line numbers. Note that the "byte conut" in this format counts the address and the checksum bytes as well

LN  RT BC ADDR DATA ... CHECKSUM
01: S1 04 000D 00 EE
02: S1 04 000D 00 EE
03: S1 04 000F 00 EC
04: S1 04 000F 00 EC
05: S1 04 0000 00 FB
06: S1 11 0000 00FD210D00FDCB0026FDCB0116C9 2D
07: S1 04 0011 00 EA
08: S1 06 0011 000700 E1
09: S1 04 0013 00 E8
10: S1 06 0013 000900 DD
11: S9 03 0000 FC

1. Line 01+02 and 03+04 are duplicated. This is the address for the reserved memory (ASM ".ds")for the variables and should not output any data at all.
2. The code data at address 0x0000 starts with an unnecessary 00-byte in line 05.
3. The code data (line 06) starts at the same address as line 05, and the data shows "00FD21..." The starting byte "00" is wrong.
4. The initializer data lists the same start address twice for value1 (address 0x0011, lines 07+08), one time with "00" and one time with "000700". It should be listed only once with data "0700". The same is true for value2 (lines 09+10).

My guess is that the buffer for each line's data starts with a wrong byte, always "00", and a len of 1 (after the address column). If the len would start at 0, that byte would be omitted. The 0-length lines could be suppressed and the remaining output would be correct.

The expected output would be (I didn't compute the checksum [cs]):

S1 10 0000 FD210D00FDCB0026FDCB0116C9 [cs]
S1 05 0011 0700 [cs]
S1 05 0013 0900 [cs]
S9 03 0000 FC

[mi-chi]

Possible FIX: Looks like copying and pasting the code from Index HEX (\sdas\linksrc\lkout.c -> ixx()) to Motorola SREC (\sdas\linksrc\lks19.c -> s19()) works as expected. The output is (again with spaces):

Copying and replaceing the whole from the whole "if (i)" branch and replacing "iflush()" with "sflush()" and "IXXMAXBYTES" with "MAXBYTES" results in the output:

S1 10 0000 FD210D00FDCB0026FDCB0116C9 2E
S1 07 0011 07000900 D7
S9 03 0000 FC

[Philipp Klaus Krause]

Could you please test if this works for you now? In [r14057], I replaced the Motorola SREC support by the one from current upstream asxxxx 5.40.

P.S.: I am neither familiar with nor a user of Motorola SREC. I just did a simple test (compile sample file to both .ihx and .s19, and then convert both to binary via objcopy and check that the results match).

[mi-chi]

Sorry for being late on that. Tested with 4.3.0 #14184, and the output looks good. That fixed the issue.

[Philipp Klaus Krause]