CALL and RTC instruction details needed.

[tonyp]

In all the manuals, reference guides, app notes etc I looked where there was (very brief ) talk about these two instructions (available only for MMU equipped MCUs, like the 9S08QE128), there was no mention of proper instruction format (e.g..., CALL Page,Address or CALL Extended24-bitAddress) the instruction opcode sequence, or the execution cycles.

I managed to find the opcodes ($AC for CALL xxxxxx and $8D for RTC -- if not, please correct me) but not the cycles (I reckon they should be about 7 for each).  Anyone knows? (I couldn't find an option for the CodeWarrior assembler to force the listing to show cycles, but then again I only had to use it this once -- to get the opcodes I needed -- and I don't it know well enough to dig up all available options, so maybe I missed it.)

By the way, Freescale, you should update your docs.  (Or is this an oversight due to the recent trend of writing all coding examples in C and letting the compiler figure out such trivial details?)

Message Edited by tonyp on 2009-09-11 07:44 PM

[kef]

Some details can be found in QE128 RM :

http://www.freescale.com/files/microcontrollers/doc/ref_manual/MC9S08QE128RM.pdf 

see 8.5 HCS08 Instruction Set Summary

Regarding cycle count in listing, I think you should mention version of tools you are using. I don't know how to configure disassembler output, but by default CW for MCUs V6.2 shows me cycle count. Also you may try opening compiler options -> Output tab and checking Generate Listing File and Configure Listing File and unchecking all relevant don'ts, including show cycle count. *.lst files are put to /bin folder.

[CompilerGuru]

This pdf is also recommended by this link

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=9361

About the cycle counts in the listing, the compiler and the decoder do support to provide the cycle count, the asssembler on its own does not.

When using assembler the decoder can be used by checking the "Use Decoder to generate Disassebly Listing".

Add the "-T" option to the Importer for HC08 tab (this configures the decoder to print the cycles).

With this setup, the Disassemble context menu generates a listing with annotated cycles.

00000000 6E0100   [4]    MOV    #0x01,temp_byte 4058:             NOP                     ; Insert here your own code00000003 9D       [1]    NOP     4060:             RTC                     ; return to caller00000004 8D       [7]    RTC    

For counting cycles the simulator can also be used, open via Components->Open Trace the Trace viewer, configure the trace as "Instruction" and check "Enable Trace", run to the start of the eare to measure, use the Clear context menu to clear the trace content and on the command line use ResetCycles to start counting cycles at 0.

This creates a trace like the one below showing the cycles as well.

   Frame  |       Cpu cycles       |  Address   |          Instruction           |  HX    |ACC |CCR |  SP    |--------------------------------------------------------------------------------------------------------------      0              1                 2094       TSX                              0150      02    68    0149           2              3                 2095       STA    1,X                       014A      02    68    0149           6              6                 2097       LDA    0x2104                    014A      02    68    0149          11              10                209A       INCA                             014A      00    6A    0149          13              11                209B       STA    ,X                        014A      01    68    0149          16              13                209C       LDHX   0x2106                    014A      01    68    0149          22              18                209F       BRA    *+33                      210A      01    68    0149          25              21                20C0       DBNZ   2,SP,*-31                 210A      01    68    0149          32              29                20A1       PSHX                             210A      01    68    0149          35              31                20A2       PSHH                             210A      01    68    0148    

Daniel

 

[tonyp]

The doc you mention would be one logical place for these details but they are not there.  A description of what the commands do and why one would need them, but none of the information I'm looking for.

I think I have the latest CodeWarrior.  I downloaded just a few days ago.   I have already been thru those options you mention, and couldn't find it.

But, can I ask you a favor to make it simpler? If yours shows cycles, can you (or anyone else) assemble this and let me look at the listing with cycles?

       ORG WHATEVER

       CALL NEXT

NEXT RTC

Message Edited by tonyp on 2009-09-11 09:59 PM

[CompilerGuru]

The requested sample:

ISASSEMBLY OF: '_ORG00001' FROM 596 TO 601 SIZE 5 (0X5)
00081234 AC081238 [8]    CALL   0x081238
00081238 8D       [7]    RTC   

[tonyp]

