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.

L138 Handshake Issue.

Other Parts Discussed in Thread: OMAP-L138

Looks like I have DSPLink at least started on the L138(BIOS5, DSPLink1.65 on DSP, semi-custom on ARM, based on latest L138 DVSDK).  However, it gets to the handshake point and halts due to a mis-match.  I've configured both sides to have the same components installed.  For whatever reason the DSP handshake value is 0.

I have all components but the CHNL and trying to run the readwrite sample application.

Here's the Trace output(I added the 3 check lines at the end to see values):

Feb 01 05:22:20 3 30 1 DSPLINK:Leaving DA8XXGEM_halPwrCtrl () status [0x8000]

Feb 01 05:22:20 3 30 1 DSPLINK:DSP started !

Feb 01 05:22:20 3 30 1 DSPLINK:Leaving DA8XXGEM_start () status [0x8000]

Feb 01 05:22:20 3 30 1 DSPLINK:Leaving DSP_start () status [0x8000]

Feb 01 05:22:20 3 30 1 DSPLINK:Entered LDRV_DRV_handshake ()
dspId [0x0]
hshkCtrl [0x1]

Feb 01 05:22:20 3 30 1 DSPLINK:Entered SHMDRV_handshake ()
dspId [0x0]
linkDrvId [0x0]
hshkCtrl [0x1]

Feb 01 05:22:20 3 30 1 DSPLINK:Leaving SHMDRV_handshake () status [0x8000]

Feb 01 05:22:20 3 30 1 DSPLINK:Leaving LDRV_DRV_handshake () status [0x8000]

Feb 01 05:22:20 3 30 1 DSPLINK:Entered LDRV_DRV_handshake ()
dspId [0x0]
hshkCtrl [0x2]

Feb 01 05:22:20 3 30 1 DSPLINK:Entered SHMDRV_handshake ()
dspId [0x0]
linkDrvId [0x0]
hshkCtrl [0x2]

Feb 01 05:22:20 3 30 1 DSPLINK:Expected DSP handshake value: [0xbaba01bf]
Feb 01 05:22:20 3 30 1 DSPLINK:PollCount value: [0xffffffff]
Feb 01 05:22:20 3 30 1 DSPLINK:DSP value: [0x0]
#
  • Anyone?
    What would cause the DSP-side handshake response to always be ZERO  no matter which sample application I try to start?
    I've gone over memory configs, TCF, TCI, MK, build, and other files of both ARM/DSP sides and all match.  I'm reserving the 0xc3e0 0000 region of memory as well in the OS.  If the DSP is "started", why would there be a ZERO for handshake?  It's as if either memory is configured or pointed incorrectly or the DSP really isn't running. 

  • Handshaking issues in DSPLlink are typically attributed with misconfiguration of DSPLink on both cores (GPP & DSP) or memory map related discrepancies that need to be sorted out.

    You can take a look at:

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

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

    Are you seeing a particular error?  Do you have a debug setup for the DSP? If so, where is the DSP stuck?

  • Hi Arnie!

    I've gone through those pages multiple times.  That's why this just isn't making sense.

    There are no errors from the GPP side - only a return of 0 from the DSP and with a POLLCOUNT of -1, the application just sits in the loop checking for a handshake return value to be good.  The GPP side supposedly loads and brings the DSP out of reset with success(no error messages).

    Since I built the DSP side in a Linux virtual machine(Ubuntu in VirtualBox) I have no DSP debug at this point so I can't tell what's happening.  Suggestions?

  • I suspect that the DSP is out to lunch(either executing in invalid memory or crashed somehow) though not sure why.  I've have a few clarifying questions to make sure we're on the same page. You said you are running the provided DSPLink readwrite samples, correct?  You are running Linux on the ARM, correct? What version of DSPLink are you currently using?  Are you running on an OMAP-L138 EVM board?  Are you using DSPLink from the DVSDK for this device?

    Regarding debugging the DSP.  If you are using OMAP-L138 EVM from Logic, the board has a built-in USB based XDS-100 emulator, which should allow you to connect to the device using the USB cable with Code Composer Studio (CCS) IDE.  If you have a JTAG based emulator that would be preferred due to speed. There are versions of CCS for both Linux and Windows that should allow you to connect to the DSP for this device.  Here is a good topic that covers DSP debugging from a DSPLink perspective to help in determining what might be happening on the DSP

    http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP-L138_using_CCS

  • OK, I have some new info and some success:

    Platform HW:   LogicPD EVM and Avnet EVM(tried 2 separate HW EVM's)

    DSPLink(DSP side):  Ver 1.65.01.05 from the DVSDK.

    DSPLink(GPP side):  Ver 1.62?  This is a QNX BSP build and seems to refer to a V1.62.

    I was able to configure CCSV5 in Linux to connect to the DSP side.  It seemed that the DSP was never coming out of reset.  I was able to start the DSP using CCS and get further with the handshake.  The handshake now works - I get the proper value on both DSP and GPP sides.  Then there was a version issue, but configuring(command line option in the QNX DSPLink) to match the DSP version now gets further.

    The issue now is a LDRV_POOL_getPoolId error.  On the first request for a PoolId, there is success.  However, further getPoolId requests fail with 0x8000802d.  I am now investigating this issue.