L1102 Out of Allocation Space LL36/LL64

[PG1]

When we build a project with an LL64 as a target, everything goes fine. The last lines of the map file are:

ExeFile:
--------
Number of blocks to be downloaded: 37
Total size of all blocks to be downloaded: 22502

Question1- Is this truly the number of bytes of ROM that are used, or is something left out.

Now, the amount of RAM is the same on a LL36 but the ROM decreases from ~64K to ~32K. Furthermore, all data objects are much less than  a page window size.

Question2- When we build the same exact project with same settings for LL32, we get L1102 link allocation error indicating there is not enough ROM. But 22502<~36k so there should be enough rom. Any ideas?

[BlackNight · Accepted solution]

Hello,

yes, the 22502 bytes are correct: this is the total size of ROM/Flash needed. But of course this might be distributed over different sections/segments.

About the second thing: have a look at you linker .prm file (at least this is what I have in my MCU10.2 beta):

You should have:

    ROM                      =  READ_ONLY    0xC000 TO 0xFFAB;
    ROM1                     =  READ_ONLY    0x5000 TO 0x7FFF;
    ROM2                     =  READ_ONLY    0xFFC0 TO 0xFFD1;

and:

PLACEMENT

....

    COPY                                /* copy down information: how to initialize variables */
                                        INTO  ROM; /* ,ROM1,ROM2: To use "ROM1,ROM2" as well, pass the option -OnB=b to the compiler */

Notice the comment. And notice that it goes only into ROM (which is for LL32 around 12K).

In order to have it in ROM1 and ROM2:

Add the compiler option -OnB=b (to disable a branch optimization) and change the linker file to

               INTO  ROM ,ROM1,ROM2;

Hope this helps.

[PG1]

I will try this tomorrow.. I sure hope the code does not expand significantly with branch optimizations disabled.

In IDE 5.9.0 the argument will be added via edit, standard settings, compiler. It looks like the new argument stays within the scope of one project and not other projects that may be built in the future.

Thanks for your answer!

[PG1]

Yes this works and gets you into the high 20's of K with one disabled optimization and the small memory model

To get the complete 36K you must switch to banked memory model.

[PG1]

When you use more  than ~26 or so K you are forced to redefine the project using the banked memory model to get access to the remaining flash.

If you define interrupts with the interrupt keyword (and perhaps the other ways as well), you must surround each ISR function with

#pragma CODE_SEG NON_BANKED

void interrupt BLAH blah()

{

}

#pragma CODE_SEG DEFAULT

to ensure that the ISR is placed in non-banked memory....this is because the hardware cannot store a banked address on its stack when an int is asserted.

Otherwise you will get a linker fixup error for which there is little documentation.