• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 428 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.

General debugging questions on OMAP35x EVM

Weihua Sheng
Intellectual 600 points

Hello,

I am new to TI DSP development and after a few days' reading into (piling) documents about CE, DMAI, XDM, ... I started to understand more e.g. about the decode demo that came with DVSDK release :) I am planning to make some changes to the demo software to learn different packages/APIs, invoking more things on DSP and DSP/ARM comms, etc. I'd like to ask the forum some general questions regarding the debugging:

1. Most of time I insert printf for debugging purposes. I learnt that there's also a trace built-in for most TI tools though haven't used it so far. I looked up in the TI developers' wiki that remote debugging using GDB is possible - where can I find a pre-compiled gdb/gdbserver for omap evm3, if possible? or any instructions to cross-compile it?

2. from an early post in the forum, TI CCS is listed as (graphical) debugger for ARM+DSP. My understanding is that CCS is windows-only, right? I am currently doing everything on linux, including code-gen tools. Will CCS work on windows for OMAP code-gen as well? As a debugger only, how does the CCS work (I'm particularly interested in ARM+DSP multi-processsing simultaneously)?

3. This is a bit off the topic "debugging", I read the docs about programming DSP+ARM - in CE Application Developer's Guide 4.6, there're some lines about real-time issues of DSP. My understanding is that it is mainly programmer's job to ensure RT constraints - is it possible to have hard real-time constraints, e.g. a real-time clock or something to ensure peirodic tasks?

Sorry for many newbie questions. Thanks a lot!

 

 

  • 0
    TI__Mastermind 37340 points

    1. Porting, building, maintaining, gdb can be a big effort.  We will be providing gdb/gdbserver combo in the near future; if you could wait, in my opinion that would be best.

    2. although CCS is very good at DSP, and understands ARM, it does not understand Linux; therefore, if you want to debug both sides simultaneously, this may be a challenge.  CCS is typically the tool of choice for DSP side, but for ARM/Linux side, the tool of choice is typically an IDE running on top of gdb (e.g. open source DDD, commercial DevRcoket...)

    3. I have not read this document entirely but I imagine that challenge would be synching up a real-time OS (DSP/BIOS) with what many consider not to be a real-time OS (Linux).  You canuse real-time clock to ensure periodic tasks.

  • 0
    TI__Mastermind 41665 points

    1. Eventually the SDK filesystem should include this, you could compile it yourself, but for now the easiest way would be to use the one from the Code Sourcery toolchain, you should find a gdbserver within arm-2007q3\arm-none-linux-gnueabi\libc\usr\bin if you have installed the Code Sourcery tools.

    2. CCS is currently only for windows and is no good for debugging Linux applications as it is not Linux aware. If you are looking for simultaneous debug of ARM and DSP than the Green Hills Multi IDE tool may be useful, though I am not sure if it fully supports OMAP3 yet, you would want to contact Green Hills for details.

    3. You can have periodic events on the DSP fairly easily with DSP/BIOS (PRD functions), however if your code is not completing what it needs to in time than a periodic event is not going to help, so in the end it really is up to the programmer to ensure that the code executes in the time given. DSP/BIOS tends to be tailored to real time applications, and has a hard task prioritization system with no time slicing to meet that goal, so it helps as much as it can to be real time.

  • 0 in reply to Bernie Thompson TI
    Intellectual 600 points

    Thanks for the pointers, Juan & Bernie. I found the gdbserver in the code sourcery toolchain and now uses the ddd to debug the app on EVM from the host PC remotely. It works well for now, and I will see how it goes on when I need more debug info e.g. from the DSP side, maybe some mini-debugger codes in the ARM app fetching the data from DSP would help.

    BTW, I have a question regarding the OS of the development host PC, does any of the TI/OMAP dev tool chains require a 32-bit Linux? Would a 64-bit RHEL-linux (e.g. Scientific Linux) work fine?

    Thanks!

     

     

  • 0 in reply to Weihua Sheng
    TI__Mastermind 37340 points

    Most people use 32-bit Linux distros. 

    I do not know anyone who has installed this on a 64-bit version of Linux; although it would be interesting to see if the installer even allows this.  Based on past experience, the TI installer is not as picky, but if you decide to buy the MontaVista distro (coming soon), their installers tend to be more picky.

    In conclusion, I would recommend that you use 32-bit versions of the OS.  Most of us use RHEL 4 (no longer available) and hence RHEL 5 would be the next best OS I would recommend; at least this way you will know that plenty of people are using (and testing) your host OS and problems will be minimal.  Sure you can probably use the software with other Host OSes, but if you go with RHEL 5, at least you know you will not be alone in your journey. :)