need help with Z_RAM allocation error

[jtjans]

Assembly code with codewarrier and a 9S08GB60 processor. Have Z_RAM allocated in .prm file at 0x0080 to 0x00ff.  I have defined enough variables to use memory  0x0080 through 0x00f4.  I get a link error L1102: Out of allocation space in segment Z_RAM at address 0xf5.  What am I missing.  This same allocation method works for me on 9S08QG8 chip with the same CW but with much lower zero page RAM allocation.

[frogman_sr]

Are you making sure that after you have declared your variables in Zeropage that you follow it with a

#pragma DATA_SEG DEFAULT

I was bit by that not too long ago.

frogman_sr

[jtjans]

CW puts the stack in Z-RAM to make the code compatible with the older 6805 code.  Not very usefull because not much else was kept compatible.  I know about moving the stack out of the zero page, which I have done.  Still get the out of allocation space message.  If I just forget about declaring Z-RAM and make all of my RAM the default ram, all of my variables fit into the zero page and I don't get the error message.

JJ

[peg]

Hi JJ,

The _device_ defaults to a stack pointer of $FF for backward compatability  not CW.

The compatability issue is very good IMHO.

My experience is that CW moves the stack pointer to the top of RAM by default and then alocates the RAM from here down to the highest other allocation to the stack.

Did you not glean any info from perusing your .map file as suggested by CC.

BR Peg

Message Edited by peg on 04-27-200609:49 AM

[rhinoceroshead]

Hi Peg,

Do you usually use absolute assembly?  I just tried creating a few test projects and if you do relocatable assembly or C, then the .prm file generated by CW always contains a line that says, "STACKSIZE 0x50".  The size varies depending on the device, but the line is always there on my version.  Then when you simulate, the stack pointer defaults to 0xFF on reset like you said, but the start-up routine (either compiled code, or default relocatable assembly code) initializes the stack pointer to 0x50 bytes higher than the address of the last global variable.  I tried putting "asm LDHX #$00FF; asm TXS;" at the beginning of main(), but then that instruction makes the simulator complain that the device is accessing unallocated memory.  It might work on the actual device in user mode.  I've never tried that.

Do you do this stuff for a living or a hobby?  You answer almost every post here and you are very knowledgable.  Freescale should be paying you.  :smileyhappy:

Message Edited by rhinoceroshead on 04-27-200611:34 AM

[peg]

Hi rhinoceroshead,

I now totally agree with what you said in your last post.

I am _sure_ I have seen this "top of ram stack move" but now when I do a more thorough check the action is how you describe.

Perhaps, like you, I wanted to believe this was what it would do???

I usually write in assembler using P&E tools.

I do this for a living, and a hobby I guess.

Freescale have my address for the cheques.

I have only recently started using CW because of the examples and SMAC for Zigbee stuff.

Regards Peg

Message Edited by peg on 04-28-200608:22 AM

[rhinoceroshead]

Zigbee, huh?  I bought a couple of those DLP-RF2-Z boards from DLP design, but I've been too busy to play with them so far.  I thought it would be fun to build a little remote-controlled robot for my house that I could command from the Internet through a Java applet, and have it send live images back to the browser.  I guess it would be sort of like those Mars rovers, but *slightly* less cool since it would only be exploring my house.  At this point in my life, this stuff is mostly just a hobby for me.  I'm just fascinated by these little things though.  They're simple enough for one person to see a project all the way through in not too much time, but sophisticated enough to do just about anything you can imagine (within reason).

I'd better say something on topic so Alban doesn't have to slap my hand...

How big of a deal is it really to be using that first page of RAM anyway?  I've never worried about the speed boost that gives.  I'm also usually using C, which doesn't necessarily compile into the most efficient code anyway, and I've never had a problem.  If you really are pushing the performance limitations of the device, wouldn't you just use a faster chip?  I could maybe understand reaching the limit if you were running a fast control algorithm or doing some DSP, but the AD converter on this chip isn't all that fast and this isn't the best choice for DSP either.  Has anyone ever had an application that absolutely had to use the direct page addressing mode?

[rocco]

---

rhinoceroshead wrote:

How big of a deal is it really to be using that first page of RAM anyway? I've never worried about the speed boost that gives.

---

You probably don't notice this when you write in C, but some instructions only work in page zero, and others don't have the extended addressing mode available.

The BCLR, BSET, BRCLR and BRSET only work with page-zero. So you need to put bit-flags in page zero.

