• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 22 subscribers
  • Views 1722 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

DPP error with variables initialized at compile time

Mikael Briday

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

  • 0 in reply to Mikael Briday

    Hi,

    I have got the same problem, have you found any solution or walk around? I checked all memory models and disabled code optimization, but the varaiable always points to the wrong memory...

    Thanks for any advice

    Uwe

  • 0 in reply to Uwe Brecht

    No, I did not found any viable solution.
    The work around I use is to to set the memory chunk at another address. With the new configuration, there is no error...
    but It's not a solution for a production code.

  • 0

    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

  • 0 in reply to Jo Leeuwesteijn

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

    There is only a small part of my program which is machine dependant, in another file. The code for tpl_task and the code presented is ANSI C (compiled with Gcc with the most restricitive options, and with Keil for the C166 target obviously.)

    * How did you 'look' at the pointer?
    I use the uVision 3 debugger to 'look' at the pointer value. The code is executed on the target, with a monitor.

    * 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.
    This is a pointer to a structure (tpl_task). I use it to access memory relative to this pointer.. but sorry, I don't understand what you mean :-/

    Are you using any other DPP related compiler/linker directives
    I do not use any specific options for the DPP.

    regards,
    M. Briday