• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 679 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Difficulty Debugging with Processor SDK RTOS AM335x V2.00.02.11

Victor Wheeler61
Expert 2215 points

Hello!

I'm developing on a Windows 7 64-bit platform, CCS Version: 6.1.2.00015, and have recently installed Processor SDK RTOS AM335x v2.00.02.11, and SYS/BIOS 6.45.01.29  (installs with the PDK) released just about a week ago or so, and I am using XDCtools 3.32.00.06.

I have uncovered a problem that technically should not be there:  in walking the debugger through pre-main initialization steps being conducted by the RTOS (to find out why I am getting an exception), I have discovered that the in some parts of the RTOS code, I can step through the code (e.g. Timer.c), and others report "Can't find source file at '/db/rtree/library/trees/xdcprod/xdcprod-t67/product/xdccore/Linux/xdctools_3_30_06_67_core/packages/xdc/runtime/Error.c".  This is happening with (at least -- that I know of) Startup.c and Error.c, and probably others in the XDCtools runtime library that I have not run into yet.  When I CAN step through the code (e.g. Timer.c), it works great.   I realized, for example, that I could copy the Startup.c file into my project and THEN I could step through the code there.  I'm sure this will work with Error.c as well.  However, it also occurs to me that I cannot debug with these files because the debug information as regards LOCATION OF THE SOURCE FILE is incorrect, and I BELIEVE the cause of this (though I could be wrong) is that the Startup.c and Error.c BINARYIES (.O files) that are in the XTCtools runtime library that SYS/BIOS applications normally link into -- HAVE NOT been re-compiled so as to embed the correct SOURCE FILE LOCATION for debugging!

Can this please be corrected so it works nicely to debug through the XDCtools runtime library source code?  (Doing so gives me a GREAT deal of better understanding about how these bits work, and therefore good reason to trust them more -- to me, this is essential.)

Kind regards,
Vic

  • 0
    TI__Genius 12025 points

    Victor,

    You are correct in your analysis. The xdc.runtime modules have been built with a file system path which is different from your installation path. This causes the debugger to complain. The Timer source file works because it is part of SYS/BIOS which is rebuilt implicitly by your CCS project. However, the xdc.runtime source files are not rebuilt with your project.

    But there is help. CCS has a feature called "Source Lookup Path" which allows you to specify the current location of the files. (This may actually be an Eclipse feature, I'm not sure.) Open this dialog and create a path map instance.

    Window > Preferences
    C/C++ > Debug > Source Lookup Path
    Add...
    Path Mapping > Select
    OK

    Name: TI Products

    The compilation path should be set to the initial part of the file system path used to build the xdc.runtime sources. You see this path in the debugger error message. The local file system path is your installation location. You need to specify just the parts which are different. In other words, CCS will replace the compilation path you specify with the local path you specify to create the actual physical path to the source file. Let's say you installed XDCtools in C:\TI folder.

    Compilation Path: /db/rtree/library/trees/xdcprod/xdcprod-t67/product/xdccore/Linux
    Local Path: C:\TI

    The common part of the file system path is the same for both, so you omit this part.

    xdctools_3_30_06_67_core/packages/xdc/runtime/Error.c

    Click the Add button, then paste the compilation path above into the textbox. Click in the corresponding textbox for the local path and click the browse button. Navigate to your install folder. OK the dialog and the preference dialog.

    Reload and run your program again. (Unfortunately, the change does not take effect until you run again.) This time, the debugger should find the source file. However, the library was probably built with optimization, so you will not be able to perform source level stepping. You can do assembly level stepping (use the Disassembly window) and the source code will follow as best it can. Setting breakpoints at function entry should work, but you cannot set breakpoints on line numbers.

    ~Ramsey

  • 0 in reply to Ramsey
    Expert 2215 points
    Hi, Ramsey!

    Again, allow me to thank you for such a quick turn-around on my query!

    As an IDE feature -- that path re-mapping thing is BRILLIANT! It works.

    Minor correction, however: since I am using XDCtools 3.32.00.06, THAT part of the path doesn't match, so I made an adjustment, and it is working as intended (note, CCS re-mapped the forward slash directory separators to back-slashes):

    Compilation Path:
    \db\rtree\library\trees\xdcprod\xdcprod-t67\product\xdccore\Linux\xdctools_3_30_06_67_core
    Local Path:
    C:\ti\xdctools_3_32_00_06_core

    And I changed the name of the "remapping" record to: XDCtools_path.

    Many thanks! I feel well supported. :-)

    Kind regards,
    Vic