Debugging the DSP side of SysLink on OMAP3530

Hi Valdez,

I'd have expected that CCS would be able to connect to the DSP after running slaveloader. Which version of SysLink are you using? Have you tried to do this with one of the out-of-box examples shipped in SysLink?

Best regards,

Vincent

Hi Vincent,

I use the last SysLink release 2.21.01.05. And I try with ex01_helloworld example. Slaveloader works correctly.

I use it on VirtualBox machine, with Ubuntu 12.10 host and Ubuntu 12.04 guest. My emulator is XDS100v2. That error message looks like some problem with FTDI communication, but why...

Hi Valdez,

I ran slaveloader to load the ex01_helloworld example from SysLink 2.21.01.05 onto the DSP on my Beagleboard and was able to connect to the DSP just fine. I simply had to launch the CCS configuration, right-click on the DSP core under the Debug tab and select 'Connect Target'. I am using a Windows XP box, CCS 5.1 and a BlackHawk XDS560-M emulator. I'd suggest you double-check your emulation setup.

Best regards,

Vincent

Hi Vincent,

I can test it again tomorrow.

But today I have extra question:) I had big problem to find correct kernel and rootfs for ARM side on Beagleboard, where SysLink works correct. Could you share the information about it, how do you prepare OS for that Cortex? Which software do you use?

Regards,

Valdez

Hi Valdez,

For questions regarding which OS distribution to use for the Beagleboard I'd suggest you refer to the latest information available on http://beagleboard.org. The community there should be able to assist you.

Best regards,

Vincent

Sure, I use that site. Couple of weeks ago I was looking for kernel that can be used with SysLink, is available to download and supports Beagleboard. I had found only one, from PSP 04.02.00.07. I wonder what TI people are using, if it is not a secret :)

EDIT: That info is very important for me. I have feeling that my current ARM side system configuration is not well e.g. I have network troubles, some modules fails. Would like to use something recommended, so really ask for share that info.

Hi Valdez,

We got our kernel from kernel.org (kernel) and http://www.angstrom-distribution.org/builder/ (file system). It's better if you use the recommended versions from beagleboard.org, as we expect SysLink to be compatible.

FWIW, we have people on Linux 3.3 and newer using SysLink 2.x, so do let us know if you are having specific issues with SysLink on a given kernel. I'd suggest you work with Beagleboard.org to get a working baseline going before attempting to run any SysLink program.

Best regards,

Vincent

Hi Vincent,

the most problematic thing for me with kernel and SysLink was with IOMMU IVA2. I get error when trying to load SysLink module, e.g. with 2.6.37.6 kernel from kernel.org:

root@beagleboard:~# insmod /lib/modules/2.6.37.6/kernel/drivers/dsp/syslink.ko TRACE=1 TRACEFAILURE=1
[  241.302856] syslink: Unknown symbol iopgtable_lookup_entry (err 0)
[  241.310241] syslink: Unknown symbol iopgtable_clear_entry (err 0)
[  241.319244] syslink: Unknown symbol iommu_put (err 0)
[  241.325897] syslink: Unknown symbol iopgtable_store_entry (err 0)
[  241.333801] syslink: Unknown symbol iommu_get (err 0)
insmod: error inserting '/lib/modules/2.6.37.6/kernel/drivers/dsp/syslink.ko': -1 Unknown symbol in module

Kernel patch related with this problem is provided with SysLink, but I couldn't apply it. I checked what that patch is doing and I tried to do it manually. The solution was to comment out in omap-iommu.c statement:

/* #if defined(CONFIG_OMAP_IOMMU_IVA2) */

Finally after long struggle it works for me with kernel from PSP mentioned in my previous post. I also used Angstrom file system, but it is some old Beagleboard demo image. Why? Because old kernel, so also old filesystem... This is another thing that is confusing for me. How kernel is related to file system. Could I use any kernel version (e.g. required by SysLink some of 2.6.x)  and recent Angstorm file system built with that online tool or bitbaked? Or there are some requirements that file system should know during the building process with which kernel it will work (I suppose that builders are prepared now to work with recent 3.x versions)? I tried to find answers for these questions on Beagleboard site and Beagleboard group, but I still don't get it.

Linux 3.x with SysLink 2.x ? That sounds interesting. I could then use kernel provided with Angstrom without looking for it on my own.

Finally I ask for specify kernel versions numbers, it is really hard to find correct :)

I know my questions may sound stupid. I don't want to harp on the subject. I spent much time on it, but I'm still newbie. So if you still have patience...

PS. If it is possible, could someone move that discussion about kernels and file systems to the separated thread, please? It's a bit off-topic.

Regards,

Valdez

Hi Valdez,

> Linux 3.x with SysLink 2.x ? That sounds interesting. I could then use kernel provided with Angstrom without looking for it on my own.

That is exactly what we expect you to look into. From my understanding, the Beagleboard program is meant to be a community-based initiative, where users have full freedom to experiment with bleeding edge software. On the flip side, it does require more effort from the end-user as opposed to e.g. someone using the omap3530 evm that is shipped with a pre-canned SDK made for a specific version of the kernel. The latter approach is geared towards users who put the emphasis on ease/speed of development at the cost of using an older software stack. We leave it up to customers to weight the tradeoffs.

