• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 22 subscribers
  • Views 2570 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

const DATA at absolute address in CODE seg

John Penvenne

Hi all, My goal is to put a few constants in the code segment at compile time so they are stored in the program flash when the SiLabs 'F122 is initialized via JTAG.

const UCHAR code ucTBD = TBD_VAL;

seems to work but I'd like to put the data at a known address so I can read it explicitly with a MOVC-type flash read. But

const UCHAR code ucTBD _at_ 0x6000 = TBD_VAL;

is unacceptable because an absolute specifier is illegal.

Without the "_at_", the linker puts the data down with the ISR vectors but I need it to reside in flash space that I am comfortable modifying.

It seems to work if I declare ucTBD inside a function and assign an absolute location to that function. Is that an acceptable and reliable method?

Thanks in advance for any advice,
John

Ref:
typedef unsigned char UCHAR;
#define TBD_VAL (0x00)

  • 0 

    const UCHAR code ucTBD = TBD_VAL;
    "seems to work but I'd like to put the data at a known address so I can read it explicitly with a MOVC-type flash read."

    Why does it need to be at a fixed address to use a "MOVC-type flash read"?
    What is it about your "MOVC-type flash read" that only works with fixed, absolute addresses?
    Why can't your "MOVC-type flash read" use the symbolic name?

    The whole point of the code keyword extension is that you can just use it in 'C' like any other variable:
    UCHAR code ucTBD = TBD_VAL;

some_other_variable = ucTBD; // The compiler will generate a MOVC instruction here!

  • 0

    C51 doesn't let you use both _at_ and an initializer for the same variable. This feature is often requested on the board.

    You can use the initializer in the compiler, and then use the linker to place the variable where you want it. See the "Segment And Memory Location" section of the linker manual.

    You may need to declare the variables you want to manually locate in a separate C file to ensure that they get their very own segment name.

  • 0 in reply to Drew Davis

    Thank you both for your swift replies.

    The separate segment name was the ticket.

    There's a warning about "UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS" but the data are there right where the linker put them.

    To answer A.W. Neil's questions:
    1. MOVC A,@A+DPTR
    2. It doesn't need to be at a fixed address.
    3. I just want it to be where I'm comfortable erasing it, that is, at a known address above 0x0200.
    4. It can use a symbolic name but I want to reference it by address for bootloader reasons.

  • 0

    John;
    I use starup.a51 to set these code bytes.
    About one third down the page you will see CSEG 0.
    I set CSEG 0yyyh then
    DB byte1
    DB byte2
    etc.
    CSEG 0

    Not C but you can force any init bytes to any code address that is required,

  • 0 in reply to Bradford Al

    Al,
    That seems more direct. Thank you all for the fast and expert advice.
    John

  • 0 in reply to Drew Davis

    "This feature is often requested on the board."

    A common reason is for a version code - placed at a known location so that it can easily be found on a PROM programmer.

    However, I don't see anything in the original post that actually requires fixing at an absolute address.

    Perhaps John could explain?

  • 0 in reply to John Penvenne

    "3. I just want it to be where I'm comfortable erasing it, that is, at a known address above 0x0200.
    4. It can use a symbolic name but I want to reference it by address for bootloader reasons."

    Aha! You didn't mention a bootloader - you said you were loading via JTAG.

    So, surely, what you want is not to fix the location of this particular variable, but to prevent the Linker from placing anything below 0x2000 (or whatever).

    Note that the Linker will slot stuff into any gaps in the vector table if it can.
    The vector table is not sacrosanct - it's just another bit of CODE space as far as both the Linker and the processor are concerned.

  • 0 in reply to Bradford Al

    "Not C but..."

    Make them PUBLIC, and they are accessible from 'C'

  • 0 in reply to Andy Neil

    Good point Andy. Thanks for the reminder.
    Bradford