EZSDK 5.03 and universal_copy - Ipc_procSyncStart failed

Hi, in the meanwhile I worked all through from start - have re-built completely  the EZSDK 5.03.01.15, generated a new sd-card, then followed the steps from DM814x_EZ_5.03_Software_Developers_Guide#Running_the_SysLink_examples, the system seems to be frozen again. 

And via

modprobe syslink TRACE=1 TRACEFAILURE=1 TRACEENTER=0 TRACECLASS=3

again I received the loop of messages "Ipc_attach: Ipc_procSyncStart failed!"

To be honest, I actually would expect that at least the delivered samples should be working by following step by step your descriptions... Anywhere I must have something overlooked - or maybe there is a small detail which was forgotton to mention in your documentation?

Yet hopefully to hear from you,
Joern.

After reading this entry I searched through the EZSDK 5.01.01.15 for files Platform.xdc containing string "ti.catalog.c6000", and I found some, but no such files within the CE examples. Within syslink examples there are two of those Platform.xdc files for TI814x and TI816x which differ concerning a memory entry HOST_DSP_NOTIFYMEM (but yet mentioning DDR2 - we have DDR3 at our evmTI8148).

Please let us know if concerning memory map there is any difference between TI814x and TI816x, with regard to your EZSDK Memory Map explanation.

Please let us know if notifyk.vpssm3_sva=0xBF900000 is actually the right setting for CE examples, and let us know if there are other settings like that which should be done.

Please let us know if there was a setting for CE examples like elsewhere done in Platform.xdc, and please spend a short explanation concerning these settings (or give us a hint where the documentation is to be found).

Yet hopefully to get an answer,
thanks in advance,

Joern.

If that might help concerning an answer, I added an output of the SharedAddr value in Ipc.c, now the error messages loop looks like that:

Ipc_attach: Ipc_procSyncStart failed!
Ipc_attach: Ipc_module->ipcSharedAddr = 0xd2000000

Was a somewhat blind try of mine to maybe catch a small piece of the problems reason... however, until now this address doesn't spend me an idea about that. But you TI people, if any additional output around this failing Ipc_attach() call would help you answering, please let me know, I will add it and provide the test results.

Regards,
Joern.

Concerning DSP clock rate. From Ramseys hint within this thread entry I came to the brand new TI wiki entry by Chris Ring, SYS/BIOS dmtimer configuration for TI81xx, and now I ask myself (or, if any of you is willing to answer, I ask you too, of course): should that be considered when compiling or using syslink.ko as well? I didn't found any concerning settings within the syslink sources (but only there within the sample sources). And if I'm assuming right that CodecEngine makes use of syslink.ko, should CodecEngine consider that timing setting as well (did'n t find any concerning setting there)?

Regards,
Joern.

Next step within that talk to myself...

The previous entry concerning the change of clock source in the PSP from 32kHz to 20MHz lead me so far that now the problem "Ipc_attach: Ipc_procSyncStart failed!" does no longer exist for the syslink samples.

Now yet I have to find out how to change that times setting concerning the CodecEngine's use of syslink...

Any comments?

Regards,
Joern.

Hi Ramsey,

thanks for your hint, that solved the remaining rest of the problem. Yesterday in the evening I tested around changing that timer frequency within my universal_codec-based app, but since this app runs on ARM side it obviously had been the wrong way. Now, as I changed this setting for the codec server, phew, it works again. I think I'll document that part within the wiki.

Concerning my "exceptional persistence" - that is only the persistence of 'sink or swim'. We decided to use your platform, and yet we think we had good reasons for that, but now of course more and more we are bound to that our decision to use the TI platform. Sometimes that makes me fear.

However, actually I see some positive changes within the information provided by you, last not least the forum and the wiki are helpful places.

Just as supplement:

• In my opinion it was more safe to also set timer.intFreq.hi = 0 - for the case that anywhen in the future there is a change of the default high value away from the current zero.
• I ask myself if actually it is such a good idea to change this setting for each relevant application - it's fine, that this is possible by your framework, but I would prefer to spend those platform-wide information at one, central place. That should be discussed, and if such a place exist and actually seems to be the better choice, it should be documented.
• I wished that hints like this one from Chris (Getting the D[a]M[n] Timer Config Right on TI81XX) would come via a special newsletter channel where only those hints will send, no common information, no advertising, just only such 'emergency hints', dedicated to the platfoms I have choosen to be interested in.
• At several places within the wiki there are already hints concerning the often mishmash concerning TI81xx vs. DM81xx. You are right suspecting that we have a DM8148 platform. And maybe I am right if I assume that the TI814x noun belongs to the Integra platform (which differs from the DaVinci by just leaving out the HDVPIC?). I often stumbled over those TI nouns, last not least concerning your 'internal' platform names like 'netra'. Sometimes it droves me crazy. I looked something around - and also today did not found an simple overview for those nouns. It should be placed within the wiki. It should be provided, because of course those nouns come and go away within development and marketing, and it will not be possible for you to get it consistently all at once at all places. A table of short and clear clarified nouns (including hints concerning their potential mishmash use) would be very helpful.

Thanks again,
best regards,
Joern.

Joern,

I'm happy you are finally having some success. I do hope your experience with Texas Instruments gets better. Your suggestions above are good ones. You could centralize the dmtimer configuration in one file and then include that file in all your config scripts. This would make it easier to apply changes later.

globalConfig.xs
// Change timer frequency for Linux server
var timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
timer.intFreq.lo = 20000000;
timer.intFreq.hi = 0;

app.cfg
// include globalConfig
var globalCfg = xdc.loadCapsule("globalCfg.xs");

There is more documentation on xdc.loadCapsule here: http://rtsc.eclipse.org/docs-tip/XDCscript_-_xdc.loadCapsule

We don't have email update lists. The best I can suggest is to subscribe to the blogs via RSS feeds. Hopefully, the SDK teams will have more blogs in the future.

We struggle with device names as well. When a new chip is in development, it will often have an internal code name, such as Netra. When the chip goes into production, it will be assigned a specific device name but sometimes these names are changed at the last minute. It cause much confusion for us as well. Here is a brief list of what the device name implies, but there is no hard and fast rule.

AM = ARM only
C6A = C6 + A = DSP (C6x) + ARM
DM = Digital Media

The DM parts are the most complex with lots of different processors.

~ Ramsey