Constants in banked ROM

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

Constants in banked ROM

2,263 Views
JBM
Contributor IV

I'm using the MC9S08QE128 with CodeWarrior (latest version), banked memory model -- I'm probably going to need most of the 128K.

 

There are a number of threads on constants in banked ROM.  Most, if not all, say that constants need to be in the non-banked ROM.  Is this true?  I am writing a program with a lot of constants (>30K -- lots of proprietary data) so I can't fit it all in non-banked ROM.  I only have about 1/3 of the data compiled in and I'm already getting a linker error:

 

L1102: Out of allocation space in segment ROM at address 0x7FC6

 

which I interpret as too much data since the code that I have in that space is minimal (the map file shows the code to be much less than a few K, but lots of constants).  Is that a correct assumption?

 

I have added ROM1 to the non-banked memory in the prm file which seems to have cleared the linker error, but I'm afraid this is a temporary fix and it will fail when I get the rest of the constants into the code.

 

Any help would be greatly appreciated.

 

Thanks!

 

Brad

Labels (1)
0 Kudos
7 Replies

557 Views
kef
Specialist I

Did you try DEMOQE128_LAP_Dictionary CW example?

 

"Program Files\Freescale\CodeWarrior for Microcontrollers V6.3\(CodeWarrior_Examples)\HCS08\Evaluation Board Examples\DEMOQE128\DEMOQE128_LAP_Dictionary"

 

Example shows how you could have many kilobytes of constant strings in paged memory. So it is possible to have constants not only in non-banked ROM. __LINEAR_SEG section modifier and __linear keyword help creating pointers to linear flash address space. But access to those constants is not simple. You can't access array elements directly or dereference pointer to linear data using C notation. Instead you use macros from mmu_lda.h.

 

Another limitation is data fragmentation. It seems single array can't be larger than page window size. In LAP dictionary example there's quite small array of pointers to strings and all strings are relatively short. But in case you need big array of something - you will need to break your big array into smaller pieces.

I guess L1102 error you got has similar nature. Since non-banked ROM is fragmented and there are two chunks of non-paged flash with addresses <0x8000 and with addresses >=0xC000, you get error when your data needs to cross page window gap.

 

0 Kudos

557 Views
CompilerGuru
NXP Employee
NXP Employee

 

 

Another limitation is data fragmentation. It seems single array can't be larger than page window size. In LAP dictionary example there's quite small array of pointers to strings and all strings are relatively short. But in case you need big array of something - you will need to break your big array into smaller pieces.

I guess L1102 error you got has similar nature. Since non-banked ROM is fragmented and there are two chunks of non-paged flash with addresses <0x8000 and with addresses >=0xC000, you get error when your data needs to cross page window gap.

 


I don't think the fragmentation limitation applies to the S08 banking done with the LAP header. (This limitation does exist for the data S12 banking done with C code, but the S08 case is different.)  For the S08 the increment and the access are done through dedicated HW registers which handle the whole flash as linear block, which increment the full address automatically, so in the end there is no special case when crossing a page boundary.

