EEPROM emulation on QGx

[irob]

I've read this thread, and this one, oh and this one too. Too many choices makes my head spin!

But my local FAE was kind enough to send me a sample CodeWarrior project for EEPROM emulation on the MC9S08GB60. My target is a QG4/8 demo board. I’ve ported the project over to the QG8 with all the correct include files, timing differences, flash location differences, but haven’t gotten it to work just yet.

My question is this. Page 26 of the MC9S08QG8 rev 1.01 10/2005 datasheet states:

The internal frequency is nominally 16-MHz and the default ICS settings will provide for a
4-MHz bus out of reset.

Yet page 21, figure 1-2 (clock distribution) shows the BUSCLK as divided by 2 from ICSOUT. So which is it? Seems to me that the bus clock should be 8MHz, but it's stated that it will be 4 by default.

Naturally, these clock settings determine my flash programming clock setup. I'm guessing that timing is my problem.

[RockyRoad]

irob -

The correct answer is 4MHz. See this thread. The last post has the correct explanation.

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=1520#M1520

- Rocky

[irob]

Ahh, thanks Rocky.  Regardless, I tried my project both ways and for 4MHz bus clock, I have this:

Code:

FCDIV = 0x13; // FLASH clock initialization to 200kHz

0x13 is a 0 for PRDIV8 and a 19d for DIV.  Yet, I'm not seeing anything going on with my flash target page at 0xE200.

Here's a possible problem.  I have the following compiler warning:

A13003: Value is truncated to one byte

Here's the code in question:

Code:

I_cont:     ais #SpSubSize+3 ;deallocate sub body + H:X + commandSpSubSize:  equ (*-SpSub)

The top line gets the warning.  I'm not seeing what the problem is.  The AIS operand supports immediate addressing.

[bigmac]

Hello irob,

I presume there exists a sub-routine labelled SpSub.  The expression

SpSubSize:  equ (*-SpSub)

should be present immediately following the last instruction of the routine (presumably RTS).  SpSubSize should then give the number of bytes in the sub-routine, and this must not exceed a decimal value of 124 for compatibility with your AIS instruction.

I have tried something similar with an assembly program I am working on, and did not get any warnings during the assembly process.  However, I am using absolute assembly, so the linker is not involved.

I have found that the "truncated to one byte" warning can also occur if an undefined label is referenced, in addition to the over-range condition.

Regards.
Mac

Message Edited by bigmac on 2006-06-23 02:16 PM

[irob]

bigmac, you are correct. Here is the full snippet:

SpSub:      ldhx LOW(SpSubSize+4),sp ;get flash address from stack
            sta 0,x ;write to flash; latch addr and data
            lda SpSubSize+3,sp ;get flash command
            sta FCMD ;write the flash command
            lda #FSTAT_FACCERR ;mask to initiate command
            sta FSTAT ;[pwpp] register command
            nop ;[p] want min 4~ from w cycle to r
ChkDone:    lda FSTAT ;[prpp] so FCCF is valid
            lsla ;FCCF now in MSB
            bpl ChkDone ;loop if FCCF = 0
SpSubEnd:   rts ;back into DoOnStack in flash
SpSubSize:  equ (*-SpSub)

As you can see, this routine is clearly under 124 bytes. Is there a way to get my linker to start behaving here?

[irob]

A little update on this. I rewrote the offending assembly:

I_cont: lda #SpSubSize
        add #3
        psha

But now I get the byte truncate warning at the first line, lda. So the compiler is definitely seeing SpSubSize as being larger than one byte. Hmmm.

[bigmac]

Hello irob,

It would seem more likely that the linker cannot find the value of SpSubSize.  I assume that the instructions following the Icont label would either need to be in the same file as SpSub routine, or alternatively the file containing SpSub would need to be INCLUDEd prior to the Icont instructions.

Regards,
Mac

[irob]

---

bigmac wrote:

I assume that the instructions following the Icont label would either need to be in the same file as SpSub routine, or alternatively the file containing SpSub would need to be INCLUDEd prior to the Icont instructions.

---

