• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 226 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.

need help with RTA on OMAP3530

Chris Norris
Intellectual 935 points
Other Parts Discussed in Thread: OMAP3530

I'd really like to use the CPU load graph, statistics view, etc. for my OMAP3530 debugging, but I have been unable to figure out how to get them to update in real-time.  I tried the troubleshooting steps from http://wiki.omap.com/index.php?title=DSP/BIOS_Real-time_Analysis_%28RTA%29_troubleshooting under the category "RTA only works when the target CPU is halted".  I was hoping the key was to enable INT3, INT11, and INT12 but this didn't seem to affect anything.

I'm using an XDS560R JTAG emulator to load and debug a simple DSP/BIOS test app with 1 task.

Has anyone gotten RTA working in real time on OMAP3530?

Since I'm new to DSP/BIOS, I'm wondering how I know if RTDX is really working properly.  Would LOG_printf's update in real-time?  Currently, my LOG_printf's only show up if I hit a breakpoint.

Any insight is appreciated!

  • 0
    TI__Mastermind 41665 points

    Usually in this situation the problem is how the program is structured, since the RTA does actually use some target processor resources to function, your application's structure has an impact on the RTA performance, essentially #4 under the 'RTA only works when the target CPU is halted' from the wiki you mention is the most common RTA failure I see.

    Essentially once you exit main and enter the BIOS scheduler, you have to ensure that BIOS gets to run the idle task enough to give it the time it needs to handle the RTA tasks, if you have a task that never blocks, or enough tasks that block too rarely to prevent the idle task from executing, than RTA will only update when the CPU is halted since it never got the chance to update while it was running. Since the CPU load is calculated based on the amount of time spent on the idle task, if you are in this condition the CPU is always considered at 100% loading anyway so updating the graph would not mean much, however it also will prevent LOG_printfs from appearing until a halt/breakpoint.

    So you have to ask yourself:
    1. Is there a task that never blocks?
    2. Is the system busy enough to never run the idle task?