RTOS/CC1310: Jumping between two applications in flash

Mad River

Expert 2395 points

Part Number: CC1310

Tool/software: TI-RTOS

Hi,

I am having problems to consistantly jump between two applications stored in the CC1310 flash.

My product have two firmwares stored in the flash: bootloader and application.

Bootloader is stored at address 0x0000.

Application is stored at address 0x6000.

I tested each jump individually:

1. Start the CC1310 at bootloader and then jump to application. It is working!

Jump code:

asm(" MOV R0, #0x06000 "); 
asm(" LDR R1, [R0, #0x4] "); 
asm(" LDR SP, [R0, #0x0] "); 
asm(" BX R1 ");

2. Start the CC1310 at application and then jump to bootloader. It is working:

Jump code:

asm(" MOV R0, #0x00000 "); 
asm(" LDR R1, [R0, #0x4] "); 
asm(" LDR SP, [R0, #0x0] "); 
asm(" BX R1 ");

But what I really need to do is jump from application to bootloader, performe some action and then jump back to application.

Today I can jump from application to bootloader, but can't jump back to application. As I said above, the jump from bootloader to application works fine when I start the CC1310 at bootloader, it was tested.

Putting it simple: I can jump from one firmware to the other, but I can't jump back to the first one.

Do you have some clue?

Is there a better way to do the jump?

over 9 years ago

0 Alan DeMars over 9 years ago

TI__Mastermind 30830 points

There are lots of ways this could go bad.

Are the bootloader and/or application TI-RTOS projects? Are either are both built against the BIOS in ROM? Which code owns the reset vector table (ie the one fetched from at reset time from flash locations 0x0 and 0x4?). Is there a chance that an interrupt caused by one of the two applications is not serviced or disabled prior to exiting that application, leaving it armed and dangerous for the other application?

When you say "jump back to application" what does that mean? Are you calling an API within the bootloader image from the application and then returning? Or are you jumping to the entry point of the boot loader after starting the application and then wanting to return to where you left off in the application?

Alan

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

Are the bootloader and/or application TI-RTOS projects?

Both of them are TI-RTOS projects.

Are either are both built against the BIOS in ROM?

I don't know if I understood your question, but both project are configured as follows:

/* ================ ROM configuration ================ */
/*
 * To use BIOS in flash, comment out the code block below.
 */
var ROM = xdc.useModule('ti.sysbios.rom.ROM');
if (Program.cpu.deviceName.match(/CC26/)) {
    ROM.romName = ROM.CC2650;
}
else if (Program.cpu.deviceName.match(/CC13/)) {
    ROM.romName = ROM.CC1350;
}

Which code owns the reset vector table (ie the one fetched from at reset time from flash locations 0x0 and 0x4?)

Again, I don't know if I understood your question. I think both of them have the reset vector. I only changed the following in the .cfg file:

Bootloader:

/*
 * Assign an address for the reset vector.
 *
 * Default is 0x0, which is the start of Flash. Ordinarily this setting should
 * not be changed.
 */
m3Hwi.resetVectorAddress = 0x0;

Application:

/*
 * Assign an address for the reset vector.
 *
 * Default is 0x0, which is the start of Flash. Ordinarily this setting should
 * not be changed.
 */
m3Hwi.resetVectorAddress = 0x6000;

When you say "jump back to application" what does that mean?

I don't need to jump back to where I left off. When I say JUMP I always mean to go to the start of the firmware, either bootlloader or application. Every time I "jump" I want to start running the destination firmware from the beginning.

Thank you for trying to understand my problem.

Please, ask as many questions as you need to understand it. That is the only issue remaining to finish my product.

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

Switching between two projects that have been built using the BIOS in ROM (as you have definitely done) is very difficult to achieve since the BIOS code in the ROM has references to objects at fixed locations within flash (const data) as well as RAM (bss data). The linker command files for both projects will place the ROM referenced BIOS objects at the addresses required. However, the content of those objects will be different for each application. Some of the object content will be pointers into the application code base.