OK, thank you all for your answers.  Indeed, the opcode and cycles were in that PDF (at least after I downloaded it again), I had been thru it a zillion times looking for this and just wouldn't see it, I may be getting a bit old, I guess.)  Anyway, IMO it should also be in the general HCS08RM which covers the whole 9S08 series, and in the app note AN3730 which deals specifically with this subject (please don't tell me they're there too, or I'm off to see an eye doctor.)

OK, now I'm a bit confused, the format shown is "CALL page,addr16".  This implies that the first byte of the three bytes following $AC is just the page (currently, a number from 0 to 7).

But in the example assembly listing (and the one I include below) it looks more like a 24-bit address (no comma, a single 24-bit value, and the value is not converted to page limits $8000-$BFFF with the page byte adjusted accordingly using bits 15 and 14 of the addr16).  Or, is it 24-bit address where the high byte is just the page number, even if it gets outside the ppage window (which is irrelevant in general for the assembler).  In that case the addresses that must be given to the CALL command will not match the extended addresses shown in the memory map ($0000-$1FFFF) as corresponding to the various pages.  So, which is it?

Freescale HC08-Assembler
(c) Copyright Freescale 1987-2008

 Abs. Rel.   Loc    Obj. code   Source line
 ---- ----   ------ ---------   -----------
    1    1                                          org       $1000
    2    2
    3    3  a001000 AC 08 FFFF                      call      $08FFFF
    4    4  a001004 8D                              rtc

 

 For example, to CALL extended address $1C000 (as shown in fig. 4-1 MC9S08QE128RM), which is the first byte of PAGE 7, should one do CALL $078000 or CALL $01C000?

[kef]

Tonyp, 

Regarding missing something in the docs. Using pdf search it's quite hard to miss single CALL occurence in the whole document, isn't it? But I didn't tell you something new, I hope.

[CompilerGuru]

It's the "Or, is it 24-bit address where the high byte is just the page number, even if it gets outside the ppage window (which is irrelevant in general for the assembler)" case.

So use  CALL $078000

I call this addressing schema paged addressing, the bits 16..23 of the address go unmodified into the PPAGE register regardless if the lower 16 bits are in the PPAGE window range or not.

I actually never used those "extended addresses" addressing format.

Daniel
 

[tonyp]

OK, then, things are becoming clearer.  One final question, though.

If the address to use for CALL is $078000 (in my example), is that same address the one that will go into the S2 record (to be used by programmers, simulators, etc.), or do I need to convert it to the extended address shown in the memory map section ($01C000)?  In other words, will all tools for the 9S08 interpret 24-bit paged addresses the same way?  If so, then are the extended addresses shown in the memory map ever used anywhere at all, or are they completely irrelevant and then why would the manual even bother to show them that way if they're never to be used as such?

(Kef, yes, searching PDFs is always my first step, then I still go over it again page by page in case some info is embedded in images.  Still missed it, go figure!)

Thank you all again for your help.

[kef]

S08 extended addresses are used at least in MMU Linear Address Pointer Registers, please check in RM:

4.4.2.2 Linear Address Pointer Registers 2:0 (LAP2:LAP0)

I wouldn't assume all tools will interpret 24-bit paged addresses the same way. From S12 experience, old CodeWarrior version used banked format S-records, where S2 record address is PPAGE : 16bit CPU address. But P&E PROG12z burner and (AFAIK) FSL Factory Programming required physical format S-records (the same like S08 extended/linear address). Then project wizards from more fresh CW versions started generating burner scripts to create both banked and physical/linear/global S-records files. I don't know what are current P&E requirements for paged S08, but CodeWarrior for S08 by default generates banked S-records...

Message Edited by kef on 2009-09-12 04:22 PM

[tonyp]

Now, that I look at it again, should the format "CALL page, opr16" be "CALL page: opr16" instead, with a colon (for concatenation) rather than a comma?  That would clear things up.

[CompilerGuru]

The link Kef did post does show the cycles in the "HCS08 Instruction Set Summary" page,

8 cycles for a CALL (with 24 bit address), 7 for a RTC.

The opcodes (0x8D for RTC, 0xAC for CALL) are also contained in that table

Also the "Table 8-3. Opcode Map" contains the same information.

The CALL instruction is using a big endian 24 bit paged address (page first) (worth to be mentioned as it is different from the S12's CALL).

 

Would be nice if there would be an updated ref manual :smileysad:.

Daniel

Message Edited by CompilerGuru on 2009-09-11 02:07 PM