problem implementing ULP5.1

moshe jacobson18

Hi anyone...

i'm trying to implement ulp5.1 recommendation of moving my divide functions from flash into ram....

I've followed TI's example and the code does get put into ram as per the map file, but when viewed in the debugger dissassembly i see a whole lot of duplicated nonsense code (almost like default memory values) so naturally once the PC is set to the function it never returns!

MSP430F3736, CCS 6.1.2.00015, compiler tools 4.4.7, c/c++ dev tools 8.5.0.201409172108

MEMORY
{
SFR : origin = 0x0000, length = 0x0010
PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
RAM_EXECUTE : origin = 0x1C00, length = 0x0100
RAM : origin = 0x1D00, length = 0x1F00
INFOA : origin = 0x1980, length = 0x0080
INFOB : origin = 0x1900, length = 0x0080

INFOC : origin = 0x1880, length = 0x0080
INFOD : origin = 0x1800, length = 0x0080

FLASH_EXECUTE : origin = 0x4000, length = 0x0100 /
FLASH : origin = 0x4100, length = 0xBE80
FLASH2 : origin = 0x10000,length = 0x14000
INT00 : origin = 0xFF80, length = 0x0002
..etc
..etc
}

SECTIONS
{
.bss : {} > RAM /* Global & static vars */
.data : {} > RAM /* Global & static vars */
.TI.noinit : {} > RAM /* For #pragma noinit */
.sysmem : {} > RAM /* Dynamic memory allocation area */
.stack : {} > RAM (HIGH) /* Software system stack */

.run_from_ram : load = FLASH_EXECUTE, run = RAM_EXECUTE

#ifndef __LARGE_DATA_MODEL__
.text : {}>> FLASH /* Code */
#else
.text : {}>> FLASH2 | FLASH
..etc
..etc
}

#pragma CODE_SECTION(DivByInt32,".run_from_ram")
int32_t DivByInt32(int32_t valToDivide,int32_t divisor)
{
return(valToDivide/divisor);
}
#pragma CODE_SECTION(DivByInt16,".run_from_ram")
int32_t DivByInt16(int32_t valToDivide,int16_t divisor)
{
return(valToDivide/divisor);
}

thanks

over 9 years ago

0 Chester Gillon over 9 years ago

Guru 92251 points

moshe jacobson18 said:
I've followed TI's example and the code does get put into ram as per the map file, but when viewed in the debugger dissassembly i see a whole lot of duplicated nonsense code (almost like default memory values) so naturally once the PC is set to the function it never returns!

Your program needs to copy the code section from flash to RAM before calling the RAM functions. I can't see any copy in your posted code which could explain the diassassembly in RAM is nonsense code.

0 moshe jacobson18 over 9 years ago in reply to Chester Gillon

Expert 2220 points

dear oh dear....big ooops....i didnt look far enough down the example code to see that line!!

chester, thanks for pointing it out.!

0 Alexey Bagaev over 9 years ago

Genius 5505 points

You'd better consider to switch to CCS 6.1.3, because full code copy and execution from ram feature is supported on its new compiler only.

0 moshe jacobson18 over 9 years ago in reply to Alexey Bagaev

Expert 2220 points

Hi Alexy
thanks for that...i'm busy downloading now.
But, i looked on the site and didnt see anything about that feature in the release notes...do they specifically mention this issue somewhere else?

0 Alexey Bagaev over 9 years ago in reply to moshe jacobson18

Genius 5505 points

moshe jacobson18 said:
do they specifically mention this issue somewhere else?

"This feature is available in ARM, C2000, and MSP430 compiler versions 15.6 and above". CCS v.6.1.3 uses compiler v.15.12.x.

0 moshe jacobson18 over 9 years ago in reply to Alexey Bagaev

Expert 2220 points

heck...that means its been available for quite some time or has there been a jump in the numbering??

0 Chester Gillon over 9 years ago in reply to moshe jacobson18

Guru 92251 points

moshe jacobson18 said:
heck...that means its been available for quite some time or has there been a jump in the numbering??

There has been a change in the numbering. The first number is now the last two digits of the year. See http://processors.wiki.ti.com/index.php/Compiler_Version_Numbers_and_What_They_Mean

0 moshe jacobson18 over 9 years ago in reply to Chester Gillon

Expert 2220 points

