Absolute Sections in HC(S)12 ASM file

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Absolute Sections in HC(S)12 ASM file

Jump to solution
2,450 Views
bottom_down_pro
Contributor II
Hi folks

I'm new, not only to this forum, but to Freescale micros generally.

I have recently designed an embedded controller using S12XDT512 (single-chip mode), including schematic & PCB layout, and will shortly be installing firmware (written by yours truly) to handle system IO & general housekeeping operations. This is where my remit will end, since although I'm an experienced electronic/hardware designer, I'm only a low-level man from a software point of view (as well as socially). I need to hand over the design, complete with said firmware, to others who are expert in the loftier realms of application programming.

Currently I'm trying to get the hang of CW IDE (V4.7 installed), to produce both assembly and C modules. I've been reading the document called Assembler_HC12.pdf (July 2007 revision), in particular the chapter on Sections. I can be a bit muddle-headed at times (as my forum alias suggests), and my present problem is understanding the rationale behind the ORG directive - or at least what that document says about it.

The following example is given:

XDEF entry

ORG $A00          ; Absolute constant data section.
cst1: DC.B $A6
cst2: DC.B $BC
...
ORG $800          ; Absolute data section.
var: DS.B 1

ORG $C00          ; Absolute code section.
entry:

       < assembly instructions >


It then goes on to explain that two bytes of storage are allocated at $A00. The constant variablecst1 will be allocated one byte at address $8000 and another,cst2, will be allocated one byte at $8001.

How does $8000 relate to the ORG $A00 bit? Is it just a case of someone creating a document by cutting and pasting bits from two earlier documents without changing essential details? Or is my brain even more addled than I thought?

(PS: I have taken a look through past postings, in case the answer may already exist somewhere, but no luck).



Labels (1)
Tags (1)
0 Kudos
Reply
1 Solution
882 Views
CompilerGuru
NXP Employee
NXP Employee
Sorry I somehow missed that this was just a snippet from the manual, well the short answer is that the manual text for this sample is wrong, the numbers don't match the ones used in the sample code :smileysad:.

Can you submit a service request here so that the manual gets fixed? I saw the same buggy sample in the S08 manual in HC08 V6.1 as in HC12 manual in V4.7.

Thanks
Daniel

View solution in original post

0 Kudos
Reply
4 Replies
882 Views
CompilerGuru
NXP Employee
NXP Employee
Obviously in this sample, the cst1 label has the value 0xa00. If you see anything else,
then there must be a bug somewhere.

Note however that unless you also have a "XDEF cst1" exporting cst1,
the cst1 label is visible only inside of this assembly unit.
For example any C variable with the same name declared as "extern char cst1;"
refers to another object. Labels are static by default and behave the same as static objects in C,
there can also be in different C source files different static variables with the same name.

If this is not this issue, and cst1 is not 0xA00, then please provide a full sample reproducing the issue.

Daniel
0 Kudos
Reply
882 Views
bottom_down_pro
Contributor II


CompilerGuru wrote:
Obviously in this sample, the cst1 label has the value 0xa00. If you see anything else,
then there must be a bug somewhere.


Many thanks for your comments, Daniel.

You say, 'if you see anything else ..'. So far I have not actually assembled and loaded any programs into the target system, as I'm still waiting for the first prototype board.

What I'm seeing is in the Assembler Manual: I'm seeing an example piece of code with ORG $A00 immediately followed by a DC.B directive specifying the value of a symbolic constant. This example is meant to illustrate the use of ORG to mark the start of an absolute constant section. Following the example code, I'm seeing an expalantory paragraph that says the ORG directive causes storage space to be allocated in ROM starting at 0xA00, and that the first label following the ORG represents a constant for which one byte of memory is assigned at address 0x8000. The paragraph goes on to make further nonsensical statements.

Although, as I explained, I'm primary an electronic/hardware designer, I do have many years' experience writing software, mainly of a low-level nature and mainly in assembly language (Z80, 8051, PIC Micro, Texas DSPs and others). I have done some embedded C programming and written a few DOS-type computer applications (and one Windows app). I'm therefore reasonably au fait with programming in general, and writing assembly language programs for embedded applications in particular. I have been using ORG directives for more years than I care to mention, and I think I know enough to judge that the present query is more to do with clumsy document editing and lack of adequate proof reading than anything else.

My main reasons for starting this thread are to introduce myself, to confess to being a novice at writing software for HCS12 type processors and generally to benefit from, and in due course (hopefully) to contribute materially to, the discussion. The embedded controller which is the subject of my present project involves a fairly clear distinction between resident firmware and application software - and nor is the firmware all low-level stuff (hardware interface, bootloader etc). For example, it requires a TCP/IP stack to be implemented, with FTP, HTTP and other OSI Application Layer protocols. Since I will be concentrating on the lower levels while others handle the higher level stuff, it is essential to understand compiler/assembler issues like data types, use of registers by the compiler, calling conventions etc. I want as much as possible to avoid a low-level/high-level hiatus developing between them and me.








 

0 Kudos
Reply
883 Views
CompilerGuru
NXP Employee
NXP Employee
Sorry I somehow missed that this was just a snippet from the manual, well the short answer is that the manual text for this sample is wrong, the numbers don't match the ones used in the sample code :smileysad:.

Can you submit a service request here so that the manual gets fixed? I saw the same buggy sample in the S08 manual in HC08 V6.1 as in HC12 manual in V4.7.

Thanks
Daniel
0 Kudos
Reply
882 Views
bottom_down_pro
Contributor II
Thanks Daniel, I'll submit that service request.

I'm favourably impressed with the service request system - I have had some very useful parley as a result of submitting one recently, a technical query relating to memory mapping. Reply came in <12 hours, from one of the Freescale engineers in the Czech Republic. Some very constructive 2-way communication has resulted.

The handle BTW is Neil


0 Kudos
Reply