ACPY3_wait() on cycle accurate simulator again

Nothing should really change when you move from H/w to cycle accurate simulator.

Could you share your DMAN3 configuration ? We could try making some changes in the configuration and experiment some.

What version of Framework Components are you using ?!

I see the FC veresion (1.20.02). Just the configuration file details are required.

Thanks,
gunjan

Hello Gunjan,

I am not using the XDC tooling to configure DMAN, so it's possible that I am shooting myself in the foot that way.  My manual setup in C is as as follows:

1)  Declare extern heap regions that are defined in my .tcf file:

extern DMAN3_Params DMAN3_PARAMS;
extern int IRAMHEAP;
extern int L1DHEAP;
extern int EXTMEMHEAP;

2)  Modify default DMAN3_PARAMS and init the libraries:

/* All other members of this struct are left to their default values */  
DMAN3_PARAMS.heapInternal = IRAMHEAP;
DMAN3_PARAMS.heapExternal = EXTMEMHEAP;
DMAN3_init();
ACPY3_init();

3)  Manually link the application against acpy3.a64P and dman3.a64P

I thought that the two different configurations may be initializing DMAN3_PARAMS differently, but I checked the values in the struct in memory after step 2 on both the 2430 hardware and the 2430 simulator and couldn't see any differences.  I also checked to make sure that L1DHEAP and IRAMHEAP were being placed in internal memory in both configurations.  Are there other values that may need to be initialized elsewhere?

Thanks,

-Matt

Matt,

"C" configuration should be fine, you could initialize the other entries in the DMAN3_PARAMS structure, right now you are using the defaults.

One thing you can try changing is the PaRam# used as a "NULL PARAM". This PaRam is used to plug the  end of a linked transfer. By default it is set to PaRam #0. Often other unused QDMA channels point to this PaRam sometimes causing issues. Why don't you change DMAN3_PARAMS.nullPaRamIndex to some other unused PaRam number (95 ?).

Also be mindful of the resources being exercised by DMAN3, and make sure you aren't using one that might be used by some other entity in your system (Drivers etc).

The defaults being used by DMAN3 for your release are:-

Param #s 96 to 127

QDMA channels 0 - 3

TCCs (bitmask) 0x5 (Low), 0xFFFFAFF7 (High)

Null Param # 0 (Which you can try and change)

You may have already seen this, but this link talks about common issues that cause ACPY3_wait stalls:-

http://wiki.davincidsp.com/index.php/Framework_Components_FAQ#Why_does_my_alg_hang_in_ACPY3_wait.28.29.3F

If none of the above work, this might be one for the Simulator team since it goes through fine on h/w !

Thanks,

Gunjan

Gunjan,

Sorry about the delayed response.  I've found other ways to deal with the problem for the moment, but it does look like I've found an interesting behavior in my current configuration.  Changing the default parameters didn't change the behavior on the simulator, and I don't think I'm making any of the FAQ mistakes.  It may be a little while, but I'll see if I can put together a minimal project that exhibits the issue.  I'll also give it a shot on CCS 4.0 and see if it changes anything.

Thanks for your help.

-Matt

Matt,

I'd be interested in looking at the example whenever you have the time to create/upload it. For DMAN3, any changes you make to the configuration ends up in the DMAN3_PARAMS structure, so you could look at that to confirm if the values you are trying to modify actually got updated correctly.

Good to know you could proceed.