The MOV, CLR, INC, DEC, COM, NEG, TST, ASL, ASR, LSL, LSR, ROL, ROR, LDHX, STHX, CPHX, CBEQ and DBNZ instructions can directly access page zero, but can only access other addresses indirectly, either relative to the H:X registers or relative to the stack-pointer.

[rhinoceroshead]

Oh really?  I wasn't aware of that.  I've done a lot of assembly on the HC12s, but never bothered to learn the instruction set on the HC08.  The HC12s don't even have RAM in the zero page unless you move it there.  On those chips the direct address mode saves CPU cycles, but doesn't have any limitations in which instructions you can use.  Interesting.  I guess now I'll have to start declaring variables with the 'near' keyword.  But most of what I do is not that time-critical.

[Alban]

tsss... As if I wouldn't myself write something out of subject I'm non violent and maybe even flexible.

In large productions like automotive, the price of each MCU is important. Therefore they will try and stretch the part to its maximum.
I'm thinking that having an Operating System on a HC08 with little RAM could already be a challenge. But I see some Contributors already tackled that, well done !!!

So I forward to the Admins of the board that we need a big fat cheque for Peg !

Cheers,
Alban. {Peace & Love}

[rhinoceroshead]

Alban and Peg,

Based on your spelling of the word 'cheque', and the time of day that you make posts, I would guess that you reside in Australia or perhaps New Zealand.  Am I right?

[peg]

You're half right, click on the username/author for this info.

Perhaps you could setup your own!

Peg

[CrasyCat]

Hello

This message is generated when the area Z_RAM is full.

Where did you place the stack? You can also look at the .map file generated by the linker. You will see a list of the object which have not been allocated because missing memory. 

CrasyCat

[Alban]

Yo,

Yep, I agree with CC, by default the Stack is usually put in the first page coz of the faster execution it gives.

So, for your project, depending on how the stack is declared in the PRM file (by its size or by its start address) you can change the value for it to work.

STILL be careful you have a stack big enough... Stack Overflow is quite difficult to debug, I know by experience that it's one of the last thing you think about looking when everything goes wrong.

So CC, you reading all the boards for Warriors. You are courageous !

Cheers,
Alban.

[peg]

OK Alban, I am going to question your comments on two points.

1. I thought CW's default action was to move the stack to the top of RAM.

2. Does having the stack in page zero make for faster execution. Most stack manipulation is done automatically, like return addresses being pushed on. Perhaps some direct stack data manipultion may be able to be executed faster in page zero but this would be at the loss of space for other data that could be kept there and definately manipulated faster.

BR Peg

[Alban]

Thanks for the Challenge Peg,

I am guilty of talking without checking...
However, I think that you can specify the memory model when you create a project with the wizard and the "tiny" would put things in first page.

I also checked in the CPU datasheet and PUSH POP are inherent and therefore don't care about where the stack is for the usual interrupt and context manipulation.

Fully agree that the first page is better used for often accessed variables.

Thank you for correcting me.
Alban. {useless b4 his coffee?!}

[rhinoceroshead]

I thought that by default, only the stack size (0x50 bytes) is declared in the .prm and then the stack chunk immediately follows the last global variable declaration - at least when programming in C, which is all I have ever done on the HC08.  I usually bump the stack size up to at least 0x0100 bytes immediately after starting a project just to avoid pulling out hair trying to track down bugs that aren't there.  It seems like codewarrior should automatically start it at the end of the RAM and let the stack size default all the way to the end of the global variables, but that's just me.

Message Edited by rhinoceroshead on 04-24-200612:30 PM

[Alban]

Hi Jt,

I dunno what you know and what you don't so I'll say it all. Don't be offended if it looks trivial to you !

Z_RAM is used to allocate in the Page Zero of the MCU. It actually means that the MCU can access this area of memory using addressing in the DIRECT PAGE.

This region cannot move and is bound to finish at 0xFF because it needs to be below 256. The lower boundary will change depending on the registers of the MCU you are using

The advantage of this Direct Page is execution speed. If you look for Assembly instructions using the Direct Addressing, you will see they all take less cycles to execute than if you were trying to access a variable in higher RAM or data in Flash.

To conclude, the programmer will put the most often accessed variable in Z_RAM. However if the Z_RAM is not big enough for all of them, no worries as they will fit in the Higher RAM.

For your particular application, you might have loop indexes in a for loop or other temporary variables you didn't take into account ?

Cheers,

Alban.