Problems with use of "volatile const" variables

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

Problems with use of "volatile const" variables

Jump to solution
6,026 Views
italiandoh
Contributor III
Hello to everyone,
we are working on a project based on a S12X microcontroller. Part of our application code is developed in Matlab/Simulink and then translated into C code using Targetlink from dSpace.
All calibratable parameters are declared in Targetlink as "CAL", which equals in C to the attributes "volatile const". When we used Cosmic as compiler, these CAL parameters were allocated into RAM memory, thus they were all calibratable using an external tool which access to the microcontroller memory in some ways (typically using CCP).
We recently moved to Codewarrior tools and now all CAL variables are allocated in ROM memory, so they are no more tunable. If we remove the "const" attributes of course everything is OK, but I would like to know if there is a way to have a variable with "volatile const" attributes allocated in RAM memory.
Does anyone has ever encountered this kind of issue ? Is there a solution for this ?
Thanks in advance for any help.
Best regards,

Matteo
Labels (1)
Tags (1)
0 Kudos
Reply
1 Solution
3,321 Views
CrasyCat
Specialist III
Hello
 
If you wish only some constants to be placed in RAM you need to define a constant segment to place all the volatile const variables and place it in RAM.
 
Lundin provided a good example on how to achieve that.
 
Note that there is an alternate solution to place a variable in a user defined section.
 
   - Define all your user defined section in a header file included in each module within the application
   - use the modified @"SectionNane" to place the variable in a user defined section.
 
Example
 
#pragma CONST_SEG MY_CONSTANTS
#pragma CONST_SEG DEFAULT

static const volatile int var=0 @"MY_CONSTANTS"; /* place in global namespace */

CrasyCat

View solution in original post

0 Kudos
Reply
6 Replies
3,321 Views
CrasyCat
Specialist III
Hello
 
When building with CodeWarrior all constants are allocated in a section called .rodata (or ROM_VAR).
Per default this section is allocated in Flash.
 
In order to place the constant in RAM:
  - Open your .prm file in the editor
  - In the PLACEMENT block move the section ROM_VAR and make sure it is allocated in RAM:
        DEFAULT_RAM,             /* all variables, the default RAM location */
        ROM_VAR                /* constant variables */
                        INTO  RAM;
     Make sure you remove the original occurrence of ROM VAR, which places it in Flash.
  - Save the changes
  - Rebuild.
 
CrasyCat
0 Kudos
Reply
3,321 Views
Lundin
Senior Contributor IV
I would rather reconcider the program design here, placing the default ROM variables in RAM is not only very risky, but also illogical. If you slip with one "#pragma CONST SEG", all your constants will end up in RAM suddenly.

I would rather reserve a separate "SECTION" for those tuning values in RAM, making sure it is exactly as large as all variables that will be stored inside it. If variables would accidently be assigned to be allocated in the same SECTION, there will be linker errors of missing memory space.

Or as an alternative, perhaps store the values temporary on the stack, then have the program writing them to for example eeprom, to preserve them.
0 Kudos
Reply
3,321 Views
italiandoh
Contributor III
Hello to everybody,
first of all thank you for your replies.
I saw the variables being put in .rodata section. I thought about moving this section to RAM, but I don't like the idea because this way everything "const" will be put into RAM, wasting a lot of RAM memory space.
I was hoping to find a better solution with a special attribute for the linker or something similar.
I'm actually surprised no one ever encountered this issue when using Codewarrior with automatic code generators like Targetlink. I don't know why "volatile const" is declared into RAM when using Cosmic and maybe other compilers and not with Codewarrior. These attributes are known to be used for this purpose, when the values are to be modified externally by something else than the application, so the compiler returns an error if the program attempts to write them.
If anyone else has another idea, please let me know, otherwise I will just remove the const attribute from the automatic code generator and that's it. I already contacted they support and I'm waiting for an answer from their S12X specialist.

Matteo

0 Kudos
Reply
3,321 Views
Lundin
Senior Contributor IV
.prm file:

SECTIONS

SOME_CONSTANTS = READ_ONLY 0x1000 TO 0x1010; /* RAM area */

END

PLACEMENT

MY_CONSTANTS INTO SOME_CONSTANTS;

END


.c file:

#pragma CONST_SEG MY_CONSTANTS

static const volatile int var=0; /* place in global namespace */

#pragma CONST_SEG DEFAULT
0 Kudos
Reply
3,322 Views
CrasyCat
Specialist III
Hello
 
If you wish only some constants to be placed in RAM you need to define a constant segment to place all the volatile const variables and place it in RAM.
 
Lundin provided a good example on how to achieve that.
 
Note that there is an alternate solution to place a variable in a user defined section.
 
   - Define all your user defined section in a header file included in each module within the application
   - use the modified @"SectionNane" to place the variable in a user defined section.
 
Example
 
#pragma CONST_SEG MY_CONSTANTS
#pragma CONST_SEG DEFAULT

static const volatile int var=0 @"MY_CONSTANTS"; /* place in global namespace */

CrasyCat
0 Kudos
Reply
3,321 Views
italiandoh
Contributor III
Hello everybody,
thank you for your help again. I managed to solve this issue by adding appropriate #pragma to every calibratable parameter declaration :

#pragma CONST_SEG CALIBRATIONS
#pragma CONST_SEG DEFAULT

CALIBRATIONS is put into RAM in the linker file. Targetlink allows this by automatically adding custom text for these pragmas to the C generated code. However the generated code is not portable anymore to other platforms or usable to simulate the application on a host PC, but this is not a Codewarrior issue.
Thanks,

Matteo
0 Kudos
Reply