[Simulavr-devel] erroneous offset in rjmp and rcall

[eban]

Hello everybody!!!

I'm new to this atmel technology and I'm trying to
simulate a smart card operative system called SOSSE
(http://www.franken.de/users/mbsks/sosse/).

In general everything seems all right but I have
experienced some problems.

The compilation seems to be all right, and i think
SOSSE has been used before without problems. So I
suspect the problem is in your simulator.

im using simulavr version 0.1.1

Let me show you the debug session with gdb. Running
simulavr alone produces the same errors:
ERROR: file storage.c: line 101: address out of
bounds: 0xffffd550

(gdb) disassemble 0x4C 0x52
Dump of assembler code from 0x4c to 0x52:
0x4c <.zero_bss_start+2>:       cpc     r27, r18
0x4e <.zero_bss_start+4>:       brne    .-8             ; 0x48
0x50 <.zero_bss_start+6>:       rjmp    .-2818          ; 0xfffff550
End of assembler dump.

As you can see the rjmp goes to an invalid adress. (im
using at90s8515)
In the source code this instruction was in libc's
(avr-libc-20020203) gcrt1.S from Marek Michalkiewicz
et al:
...
#if XRAMEND > 0x100
        cpc     XH, r_tmp1      ; hi8(__bss_end)
#endif
        brne    .zero_bss_loop
        XJMP    _U(main)
...

in the included file macros.inc is defined:
...
#define CONCAT1(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b
#define _U(x) CONCAT1(__USER_LABEL_PREFIX__, x)
...

and you can also find in this file:
...
#if FLASHEND > 0x2000  /* ATmega */
  #define XJMP jmp
  #define XCALL call
#else
  #define XJMP rjmp
  #define XCALL rcall
#endif
...

I don't understand that a ## b notation but i think it
works for the assembler.
So instead of jumping to main (0x1550) it's jumping
somewere else (0xff...) or at least that's the way the
simulator interprets the instruction.

I compiled a much simpler program with the same
compilation parameters and I didn't find this problem.
The problem seems to be the way you manage the rjmp
and rcall instructions when the offsets are large.

If you see the binary file with hexedit you can see
that the instruction is well assembled:
        avr-objcopy -O binary sos sos.bin
        hexedit sos.bin
...
00000050   7F CA  (the bytes are reversed)
...

(0x50 is the offset of the rjmp to main)
(the C is part of the opcode for rjmp. Cxxx)

the jump that should be there is of (1550h-52h)/2 =
A7Fh so you can see it was well assembled if the data
was spected to be unsigned.

It's very likely that you have a sign conversion
problem or sign extension problem or something
similar. It makes no sense to move to that address
when the code words are in total 8K. 

the same problem occurs with rcall.

best regards,
Alberto Escalante 















__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com