In order to avoid overlapping object placements between the boot loader and the application, one or both of the projects must be built NOT using the ROM (ie comment out the ROM.romName assignments in your .cfg file). (I'd recommend that the boot loader not be built against the ROM.) Make sure that none of the section placements of either application overlap with each other by careful analysis of the generated .map files. Modify the non-ROM project's linker command file as necessary to avoid object overlap.

Alan

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

Hi Alan,

Thank you for your feedback so far.

In order to avoid overlapping object placements between the boot loader and the application, one or both of the projects must be built NOT using the ROM (ie comment out the ROM.romName assignments in your .cfg file).

I commented the ROM.romName in the bootloader .cfg file, but the problem remains.

Please, can you take a look at the .cmd files? I am not sure about the CCFG placement.

1) Bootloader .cmd file:

/* Override default entry point.                                             */
--entry_point ResetISR
/* Allow main() to take args                                                 */
--args 0x8
/* Suppress warnings and errors:                                             */
/* - 10063: Warning about entry point not being _c_int00                     */
/* - 16011, 16012: 8-byte alignment errors. Observed when linking in object  */
/*   files compiled using Keil (ARM compiler)                                */
--diag_suppress=10063,16011,16012

/* The starting address of the application.  Normally the interrupt vectors  */
/* must be located at the beginning of the application.                      */
#define FLASH_PAGE_SIZE 4096

#define FLASH_ADDR              0x0
#define FLASH_SIZE              0x20000

#define BOOTLOADER_ADDR         FLASH_ADDR
#define BOOTLOADER_SIZE         (FLASH_PAGE_SIZE * 6)

#define APPLICATION_ADDR        (BOOTLOADER_ADDR + BOOTLOADER_SIZE)
#define APPLICATION_SIZE        (FLASH_PAGE_SIZE * 25)

#define CCFG_ADDR		(APPLICATION_ADDR + APPLICATION_SIZE) // CCFG is stored in the last page
#define CCFG_SIZE		(FLASH_PAGE_SIZE * 1)

#define RAM_BASE                0x20000000
#define RAM_SIZE                0x5000

__FLASH_ADDR      = FLASH_ADDR;
__FLASH_SIZE      = FLASH_SIZE;
__FLASH_APPLICATION_ADDR = APPLICATION_ADDR;
__FLASH_APPLICATION_SIZE = APPLICATION_SIZE;

/* System memory map */

MEMORY
{
    BOOTLOADER (RX) : origin = BOOTLOADER_ADDR, length = BOOTLOADER_SIZE

    APPLICATION (RX) : origin = APPLICATION_ADDR, length = APPLICATION_SIZE

    SRAM (RWX) : origin = RAM_BASE, length = RAM_SIZE

    CCFG (RX)  : origin = CCFG_ADDR, length = CCFG_SIZE
}

/* Section allocation in memory */

SECTIONS
{
    .text           :   > BOOTLOADER
    .const          :   > BOOTLOADER
    .constdata      :   > BOOTLOADER
    .rodata         :   > BOOTLOADER
    .cinit          :   > BOOTLOADER
    .pinit          :   > BOOTLOADER
    .init_array     :   > BOOTLOADER
    .emb_text       :   > BOOTLOADER
    .application    :   > APPLICATION
    .ccfg           :   > CCFG (HIGH)

#ifdef __TI_COMPILER_VERSION__
#if __TI_COMPILER_VERSION__ >= 15009000
    .TI.ramfunc     : {} load=FLASH, run=SRAM, table(BINIT)
#endif
#endif
    .data           :   > SRAM
    .bss            :   > SRAM
    .sysmem         :   > SRAM
    .stack          :   > SRAM (HIGH)
    .nonretenvar    :   > SRAM
}

2) Application .cmd file:

/*
 *  ======== CC1310_LAUNCHXL.cmd ========
 *  CC26x0F128 PG2 linker configuration file for Code Composer Studio
 */

/* Override default entry point.                                             */
--entry_point ResetISR
/* Allow main() to take args                                                 */
--args 0x8
/* Suppress warnings and errors:                                             */
/* - 10063: Warning about entry point not being _c_int00                     */
/* - 16011, 16012: 8-byte alignment errors. Observed when linking in object  */
/*   files compiled using Keil (ARM compiler)                                */
--diag_suppress=10063,16011,16012

