Problems moving .cinit section in linker command file

Bob,

Forwarded your message to CCS.  I am not sure they are the ones to answer this, but they should be able to point us to the correct person in the compiler group that may have an idea how to help you.

Regards,
Chris 

Hi Bob,

my suggestion from the error message shown above is the problem caused due to the fact that the  C initialization function of the RTS (Run-Time-Support) library is compiled with small memory model which uses 16 bit pointer. When you put the .cinit section above the 64 KB address space, the RTS library can not reach it anymore. I think the workaround is to recompile the RTS library, and make a custom one. If you are using CCS v5.1, i think this should be easier for you because it comes with the Mklib tool:

http://processors.wiki.ti.com/index.php/Mklib

But let's see also what the CCS and compiler guys will tell us.

-Leo-

Hi Bob,

i just checked, actually there is already an available RTS library for this. I did the following:

- change the Runtime support library selection manually to rts430xl.lib as follows:

- and then set the data model support to large like this:

Then i modify the linker command file like you did:

    .cinit     : {} > FLASH2              /* INITIALIZATION TABLES             */

and compilation works.

In the map file i found the following:

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.pinit     0    00005c00    00000000     UNINITIALIZED

.bss       0    00001c00    00000012     UNINITIALIZED
                  00001c00    00000008     rts430xl.lib : _lock.obj (.bss)
                  00001c08    00000008                  : boot.obj (.bss)
                  00001c10    00000002     main.obj (.bss)

.stack     0    00005b60    000000a0     UNINITIALIZED
                  00005b60    00000004     rts430xl.lib : boot.obj (.stack)
                  00005b64    0000009c     --HOLE--

.text:_isr
*          0    00005c00    0000002a     
                  00005c00    0000002a     rts430xl.lib : boot.obj (.text:_isr:_c_int00_noexit)

.text      0    00005c2a    000000b4     
                  00005c2a    0000005c     rts430xl.lib : autoinit.obj (.text:_auto_init)
                  00005c86    0000002a                  : memcpy.obj (.text:memcpy)
                  00005cb0    00000024     main.obj (.text:main)
                  00005cd4    00000004     rts430xl.lib : pre_init.obj (.text:_system_pre_init)
                  00005cd8    00000004                  : exit.obj (.text:abort)
                  00005cdc    00000002                  : _lock.obj (.text:_nop)

.reset     0    0000fffe    00000002     
                  0000fffe    00000002     rts430xl.lib : boot.obj (.reset)

.cinit     0    00010000    0000000a     
                  00010000    00000008     main.obj (.cinit)
                  00010008    00000002     --HOLE-- [fill = 0]

So i think this should solve the problem.

-Leo-

Hi Bob,

just another additional information.

It seems that the real problem lies on the data_model setting. You do not really need to set the rts support to rts430xl.lib manually as shown above, but instead just leave it as "automatic" per default, and set the data_model either to "restricted" or "large". I think this will automatically uses the rts library with 32(20) bit pointer and enables you to put the .cinit at memory above 64 KB.

-Leo-

Thanks Leo for relpying to this.

Chris

Hi Chris, Leo
I am back working on this again now and I have some further questions.

I notice that run time support libs place a small amount of boot code at the very bottom of Block 0 (0x5C00) - rts430xl.lib : boot.obj

I assume this is because the reset vector is 16 bit so the code this references must be in the same 64K Block (is this correct).

But is it possible to move this into the same 512 byte segment as the Reset vector table, say at 0xFE00, so you only have to erase and program one segment in this Block.

Do I need to place all Int functions in Block 0 or is there a machanism so they can be placed in say Block 1 or Block 2 ?

Thanks
Bob Bacon

Hi Bob,

i am not sure what you are trying to do here. But basically you can always modify the linker command file to adjust the location of the generated binaries.

Hi
I am trying to produce some code, loosely based on the BSL, so my customer can download new firmware while the existing code is still running.
Once it has been received the vector table will be updated to point at the new code. This means the device will be twice the size required and the new code could be in any block.

But the Vector table consists of 16 bit words so is it possible to do a long jump outside the lower 64K Flash Block 0.

I have now tried this and it seems to work but I have no idea how.

For example my ".text:_isr" section is at 0x10930 but how can you jump to this from a 16 bit ISR

When I look at memory under debug it shows 0xFFFE = 0930 but how does MSP430 device select 0x10930 rather than 0x930.

Thanks

Bob Bacon

Hi Bob,

Bob Bacon said:

But the Vector table consists of 16 bit words so is it possible to do a long jump outside the lower 64K Flash Block 0.

i have never tested it myself before, but i think this should be possible. Could you please try to use an "intermediate table" which mean you have another table, let's say it resides in the INFO memory. The "intermediate table" contains the 20 bit addresses, and what you do is in the normal vector table you jump first to this intermediate table, and then use the value in the intermediate table to jump to the real function. With this, i think it is then possible to jump anywhere inside the 20 bit address space.