DPP error with variables initialized at compile time

Hi,

I have a program with manystructures that are statically allocated at compile time, and there is a problem with DPPs.

The memory configuration is:
ROM 0x0 -> 0x3FFF
RAM 0x4000 -> 0x7FFF

DPP1 points to NCONST and is correctly set to 0
DPP2 points to NDATA and is correctly set to 1

I have a structure (structA) that is set in RAM, its address is 0x544A

I set a second structure (structB), which is initialized at compile time:

tpl_alarm structB = {
....
    /* kind of the alarm    */  ALARM_TASK_ACTIVATION,
                                {
    /* action of the alarm  */      {
                                        (tpl_task *)&structA
                                    },
    /* event if necessary   */      (tpl_event_mask)0
                                },
 .....
};

When I look at structB, I can found that the value of the pointer is 0x544A!!!
But structA resides in the NDATA memory, and MUST use DPP2!!!
I expected the value 0x944A to use DPP2!!

(tpl_task *) is the correct type of structA.

Thanks for any help,
M.Briday

Parents
  • Random thoughts:

    * Are there any specific near/far keywords in the 'tpl_task' definition (or 'below' that) that might have messed things up?

    * How did you 'look' at the pointer? I can imagine that the pointer (printf'ed or looked at in a debugger) still contains 0x544A but 0x944A is only used in the assembly instructions when actually accessing the data.

    * I can imagine the compiler/linker simply can't store a pointer of 0x944A because at runtime you might access memory relative to this (DPP-using) pointer but crossing DPP page boundaries.

    * Did you use the NOFIXDPP linker directive?
    http://www.keil.com/support/man/docs/c166/c166_nofixdpp.htm

    * Are you using any other DPP related compiler/linker directives?

    Regards,
    Joost Leeuwesteijn

Reply
  • Random thoughts:

    * Are there any specific near/far keywords in the 'tpl_task' definition (or 'below' that) that might have messed things up?

    * How did you 'look' at the pointer? I can imagine that the pointer (printf'ed or looked at in a debugger) still contains 0x544A but 0x944A is only used in the assembly instructions when actually accessing the data.

    * I can imagine the compiler/linker simply can't store a pointer of 0x944A because at runtime you might access memory relative to this (DPP-using) pointer but crossing DPP page boundaries.

    * Did you use the NOFIXDPP linker directive?
    http://www.keil.com/support/man/docs/c166/c166_nofixdpp.htm

    * Are you using any other DPP related compiler/linker directives?

    Regards,
    Joost Leeuwesteijn

Children
More questions in this forum