thanks chester!
so that tells me this 'ramfunc' change was inserted in the msp430 compiler ver 15.6 which as per the website link you gave indicates that it has been around since june last year....now i found that very interesting and a new question arises which is how come that version wasn't installed even with ccs v6.1.1 which was released around sept last year?

0 Chester Gillon over 9 years ago in reply to moshe jacobson18

Guru 92251 points

moshe jacobson18 said:
now i found that very interesting and a new question arises which is how come that version wasn't installed even with ccs v6.1.1 which was released around sept last year?

The way CCS handles updates for compilers is that updates will only be found for minor updates to compilers which are already installed. To get a new major compiler you either have to use Help -> Install New Software or the CCS App Center. See Compiler Updates for details.

0 moshe jacobson18 over 9 years ago in reply to Chester Gillon

Expert 2220 points

thanks..thats a nice tip!

0 moshe jacobson18 over 9 years ago in reply to moshe jacobson18

Expert 2220 points

hi chester/alexey
now that i have downloaded ccs 6.1.3.00013 with MSP430 compiler 15.12.2 i have tried to implement the execute from ram feature

if i do the following....this does work fine
In the source...
#pragma CODE_SECTION(TheFunction,".run_from_ram")
int TheFunction(int x,int y) {
return(x/y);
}

and in the main function... memcpy((void*)0x1C00,(const void*)0x4000,0x0100);

and in the link...
MEMORY {
RAM_EXECUTE : origin = 0x1C00, length = 0x0100
FLASH_EXECUTE : origin = 0x4000, length = 0x0100
..
}
SECTIONS {
..
.run_from_ram : load = FLASH_EXECUTE, run = RAM_EXECUTE
..
}

the program loads and runs perfectly!

BUT IF I DO THIS...
In the source...
__attribute__((ramfunc))
int TheFunction(int x,int y) {
return(x/y);
}

in the link...
SECTIONS {
..
.TI.ramfunc : {} load=FLASH, run = RAM, table(BINIT)
..
}

i get the following LOAD error

MSP430: File Loader: Verification failed: Values at address 0x00000 do not match Please verify target memory and memory map.
MSP430: GEL: File: C:\\ti\projects\workspace_v6_1\Front\Debug\Front.out: a data verification error occurred, file load failed.

when it tries to load the program into the chip.

it seems to me that i'm missing a step/setting somewhere....

UPDATE....

I added the following line in the SECTIONS part of the link file.. .binit : {} > RAM

and THAT seems to work as the binit section is now at 00001f42 instead of 00000000
but i must confess that i dont see why i needed to add it in...
i'm also not sure if that is what i was supposed to do (i would have thought a definition of BINIT in the memory part would have been required rather than the SECTIONS part) !!

0 Chester Gillon over 9 years ago in reply to moshe jacobson18

Guru 92251 points

moshe jacobson18 said:
I added the following line in the SECTIONS part of the link file.. .binit : {} > RAM

Without a SECTIONS specification for the .binit section you should have got the following warning:

warning #10247-D: creating output section ".binit" without a SECTIONS specification

What this warning means is that the linker hasn't been told which memory region to place the .binit section in, and so the linker choses an arbitrary memory region. The result is that the program will probably fail. In your case the linker chose to place the .binit section in the peripherals region which caused a program download to fail. You therefore shouldn't ignore the warning #10247-D.

[I did once suggest this should be an error rather than warning - see Should linker warning #10247-D really be an error]

moshe jacobson18 said:
and THAT seems to work as the binit section is now at 00001f42 instead of 00000000

The .binit section is read by the C run time library startup code to determine how to copy the functions from flash to RAM. Therefore, while placing the .binit section in RAM will work when you download the program using the CCS debugger, the program won't startup from a power up. The .binit section should therefore be in FLASH.

[I confirmed this using the TI ARM compiler v15.12.2 for a Hercules Cortex-R5 device but equally applies to MSP430 devices]

0 moshe jacobson18 over 9 years ago in reply to Chester Gillon

Expert 2220 points

yes i did see that warning which made me think to create the .binit section, and i thought it didnt need the flash address as it had already been generated and just needed to know where to copy it to....the fact that a warning was generated didnt fuss me too much as i thought it was 'just another incomplete enhancement'!

So, THANK YOU for saving me some frustration in the future!!

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

problem implementing ULP5.1