This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Nuvoton ARM Cortex-M0. How to put a const char string into ROM region?

Hi,

I can not get through with ROM-based constants.

When I put a definition:

const char txtParcer_OK[] = "ok! this is sample message ...";

the compiler resides the message in RAM area. I need ROM area.

I use µVision V4.20.03.0
Tool Version Numbers:
Toolchain: MDK-ARM Standard Version: 4.20
Toolchain Path: BIN40\
C Compiler: Armcc.Exe V4.1.0.644
Assembler: Armasm.Exe V4.1.0.644
Linker/Locator: ArmLink.Exe V4.1.0.644
Librarian: ArmAr.Exe V4.1.0.644
Hex Converter: FromElf.Exe V4.1.0.644
CPU DLL: SARMCM3.DLL V4.20
Dialog DLL: DARMCM1.DLL V1.7.0.0
Target DLL: Bin\Nu_Link.dll V1.18
Dialog DLL: TARMCM1.DLL V1.06

Best regards,
Alex.

Parents
  • Hi Dejan,

    Am I sure? I look into .map file. It says, that all my consts ar placed in 0x20000.... area. RAM data. The only way to place it to ROM area is to give directive __attribute ((( etc.

    Word code , or static , or ROM, or any one specific word does not work.

    Plus, main problem is, that I can not add more constants now. The program fails to work. As I comment a block of constants - it works again properly.

    So, I think, I am sure. I have tried all the ways I know to place the constant to where it must be - so far all in vain.

    Alex.

Reply
  • Hi Dejan,

    Am I sure? I look into .map file. It says, that all my consts ar placed in 0x20000.... area. RAM data. The only way to place it to ROM area is to give directive __attribute ((( etc.

    Word code , or static , or ROM, or any one specific word does not work.

    Plus, main problem is, that I can not add more constants now. The program fails to work. As I comment a block of constants - it works again properly.

    So, I think, I am sure. I have tried all the ways I know to place the constant to where it must be - so far all in vain.

    Alex.

Children
  • Impossible, in my code it works with "const char". But I use CPP compiler. But anyway should be no problem.

    If I define const char acText[]= "Hallo"; , and then look at the variable acText in the watch window, it is defined at address 0x08006678, which is clearly a code address (uVision 4.60 - ARMCC 5.0 - STM32F4).

  • PS: Perhaps you have some very strange project settings. Best try it first in some fresh Blinky example directly from the Keil boards folder.

  • Thanks! I will try. As for the project settings - it is a copy of Nuvoton's sample projects' ones. I just have copied all the settings, one by one, and whole project file.

    I am also very surprised, and think, that there is some small error somewhere in my files,
    so it worth to try new project. Just one string.

    Alex.

  • Thank you b t.

    I have made the project up again from the very ground, and, by means of one-by-one .h files exclusion, found a definition in old&borrowed (Microchip C32) file:

    #define  const
    

    So, when I comment it, everything works as it must.

    Thank you folks. Thank you all. Best regards!
    Alex.

  • Strange that the compiler does not give a warning in such a case. It would be generally nice, if the compiler would produce some more warnings .... (empty code, ambiguous operator order).

  • Not at all!

    #define  const
    

    It just means that the 'const' keyword was effectively stripped from the source code by the preprocessor.
    Since 'const' was purely optional in all the cases tried, there was nothing to warn about!

    eg,

    const char acText[]= "Hallo";
    


    just becomes

    char acText[]= "Hallo";
    


    and

    static const acText[]= "...";
    


    just becomes

    static acText[]= "...";
    


    and

    const char txtParcer_OK[] = "ok! this is sample message ...";
    


    just becomes

    char txtParcer_OK[] = "ok! this is sample message ...";
    

    BTW: There is nothing in the 'C' language definition that requires the compiler to put const items into read-only memory...

  • Yes. Stupid error, but that is it.

    Thank you for the advice.

    Alex.