/* The starting address of the application.  Normally the interrupt vectors  */
/* must be located at the beginning of the application.                      */
#define FLASH_PAGE_SIZE 		4096

#define FLASH_BASE              0x6000 //0x0
#define FLASH_SIZE              (FLASH_PAGE_SIZE * 25)
//#define CCFG_BASE				(FLASH_PAGE_SIZE * 31) // CCFG was stored by the bootloader
//#define CCFG_SIZE				(FLASH_PAGE_SIZE * 1)
#define RAM_BASE                0x20000000
#define RAM_SIZE                0x5000

/* System memory map */

MEMORY
{
    /* Application stored in and executes from internal flash */
    FLASH (RX) : origin = FLASH_BASE, length = FLASH_SIZE
    /* Application uses internal RAM for data */
    SRAM (RWX) : origin = RAM_BASE, length = RAM_SIZE

    //CCFG (RX)  : origin = CCFG_BASE, length = CCFG_SIZE // CCFG was stored by the bootloader
}

/* Section allocation in memory */

SECTIONS
{
    .text           :   > FLASH
    .const          :   > FLASH
    .constdata      :   > FLASH
    .rodata         :   > FLASH
    .cinit          :   > FLASH
    .pinit          :   > FLASH
    .init_array     :   > FLASH
    .emb_text       :   > FLASH
    //.ccfg           :   > CCFG (HIGH) // CCFG was stored by the bootloader

#ifdef __TI_COMPILER_VERSION__
#if __TI_COMPILER_VERSION__ >= 15009000
    .TI.ramfunc     : {} load=FLASH, run=SRAM, table(BINIT)
#endif
#endif
    .data           :   > SRAM
    .bss            :   > SRAM
    .sysmem         :   > SRAM
    .stack          :   > SRAM (HIGH)
    .nonretenvar    :   > SRAM
}

As you can see, the bootloader cover all the flash and, because of that, is stored first. Then, the application is stored in the "reserverd" space.

I don't you if this approach is correct.

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

To my understanding, you can not relocate the CCFG area. It must be placed at the end of flash beginning at address 0x1ffa8.

To avoid overlap between the bootloader and the application, the bootloader's .cmd file should not place ANYTHING in flash between addresses 0x1000 and 0x1700. Those addresses are where the ROM code expects its .const section objects to be. Also, the RAM addresses between 0x20000100 and 0x20000600 should be avoided as this is where the ROM code expects its .bss section objects to be.

Alan

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

Thank you, Alan!

To my understanding, you can not relocate the CCFG area. It must be placed at the end of flash beginning at address 0x1ffa8.

I am placing the CCFG in the beginning of the last page. Is it incorrect?

To avoid overlap between the bootloader and the application, the bootloader's .cmd file should not place ANYTHING in flash between addresses 0x1000 and 0x1700. Those addresses are where the ROM code expects its .const section objects to be. Also, the RAM addresses between 0x20000100 and 0x20000600 should be avoided as this is where the ROM code expects its .bss section objects to be.

The bootloader yet starts at 0x00000 but I can't place any SECTION between those addresses?

Can you show me a example of how to do what you suggested?

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

"I am placing the CCFG in the beginning of the last page. Is it incorrect?"

Yes, that is INCORRECT. It must be placed at the end of flash at address 0x1ffa8.

"The bootloader yet starts at 0x00000 but I can't place any SECTION between those addresses?
Can you show me a example of how to do what you suggested?"

I think you'll have to break the flash memory specific into multiple regions (ie 'FLASHA' and 'FLASHB') that hop over 0x1000 - 0x1700 and then use this syntax for placing content into flash:

.text : > FLASHA | FLASHB
.const : > FLASHA | FLASHB
...

And similarly with SRAM:

.data : > SRAMA | SRAMB
.bss : > SRAMA | SRAMB
...

Having never attempted to accomplish what you're trying to do, I'm kinda guessing here.

Alan

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

Hi Alan,

Right now the bootloader is using 7 pages of flash, application is using 24 pages and CCFG is using 1 page.

The 24 pages of the application are almost fully used and I am worried about the future. I will have problems if I increase the application in the future.

I think that 7 pages to a simple bootloader is too much and a large part of it is due to the TI-RTOS.

