dsplink configuration problem

Dimitry Denisov

Prodigy 245 points

Other Parts Discussed in Thread: OMAPL138

Hello

I builded sample application "message" and "readwrite" and they seemed run ok.

But then i tried to write simple console application for GPP.

I call in the main() those functions:

PROC_setup ()

PROC_attach ()

PROC_load ()

PROC_start (processorId) ;

On the DSP side i have simple application "bios_led", it toggles led.

I call in main()

DSPLINK_init ()

When gpp application starts it successfully loads bios_led and starts it, but then it hangs.

This behaviour is well described in this post http://e2e.ti.com/support/embedded/linux/f/354/p/145131/527312.aspx#527312

The deadloop is exactly the same:

dsplink_linux_1_65_00_02\dsplink\gpp\src\ldrv\drv\Shm_drv.c

NORMAL_API
DSP_STATUS
SHMDRV_handshake (IN ProcessorId dspId,
IN Uint32 linkDrvId,
IN DRV_Handshake hshkCtrl)
{

......

/* Wait for DSP to write its handshake value. */
/* while ( (ctrlPtr->handshakeDsp != dspHandshake)
&& DSP_SUCCEEDED (status)) {
i ;
if ( (linkDrv->hshkPollCount != (Uint32) -1)
&& (i == linkDrv->hshkPollCount)) {
status = DSP_ETIMEOUT ;
SET_FAILURE_REASON ;
}*/

......

}

This is because expecting value of ctrlPtr->handshakeDsp is BABA01FF but actual value i get is BABA0103.

Can anybody post a simple example of how accurately configure DSPLink on DSP and GPP sides in minimum configuration including PROC and NOTIFY modules?

Thanks in advance

here is some trace output:

122896 PID:400002 TID:350000e DRV shared memory base symbol DSP address [0xc3e10d00]n
122896 PID:400002 TID:350000e Expected DSP handshake value: [0xbaba01ff]
124365 PID:400002 TID:350000e Actual DSP handshake value: [0xbaba0003]
124366 PID:400002 TID:350000e DSP-side configuration mismatch/failure
124366 PID:400002 TID:350000e 0 -> success
124366 PID:400002 TID:350000e Positive value -> DSP-side failure code.
124367 PID:400002 TID:350000e (Uint32) -1 -> DSP-side component was not initialized.

124367 PID:400002 TID:350000e ProcId received : 0, Expected : 0
124368 PID:400002 TID:350000e DRV configuration status [0x0]
124368 PID:400002 TID:350000e IPS configuration status [0x1]
124368 PID:400002 TID:350000e POOL configuration status [0x0]
124369 PID:400002 TID:350000e MPCS configuration status [0xffffffff]
124369 PID:400002 TID:350000e MPLIST configuration status [0xffffffff]
124369 PID:400002 TID:350000e MQT configuration status [0xffffffff]
124370 PID:400002 TID:350000e DATA configuration status [0x0]
124370 PID:400002 TID:350000e RINGIO configuration status [0xffffffff]
124371 PID:34f000e TID:350000e Status: 80008052

over 13 years ago

0 Robert Tivy over 13 years ago

TI__Mastermind 18260 points

Dimitry,

Your problem seems very similar to the one described here: http://processors.wiki.ti.com/index.php/Troubleshooting_DSPLink_configuration_issues#Problem:_PROC_start_failed_with_configuration_mismatch.2Ffailure_showing_some_modules_with_0.2C_some_with_1.2C_2_etc._and_others_with_0xffffffff

Please follow the advice given there, and if that doesn't prove helpful, post a reply back here and I will look into it further.

Regards,

- Rob

0 Dimitry Denisov over 13 years ago in reply to Robert Tivy

Prodigy 245 points

Thanks Rob

