• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1144 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.

OMAP35x: Reading LOG_printf traces and displaying through serial console

RH44284
Prodigy 240 points
Other Parts Discussed in Thread: OMAP3530

Hello,

I am working with OMAP3530 (Using DSP/BIOS5 and DSPLINK_1_65). In my DSP application, I am using a LOG object called "trace" to print occasional debugging information. I was looking at the wiki page:

http://processors.wiki.ti.com/index.php/Accessing_DSP_BIOS_logs_without_JTAG

It seems like the sample pseudo code at the end of the page is attempting to retrieve the traces through DSP application and then print using standard printf. However, I would like to retrieve traces from my ARM side application. I am trying to avoid doing CIO in the DSP application unless absolutely necessary. I have read in another post that LOG_printf prints either using RTDX or using serial console if connected? The link to the post is available below:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/35455/251003.aspx

 

I posted my problem at the end of that forum but have not received any response yet. I am not sure if the DSP would send the LOG_printf traces to serial console by default (in the absence of RTDX)

I looked up the map file for the application to get the physical address for the trace buffer (trace$buf) which is my case is 0x87e18000. This is in the DSP code memory and has been declared as shared access memory in my config file CFG_OMAP3530_SHMEM.c

So, on the ARM side, I should I do a PROC_read to read from that address? Because the address of (trace$buf) is a physical address and PROC_read can use physical address on the ARM side.  Any help on how to do this in the program or through configuration will be very helpful. Thank you in advance. 

 

Regards,

RH

  • 0
    TI__Expert 4095 points

    If you have a JTAG connection to the DSP, you should be able to connect to the DSP in CCS and use 'load symbols' to tell CCS about the .out file you have running on the DSP. After that, you should be able to open ROV and RTA.

    Regarding the error you mentioned (in the other post) with opening ROV --you can find the path settings under Window -> Preferences... -> CCS -> RTSC. Select an "XDCtools version" from the drop down, and under "Products and Repositories" ensure that BIOS 5 is checked. Re-open ROV and it should work.

    What version of BIOS 5 and CCSv4 are you using? If your DSP application is configured for RTA and RTDX, you should be seeing the records in RTA in CCS.

    Thanks,

    Chris

  • 0 in reply to Chris McCormick
    Prodigy 240 points

    Hello Chris,

    Thanks for the tips. I will try them and update you by tomorrow. Meanwhile, can you give me some hints on how to obtain traces from ARM code? I am following the tips from the wiki page but I am not able to read the trace buffer since I only know the physical address of the trace buffer. Thank you in advance

     

    Regards,

    RH

  • 0 in reply to RH44284
    TI__Expert 4095 points

    Do you have a JTAG connection to the DSP? If you do, you can get the LOG statements from the DSP directly over RTDX without having to route the data through the Arm.

    If you don't have a JTAG connection, there's no formal supported way for getting this data off the target yourself and decoding it. If you're brave enough, though, that wiki article can help you attempt to do the decoding yourself.

    Thanks,

    Chris

  • 0 in reply to Chris McCormick
    Prodigy 240 points

    Hello Chris,

     

    I just tried out everything that you suggested and here are the results (Using CCS 4.1.3.00038 and BIOS 5.41.02.14):

    -I can open ROV without any problem

    -I can see the LOG_system and trace object, but no real-time logs when DSP core is running

    -When I halt DSP core, I see "Acquiring Data" and then some LOG_system messages but no user-defined trace logs

    -Then I run the application for the second time from ARM, load symbols from CCS, and basically repeat the steps above. I am finally able to see the logs.

    I am unsure of two things:

    1. Why RTDX is not working. RTA seems to be working.

    2. Why I do not see the log the first time I run a application. I need to run the application twice to retrieve the logs.

     

    Here are the things that I have checked:

    1. RTDX and RTA and allTraces are enabled in the tcf file

    2. I have allocated 4096 bytes for the trace buffer

    3. I am returning from main

    4. I am waiting on the ARM side (literally doing a getchar, since I don't know how long to wait ) so that the DSP has idle time and is not reset by the ARM (in my application, like other sample DSPLINK applications,  I power down the DSP at the end of the application)

    5. In the IER register, IE11 and IE12 are enabled. For some reason, I cannot see IE3.

    I was following the trouble-shooting steps for C64x+ on the wiki page:

    http://processors.wiki.ti.com/index.php/DSP/BIOS_Real-time_Analysis_%28RTA%29_troubleshooting

     

    I am wondering what else to try out. Please let me know your suggestions. Thank you very much in advance.

    Regards,

    RH

     

  • 0 in reply to RH44284
    TI__Expert 4095 points

    RH said:

    (Using CCS 4.1.3.00038 and BIOS 5.41.02.14):

    If you move to BIOS 5.41.04, you can use stop mode RTA to view the records in RTA when the target is halted. See this article:

    http://processors.wiki.ti.com/index.php/BIOS_5_Real-Time_Analysis_%28RTA%29_in_CCSv4

     

    RH said:

    -I can see the LOG_system and trace object, but no real-time logs when DSP core is running

    ROV will only update when the target is halted, it doesn't show real-time data.

     

    RH said:

    -When I halt DSP core, I see "Acquiring Data" and then some LOG_system messages but no user-defined trace logs

    To support RTA, there is an idle function which is removing the records from their buffers and sending them to the host over RTDX. It is possible that the trace log is empty because all of the current trace records have already been sent up.

     

    RH said:

    -Then I run the application for the second time from ARM, load symbols from CCS, and basically repeat the steps above. I am finally able to see the logs.

    What are you doing the first time? Are you loading the DSP through CCS, or through the ARM?

    When you say that you finally see the logs, do you mean that you see them in the RTA views? Or are you just referring to the trace logs appearing in ROV?

     

    RH said:

    I am unsure of two things:

    1. Why RTDX is not working. RTA seems to be working.

    Are you seeing any records in the Tools -> RTA -> Raw Logs view? If you are, then RTDX is at least partially working. If not, then it may be that RTDX doesn't work when you do a load symbols versus loading the program through CCS.

     

    Thanks,

    Chris

  • 0 in reply to Chris McCormick
    Prodigy 240 points

    Hello Chris,

     

    Thank you for to-the-point explanations, tips and answers. Both RTA, RTDX  and ROV are working with load symbols. I am now downloading the BIOS 5 version you mentioned to test the stop-mode feature. Thank you once again for very complete answers.

     

    Regards,

    RH