I tried to implement the bootloader without using the TI-RTOS, only using the driverlib, but I could not initialize the uController and TI doesn't provide any example of how to do it without TI-RTOS.

As both bootloader and TI-RTOS uses the same TI-RTOS code, is there a way of puting it in a known location in the flash memory and both (bootloader and application) share the same code?

If not, I will appreciate any other tip of how to minimize the bootloader code size.

Thank you in advance.

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

I think you'll have to break the flash memory specific into multiple regions (ie 'FLASHA' and 'FLASHB') that hop over 0x1000 - 0x1700 and then use this syntax for placing content into flash:

.text : > FLASHA | FLASHB
.const : > FLASHA | FLASHB
...

And similarly with SRAM:

.data : > SRAMA | SRAMB
.bss : > SRAMA | SRAMB
...

Hi Alan,

I tried to do what you suggested.

That is what I made:

#define FLASH_PAGE_SIZE 4096

#define FLASH_ADDR              0x0
#define FLASH_SIZE              0x20000

#define BOOTLOADER_PART_1_ADDR  0x0000
#define BOOTLOADER_PART_1_SIZE  0x1000

#define BOOTLOADER_PART_2_ADDR  0x1700
#define BOOTLOADER_PART_2_SIZE  ((FLASH_PAGE_SIZE * 7) - (0x1700))

#define APPLICATION_ADDR        (BOOTLOADER_PART_2_ADDR + BOOTLOADER_PART_2_SIZE)
#define APPLICATION_SIZE        (FLASH_PAGE_SIZE * 24)

#define CCFG_ADDR				(APPLICATION_ADDR + APPLICATION_SIZE)
#define CCFG_SIZE				(FLASH_PAGE_SIZE * 1)

#define RAM_BASE                0x20000000
#define RAM_SIZE                0x5000

#define RAM_PART_1_ADDR RAM_BASE
#define RAM_PART_1_SIZE (0x20000100 - RAM_PART_1_ADDR)

#define RAM_PART_2_ADDR 0x20000600
#define RAM_PART_2_SIZE ((RAM_SIZE + RAM_BASE) - RAM_PART_2_ADDR)

/* System memory map */

MEMORY
{
    BOOTLOADER_PART_1 (RX) : origin = BOOTLOADER_PART_1_ADDR, length = BOOTLOADER_PART_1_SIZE
    BOOTLOADER_PART_2 (RX) : origin = BOOTLOADER_PART_2_ADDR, length = BOOTLOADER_PART_2_SIZE

    APPLICATION (RX) : origin = APPLICATION_ADDR, length = APPLICATION_SIZE

    SRAM_PART_1 (RWX) : origin = RAM_PART_1_ADDR, length = RAM_PART_1_SIZE
    SRAM_PART_2 (RWX) : origin = RAM_PART_2_ADDR, length = RAM_PART_2_SIZE

    CCFG (RX)  : origin = CCFG_ADDR, length = CCFG_SIZE
}

/* Section allocation in memory */

SECTIONS
{
    .text           :   > BOOTLOADER_PART_1 | BOOTLOADER_PART_2
    .const          :   > BOOTLOADER_PART_1 | BOOTLOADER_PART_2
    .constdata      :   > BOOTLOADER_PART_1 | BOOTLOADER_PART_2
    .rodata         :   > BOOTLOADER_PART_1 | BOOTLOADER_PART_2
    .cinit          :   > BOOTLOADER_PART_1 | BOOTLOADER_PART_2
    .pinit          :   > BOOTLOADER_PART_1 | BOOTLOADER_PART_2
    .init_array     :   > BOOTLOADER_PART_1 | BOOTLOADER_PART_2
    .emb_text       :   > BOOTLOADER_PART_1 | BOOTLOADER_PART_2
    .application    :   > APPLICATION
    .ccfg           :   > CCFG (HIGH)

    .data           :   > SRAM_PART_1 | SRAM_PART_2
    .bss            :   > SRAM_PART_1 | SRAM_PART_2
    .sysmem         :   > SRAM_PART_1 | SRAM_PART_2
    .stack          :   > SRAM_PART_2 (HIGH)
    .nonretenvar    :   > SRAM_PART_1 | SRAM_PART_2
}

