Code Size Problem with HCS08 and CodeWarrior v6.1

[demoqe128]

Hello Everybody,

I'm an software engineer and I'm working with the DEMOQE128 Board and the controller MC9S08QE128CLH.

I made my first steps with the (free) SPECIAL Edition V.1 of CodeWarrior for Microcontrollers. Now my company bought a FLOATING License of the CodeWarrior Basic Edition, beaucse of the limited code size.

I'm still working with the installed Basic Edition and the floating license was installed on a floating license Server. Can I still use my CodeWarrior Software Version 6.1 or do I need to install an other software version of CodeWarrior?

I'm not sure if my currently used CodeWarrior is licensed or not.. I can't find any information about the license status. Not in the "about box" of my software or elsewehre..

Now my system became very large.. and the limited code size was exceeded... Follwing messages appears out of my linker: "L1102: Out of allocation in segment ROM at address 7FDF..."

It seems like as my CodeWarrior Basic Edition V6.1 is still a Special Edition...

Now, my Questions...
So, what can I do to find out if my CodeWarrior is correctly licensed???
Or, what else could be the cause of my linker error?
And my last general question... Can I still use my (free) special Code Warrior when I want to license it to the basic code warrior.. ?

Thanks a lot!

Cheers!
Sebastian

[CompilerGuru]

Hi Sebastian,
the error message L1102 has nothing to do with the licensing.
The error contains
"address 7FDF" but that is derived from the end address of a segment in the prm file, I guess
its actually 0x7FFF.
Check the prm file, it defines how sections get mapped into the memory, and what the linker tries to tell you is that for ROM there is nothing more available according to your prm.
Given that you have a device with 128k flash, there is probably still a lot of free space, but the prm file does not instruct the linker to use that space for this ROM section.
Given than, which memory model are you using? small? The small memory model generates code to be placed into the 16 bit address space only, therefore prm's generated for that memory model do not use most of the space for code compiled with no explicit section placement. At 0x8000 starts the paged area, that's why the segment ends at 0x7FFF, just before that.
Other things which could explain it:
- are you using a lot of constants?
- single objects larger than 16k?
- tiny memory model...

Things which are completely unrelated: licensing....

About the licensing part of your question, did you check the with the About button in the Settings pages (Linker for HC08, for example)?

When switching licenses, the only think which needs to be adapted is the license.dat in the CodeWarrior root folder. Backup the old one, and replace it with a separate license.dat pointing to your license server in order to use that one. Really I don't know all those licensing details very much though, but I'm sure there is no need to reinstall anything (which works ).

Daniel

[demoqe128]

Hi Daniel,

thank you very much for your explanatory notes!!

I analyzed my project and get this information about it:

Project.map:
ARGET SECTION
---------------------------------------------------------------------------------------------
Processor   : Freescale HC08
Memory Model: SMALL
File Format : ELF (no debug info)
Linker      : SmartLinker V-5.0.30 Build 7285, Oct 13 2007

I have one module, which is very large... This module contains the control and visualization of a menu, which is displayed on a 2-line LCD Display...

Name                                      Data   Code  Const
Menu.c.o                                  1124   5558   2368

*********************************************************************************************
SECTION-ALLOCATION SECTION
Section Name                    Size  Type     From       To       Segment
---------------------------------------------------------------------------------------------
.data                           1069   R/W      0x100      0x52C   RAM
.init                            132     R     0x2080     0x2103   ROM
.startData                        18     R     0x2104     0x2115   ROM
.rodata                         1195     R     0x2116     0x25C0   ROM
.rodata1                        1328     R     0x25C1     0x2AF0   ROM
NON_BANKED                       239     R     0x2AF1     0x2BDF   ROM
.text                          20979     R     0x2BE0     0x7DD2   ROM

Menu.c.o                                Model: SMALL,         Lang: ANSI-C

Is the size of this module too big?? When I add a little function of less lines of code to this module, this Linker Error Message appears...

Is the reason of my linker problem only related to this module or did I exceeded with my complete project the allowed object size....?

Now, I had analyzed the Project.prm :
SEGMENTS /* Here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */
    Z_RAM                    =  READ_WRITE   0x0080 TO 0x00FF;
    RAM                      =  READ_WRITE   0x0100 TO 0x17FF;
    RAM1                     =  READ_WRITE   0x1880 TO 0x207F;
    /* unbanked FLASH ROM */
    ROM                      =  READ_ONLY    0x2080 TO 0x7FFF;
    ROM1                     =  READ_ONLY    0xC000 TO 0xFFAD;
 /* INTVECTS                 =  READ_ONLY    0xFFC0 TO 0xFFFF; Reserved for Interrupt Vectors */
    /* banked FLASH ROM */
    PPAGE_0                  =  READ_ONLY    0x008000 TO 0x00A07F; /* PAGE partially contained in ROM segment */
    PPAGE_2                  =  READ_ONLY    0x028000 TO 0x02BFFF;
    PPAGE_4                  =  READ_ONLY    0x048000 TO 0x04BFFF;
    PPAGE_5                  =  READ_ONLY    0x058000 TO 0x05BFFF;
    PPAGE_6                  =  READ_ONLY    0x068000 TO 0x06BFFF;
    PPAGE_7                  =  READ_ONLY    0x078000 TO 0x07BFFF;
 /* PPAGE_1                  =  READ_ONLY    0x018000 TO 0x01BFFF; PAGE already contained in segment at 0x4000-0x7FFF */
 /* PPAGE_3                  =  READ_ONLY    0x038000 TO 0x03BFFF; PAGE already contained in segment at 0xC000-0xFFFF */
