• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 21 subscribers
  • Views 1772 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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

Nohau ICE & var's in external RAM & watch window

Dave S.

I can't seem to figure out how to put variables declared via KEIL's
absolute memory access macros (#include <absacc.h>) such as:

#define myVariable HVAR(unsigned int, 0x100000)

into my Nohau (EMUL166PC) ICE's watch window. Can anyone tell me
what I need to do to make this work?

Any help would be greatly appreciated... thanks,
Dave.

Parents
  • 0 in reply to Dave S.

    After spending many 1000's of $ for what's supposed to be a good ICE, what a letdown!

    Whoa! This is not a Nohau or Keil problem (well maybe Keil's in some way, they could've added _at_), it is simply the C language. There is no reason for a #define to ever be placed into the symbol file, I don't know if any tools place the #define name portion into a symbol file. Since the symbol does not really exists (the pre-processor strips it out) the compiler, linker, and debugger simply cannot know about the name you chose to call 0x100000.

    The correct answer is a the properly typed pointer to the location 0x100000. Nohau should let you watch the pointer and what it points to.

    - Mark

Reply
  • 0 in reply to Dave S.

    After spending many 1000's of $ for what's supposed to be a good ICE, what a letdown!

    Whoa! This is not a Nohau or Keil problem (well maybe Keil's in some way, they could've added _at_), it is simply the C language. There is no reason for a #define to ever be placed into the symbol file, I don't know if any tools place the #define name portion into a symbol file. Since the symbol does not really exists (the pre-processor strips it out) the compiler, linker, and debugger simply cannot know about the name you chose to call 0x100000.

    The correct answer is a the properly typed pointer to the location 0x100000. Nohau should let you watch the pointer and what it points to.

    - Mark

Children
  • 0 in reply to Mark Odell

    After spending many 1000's of $ for what's supposed to be a good ICE, what a letdown!<br>
    <br>
    Whoa! This is not a Nohau or Keil problem (well maybe Keil's in some way, they could've added _at_), it is simply the C language. There is no reason for a #define to ever be placed into the symbol file, I don't know if any tools place the #define name portion into a symbol file. Since the symbol does not really exists (the pre-processor strips it out) the compiler, linker, and debugger simply cannot know about the name you chose to call 0x100000.<br>
    <br>
    The correct answer is a the properly typed pointer to the location 0x100000. Nohau should let you watch the pointer and what it points to.<br>
    <br>
    - Mark<br>

  • 0 in reply to Dave S.

    The correct answer is a the properly typed pointer to the location 0x100000. Nohau should let you watch the pointer and what it points to.

    It doesn't? That doesn't sound right. My Signum Systems' USP-51 does. If it's a struct pointer it shows you the struct format too. Sorry to hear that about Nohau, haven't used them in a while.

    BTW, see "Tips for posting" (left) to see the limited HTML tags this forum supports, no <br>'s I'm afraid.

    Regards,

    - Mark