From the information you mentioned I see that MPCS, MPLIST, MQT, RINGIO (i don't use they) are not configured and moreover somethig wrong with IPS (configuration status [0x1]) so i need try to change heap size.

Please, can you suggest me solution of how can i simply configure those modules (i need only stub for they) in my dsp initialization code?

And how can i increase heap?

Thanks for support

0 Robert Tivy over 13 years ago in reply to Dimitry Denisov

TI__Mastermind 18260 points

Dimitry,

The components with [0xffffffff] status were probably configured on GPP side but not on the DSP side. When building DSPLink, you first run the dsplinkcfg.pl script which configures components, followed by building the DSP and GPP sides with those configured components. Your errors indicate that the GPP side was expecting those failed components and presumably the DSP side did not contain them.

The dsplinkcfg.pl script supports an option named "--comps" (for "components"). It is assigned a string of letters, with each letter corresponding to one of the DSPLink components. In your previous post you asked for a configuration including PROC and NOTIFY. You would therefore set:
--comps=pn
and then rebuild both the GPP and DSP sides of DSPLink. FYI, your current GPP side probably had the letters "slr" in --comps to indicate MPC[S], MP[L]IST, [R]INGIO (MQT is handled outside of --comps).

Dimitry Denisov said:

And how can i increase heap?

The IPS_init() function allocates its memory from DSP/BIOS from a MEM segment that is defined in the platform.h file. In the file
   <dsplink_install>/packages/dsplink/dsp/inc/DspBios/5.XX/<platform>/platform.h (where <platform> is your platform)
there is the line
    #define DSPLINK_SEGID   DDR2 (or it might be set to DDR or SDRAM)
See what is set in your installation. The DSP/BIOS application .tcf file (or some .tci file that it imports) should have a MEM.create() of that segment (or it might be MEM.instance() if already created), along with heap parameters if appropriate. It is in those heap parameters that you would increase the size of the heap contained in that MEM segment. In the DSP/LINK samples, their .tcf file includes a .tci file that contains these assignments. I don't know your platform, but for example, for the OMAPL138 there is this file:
    <dsplink_install>/packages/dsplink/dsp/inc/DspBios/5.XX/OMAPL138GEM/dsplink-omapl138gem-base.tci
which has this entry:
    var DDR = prog.module("MEM").instance("DDR");
    DDR.base             = RESET_VECTOR.base + RESET_VECTOR.len ;
    DDR.len              = 0xFFF80;
    DDR.space            = "code/data";
    DDR.createHeap       = true;
    DDR.heapSize         = 0x10000;
    DDR.comment          = "DDR";
so you would want to change DDR.heapSize to something larger in order to increase the memory available in DSPLINK_SEGID (which is used by lots of DSP/LINK allocations).

Regards,

- Rob

0 Dimitry Denisov over 13 years ago in reply to Robert Tivy

Prodigy 245 points

Oh my God! It Works!!! %)

Grate thanks!

1. Configuration of modules:

I made --comps = pn and immediately got an errors.

Thirst of all there were some errors with macros described in post http://e2e.ti.com/support/embedded/linux/f/354/t/99666.aspx

I commented out '#if defined' which guards those macros:

D:\TI\dsplink_1_65_00_03\dsplink\dsp\inc\C674X\c64xxdefs.h

// !!! MY COMMNET#if defined (MPCS_COMPONENT)
#define MPCSOBJ_PROC_PADDING ((CACHE_L2_LINESIZE - sizeof (MPCS_ProcObj)) / 2)

#define MPCS_CTRL_PADDING (( CACHE_L2_LINESIZE \
- ( (sizeof (Uint32) * 5) \
+ (sizeof (Void *)))) / 2)

#define MPCS_ENTRY_PADDING (( CACHE_L2_LINESIZE \
- ( (sizeof (Ptr)) \
+ (DSP_MAX_STRLEN * sizeof (Char)) \
+ (sizeof (Uint16) * 2))) / 2)

#define MPCS_TURN_PADDING (( CACHE_L2_LINESIZE \
- (sizeof (Uint16))) /2)
// !!! MY COMMNET#endif /* if defined (MPCS_COMPONENT) */

Second.

There is an error in drv_pmrg.c file at line 1714.

case CMD_IDM_ACQUIREID:

{

hr = CeOpenCallerBuffer((PVOID*) &imgMapPtr,

args->apiArgs.idmAcquireIdArgs.idKey,

MAX_ARGUMENT_VAL_LENGTH, ARG_IO_PTR, FALSE);

hr = CeOpenCallerBuffer((PVOID*) &argMapPtr,

args->apiArgs.idmAcquireIdArgs.id,

sizeof(Uint32), ARG_IO_PTR, FALSE);

retStatus = IDM_acquireId (args->apiArgs.idmAcquireIdArgs.key,

imgMapPtr,

argMapPtr) ;

hr = CeCloseCallerBuffer((PVOID) argMapPtr,

args->apiArgs.idmAcquireIdArgs.id,

sizeof(Uint32), ARG_IO_PTR);

hr = CeCloseCallerBuffer((PVOID) imgMapPtr,

args->apiArgs.idmAcquireIdArgs.idKey,

MAX_ARGUMENT_VAL_LENGTH, ARG_IO_PTR);

args->apiStatus = retStatus ;

//} !!! MY COMMENT

}

break ;

I commented out unnecessary '}' .

2. Heap.

I found that

#define DSPLINK_SEGID DDR

in platform.h but in my DSP BIOS project there was no heap enabled for this memory. I enabled heap creation in tcf file.