END

How can I tell my system that it can access the ROM1 segment, too... not only the ROM segement which ends at address: 0x7FFF (as you have said, too... ) ???

I think, when I'll tell my system that it can use the ROM1 segment part, too... then this linker error must not appear anymore... Or am I wrong?

The other posibility to reduce the object size of the module menu.c.o is not that easy... because it contains the complete structure of the menu model... which is realized with big arrays, many strings and a lot of different structures...

Thank you very much for your very usefull advices!!

Best regards and cheers,
sebastian :smileyhappy:

[Limestone]

Hi!

This looks like a perfect thread to hijack for my purpose :smileyhappy:

I have the (more or less) exact same problem. Im am on the  MC9S08QE128CLH, I do get the L1102: Out of allocation space in segment. And if I uncomment a HUGE constant variable I have, the problem disappear.

 So, I tried to switched from small to a banked memory model. What I did was

* Change in CPU bean build options from small to banked

* In edit->Standard settings->Compiler->options->Code generation->memory model = banked

* in the file / libs tab, added ansibim.lib and removed ansiis.lib

* In events.c added

#ifdef ISR_IN_NONBANKED
#pragma push
#pragma CODE_SEG __NEAR_SEG NON_BANKED
#endif

before all my handlers ( should it be before static variables as well? )

and

#ifdef ISR_IN_NONBANKED
#pragma pop
#endif

afterwards.

However I still get the same problem.  Btw I am using V6.22 instead. Any suggestions? What have I missed?

Best Regards

Martin

[CompilerGuru]

Not sure if reusing threads is a good idea, in general and also as I'm not sure this is the same issue.

The difference in betweem the small and banked memory model is that in the banked model the code

can use the full available flash. However constants are still limited to the non banked area and as you have a huge constant to comment, I wonder if this is the problem.

Anyway, check in the map file how the memory is used currently. Check that the regular code gets placed banked (regular meaning not interrupt handlers, not compiler runtime support and not startup code, just not stuff which has a special purpose to be non banked). Then check if in the remaing non banked memory area the commented constant would fit. Is there enough space for it?

BTW2: How huge is your constant? If >16k then the prm file needs to contain a block of that size.

Daniel

[Limestone]

Hi!

I more or less solved my own problem by reusing this thread

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=15209&query.id=1928...

 in combination with my own instructions above. Im not compleatly sure that the supplied prm.zip will work compleatly on a MC9S08QE128, but for now,atleastmy memory problems are gone.

The constant was about 4K

Best regards

Martin

[CompilerGuru · Accepted solution]

Hi Sebastian,

Reducing the code size is always good, but not necessary in you case.
There are two ways to provide more space in you case, use the banked memory model (recommended) or to provide additional space in the small memory model.
In order to switch to banked, you have to adapt the compiler options, the prm, use a different set of libraries and
explicitly place interrupt handlers non banked with a
#pragma push
#pragma CODE_SEG __NEAR_SEG NON_BANKED
// handler here....
void __interrupt ....
#pragma pop
(out of my memory, could contain typos)

For the prm, options and libraries, create a new project with the wizard and steal/replicate the setup including the prm (or move the sources into the new project).
(the options, change from -ms to -mb, the libraries described in lib/hc08c/readme.txt, and the prm changes place the code into the banks.)

Anyway, I think it sounds more complicated than it is.
In order to provide more space in the small memory model, you have to change the PLACEMENT part in the prm file to also use the ROM1 area.
One (maybe theoretical) issue there is that the compiler optimization -onb=t can cause link time errors if code from one compiler section is placed into multiple segments in the prm file. It's not really problematic as it will either link and work, or not link, but in order to avoid the issue beforehand either do not place one section into multiple segements (say place DEFAULT_ROM into ROM, and the others into ROM1) or switch off the optimization with -onb=t.

Having said that, using the small memory model still limits the code to the 64 address space, and therefore > 50% of the flash only gets usable for code in the banked memory model. Therefore I would switch now to the banked memory model before you fill up the complete non banked area and have to switch either way.

Daniel

[demoqe128]

Muchas gracias / Vielen Dank.... and thank you very much


I'll try to create a new project with the option "banked memory model" tomorrow and will tell you if the linker error disappear or not.

But your explanation sounds very good to me!

just for background information:
Just now I'm doing my master-thesis on this hc08. The system will be a multifunctional I/O Device with analog  and digital inputs/outputs... a serial computer interface...  a external eeprom memory...  a 2-line lcd display... 2 pwm outputs with configurable output-levels and a option to flexible progammable test-sequence which everytime will be ready to start...

If you need any information or source code about or schematics of:
- spi driver
- iic driver
- eeprom driver
- dogm 2 line lcd driver
- ATV dac driver
- a 2 line lcd based rotating menu (ipod style)
- encoder driver
- pushbutton driver


just contact me!

Once more: Thank you very much!!!

sebastian

[Unknown]

Hello sebastian,

I require generic SPI driver code very urgently.
It would help me if you have it for HCS08 family especially.
Could you please send me the same, if there's no objection.
Thank you.


Regards
xxx

[peg]

Hi xxx,

Generic SPI code is really quite simple.
It's all here!