But I am getting a error refering to DEFAULT and I don't know what it means.

I hope the following print-screens can help you to understand.

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

It appears you have another .cmd file somewhere in your project that has a "DEFAULT" memory region specified. You should try 'grep'ping in your project directory for "DEFAULT".

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

It appears you have another .cmd file somewhere in your project that has a "DEFAULT" memory region specified. You should try 'grep'ping in your project directory for "DEFAULT".

I made a FILE SEARCH selecting all file extersions.

That is what I got:

I don't think this is related.

Do you have any other clue?

Maybe this DEFAULT is configured somewhere in the project configuration?

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

Hmm. Do you see "DEFAULT" mentioned in the generated .map file? Even if the link fails, a .map file is generated in the same directory as the .xml file you found.

Is this project referencing any external files? (ie could there be an external .cmd file include in the project).

Alan

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

Hmm. Do you see "DEFAULT" mentioned in the generated .map file? Even if the link fails, a .map file is generated in the same directory as the .xml file you found.

Is this project referencing any external files? (ie could there be an external .cmd file include in the project).

Alan

Hi Alan,

I could not find any external .cmd in my project.

Is it possible that TI folders (such as TI-RTOS and drivers) included from without the project can contain this DEFAULT declaration?

That is my project include list:

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

At least part of the problem is that the MEMORY definition section does not include a definition for the RAM memory used by the TIRTOS code (0x20000100 to 0x20000600).
Nor does it have a definition for the flash memory used by TIRTOS (0x1000-0x1700). Consequently, the linker gets mad when it can't place objects in that region.

Try adding this to your MEMORY definition:

SRAM_RTOS (RWX) : origin = 0x20000100, length = 0x600
FLASH_RTOS (RW) : origin = 0x00001000, length = 0x700

This should help.

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

At least part of the problem is that the MEMORY definition section does not include a definition for the RAM memory used by the TIRTOS code (0x20000100 to 0x20000600).
Nor does it have a definition for the flash memory used by TIRTOS (0x1000-0x1700). Consequently, the linker gets mad when it can't place objects in that region.

Try adding this to your MEMORY definition:

SRAM_RTOS (RWX) : origin = 0x20000100, length = 0x600
FLASH_RTOS (RW) : origin = 0x00001000, length = 0x700

This should help.

Hi Alan,

I am still struggling to get my two programs working in the same flash memory.

My last attempt was what you suggested.

Can you review it, please?

#define FLASH_PAGE_SIZE 0x1000

#define FLASH_ADDR              0x0
#define FLASH_SIZE              0x20000

#define BOOTLOADER_PART0_ADDR	0x0000 	// First part goes from 0x0000 to 0x1000
#define BOOTLOADER_PART0_SIZE	0x1000 	// We can't go beyond 0x1000 because there are RTOS stuff in there

#define FLASH_RTOS_OBJ_ADDR		0x1000 	// RTOS stuff is stored from 0x1000 to 0x1700
#define FLASH_RTOS_OBJ_SIZE		0x700

#define BOOTLOADER_PART1_ADDR	0x1700	// Second part goes until page 7
#define BOOTLOADER_PART1_SIZE	(0x7000 - 0x1700)

#define APPLICATION_ADDR		0x7000	// Application goes from page 7 until page 31
#define APPLICATION_SIZE		(0x1F000 - 0x7000)

#define CCFG_ADDR				0x1F000	// CCFG is stored at the end of the last page (keyword HIGH used in SECTIONS)
#define CCFG_SIZE				0x1000

#define RAM_BASE                0x20000000
#define RAM_SIZE                0x5000

#define RAM_PART0_ADDR		0x20000000					// Fist part goes from 0x20000000 to 0x20000100
#define RAM_PART0_SIZE		(0x20000100 - 0x20000000) 	// We can't go beyond 0x20000100 because there are RTOS stuff in there

#define RAM_RTOS_OBJ_ADDR	0x20000100	// RTOS stuff is stored from 0x20000100 to 0x20000600
#define RAM_RTOS_OBJ_SIZE	(0x20000600 - 0x20000100)