Could be that for using >16k objects, the prm file has to use flash addresses though (has been some time, don't remember the details).

 

Also the gap in the non banked flash is not an issue for constants at all, there is a code generation optimization which takes advantage of short branch distances, but for constants the gap is not a problem.

Daniel

0 Kudos

557 Views
kef
Specialist I

Daniel,

 

I meant not physical limitation of S08 with LAP/MMU, but Codewarrior limitation. Code below compiles well but due to 16k page size limit doesn't link with L1102 error. There's plenty of free flash available, but data has to fit one of free PGED_ROM SEGMENT's .

 

#include <mmu_lda.h>

#pragma push
#pragma CONST_SEG __LINEAR_SEG PAGED_ROM
const char arr[17000] =
{1,2,3
};

#pragma pop

 

void main(void) {

  __LOAD_LAP_ADDRESS(arr);

}

 

It is similar on S12X. Project wizard default PRM file defines many paged flash segments. Without modifications in prm file It is not possible to allocate >16k array/object in paged flash and access it using global addressing until you combine few segments into single big segment. It is good CW for S12X treats address followed by 'G as global address, else I don't know how it would be possible do define long segments. After I combine few 16k segments into bigger one, I can allocate and access >16k objects. Does CW for S08 understand 'L - linear addresses in PRM files? If not, then I still think that linear flash is fragmented using Codewarrior, because no object in paged flash can cross (adr % 0x4000) == 0 boundary.

 

Gap in nonbanked flash is not a problem for small objects, but how would you allocate object that doesn't fit the biggest available segment?

0 Kudos

557 Views
CompilerGuru
NXP Employee
NXP Employee

Codewarrior supports to allocate objects > 16k (up to the flash size the S08 actually).

Use

 

 

    PPAGE_4                  =  READ_ONLY    0x10000'F TO 0x1FFFF'F; 

 

 

    PPAGE_4                  =  READ_ONLY    0x10000'F TO 0x1FFFF'F;

The 'L is used as address space suffix for logical for the S12 and as the semantic of the S12 logical is quite different to the linear address space of the S08, so 'F for Flash was defined.

 

 

With the 'F syntax the S08 supports bigger objects that the S12, for the S12 there is still the 64k boundary even when using global addressing. For the S08, no such boundary exists.

 

Daniel

 

 

0 Kudos

557 Views
BooleanBob
Contributor IV

I need to use a 9S08QE128 in production and write software for this device. We have the parts in stock. My application uses arrays that surpass the boundaries of a page segment. But the complete program ( code + data)  takes less than 64K of FLASH. The upper half of the available 128 K FLASH is not needed.


I have read the LAP dictionary application note, compiled the application and ran it. I understand the method used but it does no fit my needs and it is complicated in my case. I have read the previous post, but as I am new to this paged memory processor, the linker pragmas and commands still confuse me.


In my case, I need to instruct the compiler and linker to see the memory map as just a plain 64K memory space and allow the tool to place code and data across this space, ignoring the paging mechanism. I don't know if this is really possible.

 

My guess is: if the paged memory PPAGE2 is set at the Paging Window out of reset, the complete memory address range between CPU memory 0x2080 and 0xFFFF could be addressed naturally.


So I changed the .PRM file to look like this:


/* unbanked FLASH ROM */

ROM           =  READ_ONLY    0x2080 TO 0xFFAD; /* almost full 64K map */
//ROM          =  READ_ONLY    0x2080 TO 0x7FFF;
//ROM1         =  READ_ONLY    0xC000 TO 0xFFAD;


The following declaration compiles and links with no errors:


/* example of array declaration */


static const char myarray[50500] = { 10,20,30,40,50,60,70,80,90,100 };


I can see the array correctly allocated in FLASH as listed in the .MAP file


****************************************************************************
SECTION-ALLOCATION SECTION
Section Name                    Size  Type     From       To       Segment
----------------------------------------------------------------------------
.data                              4   R/W      0x100      0x103   RAM
.init                            138     R     0x2080     0x2109   ROM
.startData                        18     R     0x210A     0x211B   ROM
.rodata                        50500     R     0x211C     0xE65F   ROM
.text                            499     R     0xE660     0xE852   ROM
.copy                             10     R     0xE853     0xE85C   ROM
.stack                           896   N/I     0x1D00     0x207F   MY_STK

----------------------------------------------------------------------------


Is this a good procedure ? Is there some other better way ?

I will very much appreciate your valuable opinions.


Kind regards


0 Kudos

557 Views
kef
Specialist I

Daniel, thanks for 'F ! 'F of course removes 16k object size limitation. Any pointers for how to find such details about linker or PRM file? Search for PRM or for 'F suggests a lot, but not what I'm looking for.

0 Kudos

557 Views
CompilerGuru
NXP Employee
NXP Employee

In MCU 10, it is used in the sample and mentioned in a note in here:

 

CodeWarrior for Microcontrollers V10.0 > HCS08/RS08 for Microcontrollers > HC(S)08 Build Tools Reference Manual > Banked Memory Support > Linear Memory Space

 

Daniel

0 Kudos