Problem with copy routine for HCS08 and CW 5.1

[Ralph]

Hi!
Maybe a beginners question, but I don't know whats wrong there.
In my program I have to copy different strings from Flash to my transmit queue which is in RAM (for sure :-)). So I tried to find a good assembler routine to do this with minimal effort. Fortunately (?) I have found a routine in HCS08RM chapter 6.5.1.3 "Memory to Memory Moves":

    ldhx    #TX_queue
copy_loop:
    lda      (Text-TX_queue),x
    beq      end_of_copy
    sta      ,x
    incx
    bra      copy_loop
end_of_copy:
.....

If I start with "make" button of CW5.1 I get the following Error:
A2401: Complex relocatable expression not supported for "    lda      (Text-TX_queue),x"

I don't know why this is happening. It should be a valid command (address mode IX2). Is this a bug of CW5.1 or do I have to use fixed flash adresses and compute the difference of "Text-TX_queue" by myself?

Many thanks in advance!
Best regards

Ralph


J2MEJediMaster added MCU type and CodeWarrior version to subject line



Message Edited by J2MEJediMaster on 2007-06-05 09:19 AM

[bigmac · Accepted solution]

Hello Ralph,

This sort of compile time calculation is apparently a big no no for relocatable assembly, but seems to be quite OK for absolute assembly (using CW assembler tool rather than IDE).

A work-around method given in the help file is to calculate the required offset in run time.

Perhaps another method is to use two different (non-zero) offsets, one for the source location and the other for the destination.

    ldhx    #0
copy_loop:
    lda     Text,x
    beq     end_of_copy
    sta     TX_queue,x
    incx
    bra     copy_loop
end_of_copy:

Regards,

Mac

[Ralph]

Hello Mac,

many thanks for your quick reply! I now understand that this kind of programming is not good for relative assembly code. So a little note in the RM would have been good that this is not a good programming style.

Many thanks also for your code proposal. I'll use your code then and think my problems have gone :smileyhappy:.

Best regards

Ralph

[rocco]

---

Ralph wrote:
. . . So a little note in the RM would have been good that this is not a good programming style.

---

Hi Ralph,

I don't think that there is anything wrong with that style, and I use it all of the time.

It would work if the two lables were in the same segment, because the assembler could calculate the offset. But if the two lables are in different segments, as they must be when one is in ram and the other is in flash, then the assembler can't calculate the offset. For some reason, the linker is not smart enough to calculate the offset, although it has all of the neccessary information.

In my opinion, Mac's code is more understandable and would be the method that I would prefer if I wasn't concerned with a couple of extra cycles.

[bigmac]

Hello Ralph,

---

Ralph wrote:
. . . So a little note in the RM would have been good that this is not a good programming style.

---

I now see to what you were referring -

There are at least two instances, within the Reference Manual HCS08RMv1 (on page 137 and page 150), where programming samples are given that do not work for CW relocatable assembler, because of the "unknown" offset between the two different segments.  The samples would work as intended for absolute assembly (using ORG directives), and maybe for assemblers other than CW.

However, because of the now implicit assumption of the use of CW, the code samples given are probably inappropriate.  The use of indexed addressing could easily have been demonstrated using sample code that did not need to calculate the offset value at compile/link time.

Regards,
Mac

[Ralph]

Hello Mac,

sorry for my late reply, I was on vacation some days.
I think these examples are old ones which are copied from older manuals. I remember during my studies we played around with the 68332. In the TPU manual there were also programming examples given. They had some obvious mistakes and could therefore not be compiled and this was never corrected.

I use your given method and it works fine, thanks for your help again!

Best regards

Ralph