After that i was able successfully run my DSP project from console application on WINCE 6.

Thanks to all.

0 Robert Tivy over 13 years ago in reply to Dimitry Denisov

TI__Mastermind 18260 points

Dimitry,

Excellent, great to hear that you got it working.

I suspect that the MPCS problems are caused by a problem in the DSP/LINK build framework, where the file ldrv_mpcs_os.o is incorrectly being added to the build. Since the build framework is fairly complex it's not immediately apparent what the problem is. Either that, or the PROC and NOTIFY components actually should be enabling MPCS automatically but are not doing so, leading to incomplete references.

I would suggest including "s" in your "--comps=" to enable the MPCS module and not have to hack the DSP/LINK header file, but including "s" will also bring in the POOL module automatically, so it may be too much for your needs.

Thanks for pointing out that problem in drv_pmgr.c, I will file a bug on that one. Looks like the bug is present only in the WinCE build.

Regards,

- Rob

0 Robert Tivy over 13 years ago in reply to Dimitry Denisov

TI__Mastermind 18260 points

Dimitry Denisov said:

There is an error in drv_pmrg.c file at line 1714.

case CMD_IDM_ACQUIREID:

{

hr = CeOpenCallerBuffer((PVOID*) &imgMapPtr,

args->apiArgs.idmAcquireIdArgs.idKey,

MAX_ARGUMENT_VAL_LENGTH, ARG_IO_PTR, FALSE);

hr = CeOpenCallerBuffer((PVOID*) &argMapPtr,

args->apiArgs.idmAcquireIdArgs.id,

sizeof(Uint32), ARG_IO_PTR, FALSE);

retStatus = IDM_acquireId (args->apiArgs.idmAcquireIdArgs.key,

imgMapPtr,

argMapPtr) ;

hr = CeCloseCallerBuffer((PVOID) argMapPtr,

args->apiArgs.idmAcquireIdArgs.id,

sizeof(Uint32), ARG_IO_PTR);

hr = CeCloseCallerBuffer((PVOID) imgMapPtr,

args->apiArgs.idmAcquireIdArgs.idKey,

MAX_ARGUMENT_VAL_LENGTH, ARG_IO_PTR);

args->apiStatus = retStatus ;

//} !!! MY COMMENT

}

break ;

Hi Dimitry,

In the process of making a fix for the problem you point out above, I came to realize that while the closing '}' that you commented out is indeed in the wrong place, there is a missing '}' above that line (a few pages above, not in that local 'case'). I realized this because when I removed the bad '}' my editor indicated that the braces in that function didn't balance. Having found this, I then wondered how your file after your change would even compile.

Regardless, I believe that if you comment out that '}' then you should add a closing '}' to the place where it is missing. This place is reflected in this patch output:
From efb87679021373bcd48d49ffd31a0c81d44a1fe1 Mon Sep 17 00:00:00 2001
From: Robert Tivy <rtivy@ti.com>
Date: Wed, 11 Jul 2012 16:10:48 -0700
Subject: [PATCH] Fixed bad bracketing (closing '}') in DRV_CallAPI()

Although the '{' and '}' balanced in the function, one of the '}' was
in the wrong place.
---
src/dsplink/gpp/src/pmgr/WinCE/drv_pmgr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/dsplink/gpp/src/pmgr/WinCE/drv_pmgr.c b/src/dsplink/gpp/src/pmg
r/WinCE/drv_pmgr.c
index f74d301..9fdf3f2 100644
--- a/src/dsplink/gpp/src/pmgr/WinCE/drv_pmgr.c
+++ b/src/dsplink/gpp/src/pmgr/WinCE/drv_pmgr.c
@@ -1519,7 +1519,9 @@ DRV_CallAPI (Uint32 cmd, CMD_Args * args)
                 hr = CeCloseCallerBuffer((PVOID) poolOpenParams,
                     args->apiArgs.poolOpenArgs.params,
                     MAX_ARGUMENT_VAL_LENGTH, ARG_IO_PTR);
-            args->apiStatus = retStatus ;
+
+                args->apiStatus = retStatus ;
+            }
         }
         break ;

@@ -1699,7 +1701,6 @@ DRV_CallAPI (Uint32 cmd, CMD_Args * args)
                 args->apiArgs.idmAcquireIdArgs.idKey,
                 MAX_ARGUMENT_VAL_LENGTH, ARG_IO_PTR);
                 args->apiStatus = retStatus ;
-            }
         }
         break ;

--
1.7.9.4

The line numbers might not match up with your file, but the diff output should show the place nicely.

Regards,

- Rob

Processors

Processors forum

dsplink configuration problem