As mentioned previously, we expect SysLink to work with the latest Linux kernels. We did test SysLink using whichever version of the kernel we got our hands on at the time (2.6.34 in this case), but it doesn't preclude using newer kernels. You do raise a good point that there are small tweaks like the one you found for patches supplied in the product since patches are tied to a given kernel version. I will file an enhancement for the documentation to better assist the users with this in future releases. Thanks for the feedback.

Unfortunately I don't track the Beagleboard development community close enough to recommend the best baseline for you to use as of today. The forums on Beagleboard.org (http://beagleboard.org/discuss) is supposed to assist you with this. If you find that you can't get SysLink to work on the recommended kernel then you can come back and we can work it out.

Best regards,

Vincent

Thank you Vincent for all your support and explaining words.

I'm back with debugging issue.

I still get that "IcePick_C_0: Error connecting to the target: (Error -150 @ 0x0) One of the FTDI driver functions used during configuration returned a invalid status or an error. (Emulation package 5.0.952.0) ".

To remind, I use Ubuntu, XDS100v2 and default from CCSv5.3.0.00090 target configuration: "OMAP3530". Test configuration is finished with success.

xds100serial in /ccs_base/common/uscif gives me:

Scanning for XDS100 emulators...

VID/PID    Type            Serial #    Description
0403/a6d0  XDS100v1/v2     TITNT15A    Texas Instruments Inc.XDS100 Ver 2.

This is output of Test connection:

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

/home/valdez/.TI/3964360170/0/0/BrdDat/testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'libjioserdesusb.so'.
The library build date was 'Dec 19 2012'.
The library build time was '23:14:27'.
The library package version is '5.0.952.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 512 32-bit words.

The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 6 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 512 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 512 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG DR Integrity scan-test has succeeded.

[End]

In target configuration settings, when I click on that IcePick_C_O there is initialization script: ../../emulation/gel/omap3430es2_icepick.gel. Maybe it is wrong (3430)?

Can you help? It is now very urgent for me.

Hi Valdez,

I am using the same GEL file as you are:

..\..\emulation\gel\omap3430es2_icepick.gel for IcePick_C_O

..\..\emulation\gel\omap3430_c64plus.gel for C64XP_0

..\..\emulation\gel\omap3530_cortexA.gel for Cortex_A8_0

This is the default OMAP3530 Target Configuration for my emulator.

At this point, I think the differences between our setup are: VirtualBox+Ubuntu host vs. Windows XP, XDS100v2 vs. Blackhawk emulator, and CCS 5.3 vs 5.1. Depending on what you have available on your end, you might want to try changing these if possible.

Also, make sure your SysLink application does run fine without CCS, as it should.

Best regards,

Vincent

Hello,

Finally I suppose I have connection: http://uppix.net/d/3/9/92b100e07f5961537fd2224fe914b.png :)

Because I have second system in my VirtualBox, Windows 7, I have installed there CCSv5.1 and I tested it. It worked, so I have installed all the updates to get CCSv5.3. It also finished with success. I assumed that it must be some problem with FTDI driver. Because Ubuntu uses open source version, I decided to install official driver from FTDI site (they support Linux and there is instruction how to install it). That allows me to connect to DSP core after release from Slaveloader application :)

Now I have to learn what should be next, when I should load load DSP app, when I should start ARM app.

Best regards,

Valdez

Hi Valdez,

Glad you found the root cause to your issue. The bottom line from the SysLink standpoint is that you should be able to connect after pulling the slave out of reset via the Slaveloader.

Best regards,

Vincent

Hi Vincent,

do you know what I could do then to debug DSP side application? I though that I've seen some description somewhere but now I don't see it and don't know what to do.

What I'd like:

1. see that Log_print0(Diags_ENTRY, "Server_exec: sent hello world event to host"); messages,

2. maybe some possibility to go through the code line after line? Like when I use JTAG emulator to load program and run on DSP.

Best regards,

Valdez

After some reading, I suppose that is some moment I should use CCS option: "Load symbols" and I can get that symbols from 'debug' version of application. That's the difference between 'release' and 'debug' versions?

And I don't know when to load them. run.sh script has such a procedure:

./slaveloader startup DSP server_dsp.xe64P memmap.txt

./app_host DSP

./slaveloader shutdown DSP memmap.txt

because as I understand, first line loads that application and then run ProcMgr_start() what allows me to connect to DSP.

And when I should then run ./app_host DSP ?

I tried to load symbols after connecting, I get error:

Can't find a source file at "/db/vtree/library/trees/avala/avala-r22x/src/ti/sysbios/family/c64p/Cache.c"

but I didn't build SysLink example in CCS. Is it necessary?

Best regards,

Valdez

Finally it works :)

I needed to add that infinite loop and then I used Optional approach with slaveloader. I need that loop because when I loaded symbols, it fall into Cache.c or Ipc.c file and I could go to main_dsp.c file. I don't fell that I have control over it, e.g. only first "Log_print0(Diags_EXIT, "-->main:");" showed into LoggerBuf in ROV, don't know why there is no other if they exist in code. And XDS100v2 in Linux is really slooooow... But it works what makes me happy.

Thank you a lot Vincent!