Bigmac, both I_cont and SpSub are in the same assembly file. So the includes that you're recommending aren't relevant (I think?).

Message Edited by irob on 2006-06-28 05:36 PM

[peg]

Hi guys,

Isn't this just the assembler warning that as you are doing maths with 16-bit values that the answer could _potentially_ be 16-bit and that as the opcode only accepts an 8-bit operand, it is only using the low byte. Which is what you want anyway.

Below is the output listing file from P&E's assembler which doesn't complain.

Why don't you try replacing the "*-SpSub" with two dummy 8-bit values that produce the same result just to see what happens like I did at the end of the code below.

Note: I just put some dummy equ's in there.

Code:

IROB.ASM  Assembled with CasmHCS08_Pro v1.00  24/06/2006  3:35:08 PM     PAGE 1            0000FEEF     1 FSTAT        equ     $feef     00             0000FEEE     2 FCMD equ     $FEEE     00             00000080     3 FACCERR      equ     %10000000     00                          4                          5      org $e800                         6                          7 *SpSub:      ldhx LOW(SpSubSize+4),sp ;get flash add                           ress from stack E800  [05] 9EFE1C       8 SpSub:      ldhx SpSubSize+4,sp ;get flash address f                           rom stack E803  [02] F7           9             sta 0,x ;write to flash; latch addr and                            data E804  [05] 9ED6001B    10             lda SpSubSize+3,sp ;get flash command E808  [04] C7FEEE      11             sta FCMD ;write the flash command E80B  [02] A680        12             lda #FACCERR ;mask to initiate command E80D  [04] C7FEEF      13             sta FSTAT ;[pwpp] register command E810  [01] 9D          14             nop ;[p] want min 4~ from w cycle to r E811  [04] C6FEEF      15 ChkDone:    lda FSTAT ;[prpp] so FCCF is valid E814  [01] 48          16             lsla ;FCCF now in MSB E815  [03] 2AFA        17             bpl ChkDone ;loop if FCCF = 0 E817  [06] 81          18 SpSubEnd:   rts ;back into DoOnStack in flash            00000018    19 SpSubSize:  equ (*-SpSub)     00                         20  E818  [02] A618        21 I_cont: lda #SpSubSize E81A  [02] AB03        22         add #3 E81C  [02] 87          23         psha                        24             0000001A    25 test1        equ     $1A     00             00000002    26 test2        equ     $2     00             00000018    27 test3        equ     (test1-test2)     00  Symbol Table  0000E811  CHKDONE 00000080  FACCERR 0000FEEE  FCMD 0000FEEF  FSTAT 0000E818  I_CONT 0000E800  SPSUB 0000E817  SPSUBEND 00000018  SPSUBSIZE 0000001A  TEST1 00000002  TEST2 00000018  TEST3 Absolute Memory Utilization by Segments   Address Range       Length     Segment Name-------------------  ----------  -------------- 0000E800-0000E81C    0000001D   

 
Regards David

[bigmac]

Hello Peg, irob,

Actually the CW assembler doesn't complain either provided a single file contains both SpSub and Icont routines, and with the use of absolute assembly.  I assume that Peg's sample also uses absolute assembly.  The main concern with the warning message would be if the value was truncated to zero (as it could well be if the linker could not identify the reference).  The value of SpSubSize should be known when Icont is linked, and for the example given this is a non-zero single byte value, so the warning message should not occur.

With relocatable assembly, if the two routines happen to be in different files, I believe XDEF and XREF directives should be included with respect to the value (symbol) SpSubSize.

Regards,
Mac

[rocco]

Does the code line

I_cont:     ais #SpSubSize+3 ;deallocate sub body + H:X + command

precede the line

SpSubSize:  equ (*-SpSub)

?
I have found that my assembler (prior to CW) does not complain about the truncation if it already knows that the high byte is zero. If the reference to "SpSubSize" precedes the definition, it doesn't yet know that.

Message Edited by rocco on 2006-06-25 12:35 AM

[irob]

---

rocco wrote:
Does the code line

I_cont:     ais #SpSubSize+3 ;deallocate sub body + H:X + command