#define RAM_PART1_ADDR		0x20000600 // Second part goes until the end of RAM
#define RAM_PART1_SIZE		((RAM_BASE + RAM_SIZE) - 0x20000600)

/* System memory map */

MEMORY
{
    BOOTLOADER_PART0 (RX) 	: origin = BOOTLOADER_PART0_ADDR, length = BOOTLOADER_PART0_SIZE
    FLASH_RTOS_OBJ (RW)		: origin = FLASH_RTOS_OBJ_ADDR, length = FLASH_RTOS_OBJ_SIZE
    BOOTLOADER_PART1 (RX)	: origin = BOOTLOADER_PART1_ADDR, length = BOOTLOADER_PART1_SIZE
    APPLICATION (RX)		: origin = APPLICATION_ADDR, length = APPLICATION_SIZE
    CCFG (RX)				: origin = CCFG_ADDR, length = CCFG_SIZE

    RAM_PART0 (RX)		: origin = RAM_PART0_ADDR, length = RAM_PART0_SIZE
    RAM_RTOS_OBJ (RWX)	: origin = RAM_RTOS_OBJ_ADDR, length = RAM_RTOS_OBJ_SIZE
    RAM_PART1 (RX)		: origin = RAM_PART1_ADDR, length = RAM_PART1_SIZE
}

/* Section allocation in memory */

SECTIONS
{
    .text           :   > BOOTLOADER_PART0 | BOOTLOADER_PART1
    .const          :   > BOOTLOADER_PART0 | BOOTLOADER_PART1
    .constdata      :   > BOOTLOADER_PART0 | BOOTLOADER_PART1
    .rodata         :   > BOOTLOADER_PART0 | BOOTLOADER_PART1
    .cinit          :   > BOOTLOADER_PART0 | BOOTLOADER_PART1
    .pinit          :   > BOOTLOADER_PART0 | BOOTLOADER_PART1
    .init_array     :   > BOOTLOADER_PART0 | BOOTLOADER_PART1
    .emb_text       :   > BOOTLOADER_PART0 | BOOTLOADER_PART1
    .application    :   > APPLICATION
    .ccfg           :   > CCFG (HIGH)

    .data           :   > RAM_PART0 | RAM_PART1
    .bss            :   > RAM_PART0 | RAM_PART1
    .sysmem         :   > RAM_PART0 | RAM_PART1
    .stack          :   > RAM_PART1 (HIGH)
    .nonretenvar    :   > RAM_PART0 | RAM_PART1
}

It is not compiling.

I am getting the error:

program will not fit into available memory. placement with alignment fails for section ".text" size 0x5e40 . Available memory ranges:
BOOTLOADER_PART0 size: 0x1000 unused: 0x9e6 max hole: 0x9e6
BOOTLOADER_PART1 size: 0x5900 unused: 0x5900 max hole: 0x5900

I think it means that I need 0x5e40 sequencial free space and the maximum I have is 0x5900.

Is there a way to tell to the linker to break that 0x5e40 in two parts?

EDIT:

The error above appears when I compile the bootloader project.

Below is the error that appears when I compile the application project. In that case, the problem occurs with the RAM.

I have two parts with a total space of 0x628 (0x38 + 0x5F0). But the linker is trying to place a "piece" with 0x93b.

Before I declare and reserve space to RAM_RTOS_OBJ (RWX) the project was fiting in RAM. I am wondering if the linker is ignoring that space since I am not explict putting anything in it in the SECTIONS:

// NOTHING IS ATTRIBUTED TO RAM_RTOS_OBJ
.data           :   > RAM_PART0 | RAM_PART1
.bss            :   > RAM_PART0 | RAM_PART1
.sysmem         :   > RAM_PART0 | RAM_PART1
.stack          :   > RAM_PART1 (HIGH)
.nonretenvar    :   > RAM_PART0 | RAM_PART1

RAM_PART0 size: 0x100 unused: 0x38 max hole: 0x38
RAM_PART1 size: 0x4a00 unused: 0x5f0 max hole: 0x5f0

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

Try using the '>>' operator in your .text, .const, .data, and .bss placements.

.text : >> BOOTLOADER_PART0 | BOOTLOADER_PART1

