• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 21 subscribers
  • Views 874 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

Debugging C application using MetaICE XF for Dallas DS80C400

Richard Gilday

I wonder if anyone can help me out...

I wish to debug a C application using a MetaICE-XF
ICE for the Dallas DS80C400. The application has been compiled using the Keil compiler v7.2 in the uVision 2 environment. The memory model is Large: variables in XDATA and the Code Rom Size is Contiguous Mode (16MB program).

I have successfully convinced myself that I can set break points etc in the application but am unable to get a program view where C statements are interleaved with the underlying op codes. ie What I want to do is debug the C source code, not the assembler.

I understand that this is possible; in fact the Metalink h/w comes with examples using .AOM files. Unfortunately I've been unable to configure the Keil compiler to generate aom files (or dgb files) and would appreciate some pointers. Many thanks.

  • 0

    The output from the Keil linker is an Absolute Object Module. The file extension is blank. This is the standard defined by Intel a long time ago.

    Numerous other companies come up with their own extensions (AOM, OMF, BIN, and so on). It doesn't matter what they are called. They are Absolute OMF51 files--the same thing generated by the Keil linker. Metalink and Keil have worked together for a very long time so I KNOW that the Keil tools work well with the Metalink Emulators.

    The fact that you can load the program indicates that you're either loading the HEX file (in which case there IS NO source-level or symbolic information) or the absolute object file from the linker (in which case there is).

    The absolute OMF file does not actually contain your program source code. It only contains references to it that include the file name and the line number.

    The debugger (or emulator) has to take that information and interleave the assembler disassembly with the original source code. To do that, it needs to know where the source code is located and it needs to have access to it.

    1. Make sure you are using the correct file (the output from the linker and not the HEX file).

    • Check the emulator to figure out how to specify the folder where the source code is located. You MAY need to specify this.

    • Make sure that the machine the emulator is connected to can get to the source code. We once had a customer who copied his absolute OMF file to a floppy, carried it into the lab, loaded it into the emulator PC (which had no access to the original source code), and then called support complaining that our compiler didn't generate source-level debugging information.
      • That should pretty much do it. It may be worth a phone call to Metalink if these instructions don't help.


    Jon

  • 0 in reply to Jon Ward

    Hi Jon,

    Many thanks for your sound advice. I've just got feedback from Metalink and thankfully have solved the problem. We were successfully loading the Absolute Object Module (no file extension) but the emulator was unable to find the source. Had **thought** we'd told the emulator where to find the C source, but in the end got things working by placing the emulator config files in the same directory as the source. Not elegant, but functional :)

    ATB

    Richard