precede the line

SpSubSize:  equ (*-SpSub)

?
I have found that my assembler (prior to CW) does not complain about the truncation if it already knows that the high byte is zero. If the reference to "SpSubSize" precedes the definition, it doesn't yet know that.

Correct, the I_cont line precedes the SpSubSize line. Hmm, the trouble with relocating the definition of

SpSubSize:  equ (*-SpSub)

to before the I_cont line is that SpSub occurs after I_cont.

[rocco]

I don't think there is any way around this message.

At least it is only a warning. But it is a warning that may be destined to annoy you for the rest of your life, maybe longer.

[CarlFST60L_3rd]

Sorry to post in the old thread again. This code is still in the current HCS08RMV1.pdf

Warning (A13003) happens on this line.
I_cont: ais #SpSubSize+3         ;deallocate sub body + H:X + command
                                                    ;H:X flash pointer OK from SpSub

The same warning (A13003) happens on this line.

SpSub:        ldhx  SpSubSize+4,sp        ;get flash address from stack

Going off previous posts, I guess the code works, its just been released with warnings...?

I was wondering, is there any way to tell the compliler that the result of this line:
SpSubSize:    equ   (*-SpSub)
is only allowed to be one byte i.e. cast it as byte? This should stop the warning (i think).

[bigmac]

Hello,

To avoid the warning an equate must be defined before it is used.  As has been said previously, this is easily solved for the first warning, by repositioning the I_cont (routine) code after the SpSub routine.

For the second warning, it is a little more complex, since the first line of SpSub uses SpSubSize value.  A possible work around is to remove the LDHX instruction from the routine, and instead pre-load the H:X value immediately prior to calling this routine.  The calling code can then be positioned after the definition of SpSubSize.  Of course, the offset for the LDHX instruction will need to be adjusted to take into acount that the return address for SpSub is then not present on the stack.

Regards,

Mac

[CompilerGuru]

one way to avoid the message is to declare the SpSubSize to be an external byte label before the first use.
Add before the first use:
 XDEF.B  SpSubSize

Well, I don't like this way too much as it does export a symbol which does otherwise not need to be exported.

The warning for " ldhx  SpSubSize+4,sp" can also be avoided by explicitly marking this access as short with a <
 ldhx  <SpSubSize+4,sp

However that < syntax is not supported for immediate addressing, just for direct/extended/... addressing, so for the first one this syntax does not apply.

Daniel

[bigmac]

Hello irob,

When an immediate value includes some arithmetic, you might need to surround the expression by parenthesis.

I_cont:  ais #(SpSubSize+3)

I seem to recall that I previoulsy experienced a similar problem, but not necessarily with this specific instruction.

Regards,
Mac

[irob]

---

bigmac wrote:

When an immediate value includes some arithmetic, you might need to surround the expression by parenthesis.

I seem to recall that I previoulsy experienced a similar problem, but not necessarily with this specific instruction.

---

Bigmac, thanks for the idea, but that didn't cure it. I tried splitting up the first line into two by first adding the two things and then running the AIS operand. But now I get the same warning at my new ADD operand. Seems that what's choking up the compiler is the second line, SpSubSize: equ (*-SpSub).

What is that equate doing?

[peg]

Hi Rob,

The AIS instruction ONLY accepts immediate and it is sign extended 8-bit. It looks like you are trying to squeeze a bigger value in there.

Also can someone re-rate my two posts referred to here by Rocky, now the wrong one has 5 and the correct none!

Regards David

[irob]

Hmm, my assembly is really rusty. What is the asterisk in the above second line? Is that like casting? Then the minus sign in front of the label SpSub, what's that all about?

Speaking of assembly, can anyone recommend a good resource for syntax? Or a good reference book?

Message Edited by irob on 2006-06-21 06:47 PM

Message Edited by irob on 2006-06-21 06:48 PM

[peg]

Hi Robyn,

The asterisk in this example means current address

the minus sign means minus (just like you learnt in 1st grade)

So the label will equate to the current address less the value of SpSub

Which is perhaps equal to the size of the routine???

Regards David