This informs the linker that the sections can be broken up into smaller pieces.

Alan

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

Try using the '>>' operator in your .text, .const, .data, and .bss placements.

.text : >> BOOTLOADER_PART0 | BOOTLOADER_PART1

This informs the linker that the sections can be broken up into smaller pieces.

Alan

Hi Alan,

Thank you for your quick answer.

Now the error changed a little:

"../source files/low level/inc/CC1310_LAUNCHXL.cmd", line 102: error #10099-D: program will not fit into available memory. run placement with alignment fails for section ".data" size 0xa26 . Available memory ranges:
RAM_PART0 size: 0x100 unused: 0x0 max hole: 0x0
RAM_PART1 size: 0x4a00 unused: 0x0 max hole: 0x0

It seems that the linker now is using all the space available in the first part. But I can't understand why it can't place the rest in the second part. The .data have size 0xa26, the second part have size 0x4a00.

Please, review the memory ranges:

#define RAM_BASE            0x20000000
#define RAM_SIZE            0x5000

#define RAM_PART0_ADDR		0x20000000					// Fist part goes from 0x20000000 to 0x20000100
#define RAM_PART0_SIZE		(0x20000100 - 0x20000000) 	// We can't go beyond 0x20000100 because there are RTOS stuff in there

#define RAM_RTOS_OBJ_ADDR	0x20000100	// RTOS stuff is stored from 0x20000100 to 0x20000600
#define RAM_RTOS_OBJ_SIZE	(0x20000600 - 0x20000100)

#define RAM_PART1_ADDR		0x20000600 // Second part goes until the end of RAM
#define RAM_PART1_SIZE		((RAM_BASE + RAM_SIZE) - 0x20000600)

EDIT:
The problem happens because it ran out of memory (image below).
Before I reserve the RAM_RTOS_OBJ space, the project was compiling and using 97% of the RAM.
The wierd thing is that the reserved space is empty. Is the linker even using it?

EDIT2:

In order to compile it, I reduced some buffers size (which can't be reduced in the final product) and the application compiled.

Below is the result.

My question is: Why are the TI-RTOS objects placed in the application area? I really need the space they are using and their reserved space is empty.

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

Alan DeMars said:

My question is: Why are the TI-RTOS objects placed in the application area? I really need the space they are using and their reserved space is empty.

Hi Alan,

Please, could you give a feedback about that issue?

Thank you in advance!

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

BIOS in ROM actually uses only 0x104 bytes of RAM starting at 0x20000100. You can decrease the length of RAM_RTOS_OBJ_SIZE accordingly. This RAM region contains the module state variables referenced by the ROM code.

Alan

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

Alan DeMars said:
BIOS in ROM actually uses only 0x104 bytes of RAM starting at 0x20000100. You can decrease the length of RAM_RTOS_OBJ_SIZE accordingly. This RAM region contains the module state variables referenced by the ROM code.

Alan

Hi Alan,

Thank you for your feedback.

I don't know if I did not understood what you mean, but it still doesn't explain why that section is empty (as you can see in my print).

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

I guess I'm also confused. When you build an application against the BIOS in ROM, the build flow (linker commands) will force the placement of the RAM objects needed by BIOS into the region between 0x20000100 and 0x20000204. If you're application is not built against the BIOS in ROM, then that RAM region can be used by the application.

If you're switching back and forth between two applications, one of which is built against the BIOS in ROM and one that isn't, the application that is NOT built against the BIOS in ROM MUST NOT CORRUPT THE RAM CONTENT used by the application which is built against the BIOS in ROM.

0 Mad River over 9 years ago in reply to Alan DeMars

Expert 2395 points

I guess I'm also confused. When you build an application against the BIOS in ROM, the build flow (linker commands) will force the placement of the RAM objects needed by BIOS into the region between 0x20000100 and 0x20000204. If you're application is not built against the BIOS in ROM, then that RAM region can be used by the application.

If you're switching back and forth between two applications, one of which is built against the BIOS in ROM and one that isn't, the application that is NOT built against the BIOS in ROM MUST NOT CORRUPT THE RAM CONTENT used by the application which is built against the BIOS in ROM.

I think we are not understanding each other.

Let me review some steps.

1. You told me to "reserve" a flash and a ram area which could not be written to.

2. I reserved that space as follows. The areas are named: FLASH_RTOS_OBJ and RAM_RTOS_OBJ,

#define BOOTLOADER_PART0_ADDR	0x0000 	// First part goes from 0x0000 to 0x1000
#define BOOTLOADER_PART0_SIZE	0x1000 	// We can't go beyond 0x1000 because there are RTOS stuff in there

#define FLASH_RTOS_OBJ_ADDR		0x1000 	// RTOS stuff is stored from 0x1000 to 0x1700
#define FLASH_RTOS_OBJ_SIZE		0x700

#define BOOTLOADER_PART1_ADDR	0x1700	// Second part goes until page 7
#define BOOTLOADER_PART1_SIZE	(0x7000 - 0x1700)

#define APPLICATION_ADDR		0x7000	// Application goes from page 7 until page 31
#define APPLICATION_SIZE		(0x1F000 - 0x7000)

#define CCFG_ADDR				0x1F000	// CCFG is stored at the end of the last page (keyword HIGH used in SECTIONS)
#define CCFG_SIZE				0x1000

#define RAM_BASE                0x20000000
#define RAM_SIZE                0x5000

#define RAM_PART0_ADDR		0x20000000					// Fist part goes from 0x20000000 to 0x20000100
#define RAM_PART0_SIZE		(0x20000100 - 0x20000000) 	// We can't go beyond 0x20000100 because there are RTOS stuff in there

#define RAM_RTOS_OBJ_ADDR	0x20000100	// RTOS stuff is stored from 0x20000100 to 0x20000600
#define RAM_RTOS_OBJ_SIZE	(0x20000600 - 0x20000100)

#define RAM_PART1_ADDR		0x20000600 // Second part goes until the end of RAM
#define RAM_PART1_SIZE		((RAM_BASE + RAM_SIZE) - 0x20000600)

/* System memory map */

MEMORY
{
    BOOTLOADER_PART0 (RX) 	: origin = BOOTLOADER_PART0_ADDR, length = BOOTLOADER_PART0_SIZE
    FLASH_RTOS_OBJ (RW)		: origin = FLASH_RTOS_OBJ_ADDR, length = FLASH_RTOS_OBJ_SIZE
    BOOTLOADER_PART1 (RX)	: origin = BOOTLOADER_PART1_ADDR, length = BOOTLOADER_PART1_SIZE
    APPLICATION (RX)		: origin = APPLICATION_ADDR, length = APPLICATION_SIZE
    CCFG (RX)				: origin = CCFG_ADDR, length = CCFG_SIZE

    RAM_PART0 (RX)		: origin = RAM_PART0_ADDR, length = RAM_PART0_SIZE
    RAM_RTOS_OBJ (RWX)	: origin = RAM_RTOS_OBJ_ADDR, length = RAM_RTOS_OBJ_SIZE
    RAM_PART1 (RX)		: origin = RAM_PART1_ADDR, length = RAM_PART1_SIZE
}

3. I compiled the code and took a look in the memory usage. The linker is not using the "reserved" space.


4. I checked the TI-RTOS config, and it is as follows:

/* ================ ROM configuration ================ */
/*
 * To use BIOS in flash, comment out the code block below.
 */
 /*
var ROM = xdc.useModule('ti.sysbios.rom.ROM');
if (Program.cpu.deviceName.match(/CC26/)) {
    ROM.romName = ROM.CC2650;
}
else if (Program.cpu.deviceName.match(/CC13/)) {
    ROM.romName = ROM.CC1350;
}
*/

Please, let me know if there are any info that is missing to the understanding of the issue.

Right now I am not concerned about the jumps, I am only wanting to get everything in the correct position in the memory.

0 Alan DeMars over 9 years ago in reply to Mad River

TI__Mastermind 30830 points

That is correct except that the RAM_PART1_ADDR can be set to 0x20000204 and the math for computing RAM_RTOS_OBJ_SIZE should be (0x20000204 - 0x20000100)

Alan

Processors

Processors forum

RTOS/CC1310: Jumping between two applications in flash