TI E2E Community
ECU can't work in EZSDK
I new a CCS project and add my own ECU code to the new project. The project can cancel echo.
But the ECU can't cancel echo when I add the code to EZSDK(5_02_02_60).
Did you test ECU in EZSDK when CCS is not used ?
I run AER lib, G.729 lib in EZSDK and they can work good. I get these lib from TI.
Why my ECU code can work in CCS and can't work in EZSDK ?
golden tigerBut the ECU can't cancel echo when I add the code to EZSDK(5_02_02_60).
Can you clarify the error you're getting? Does the DSP executable compile/link correctly, linking in the ECU lib?
Could it be a cache configuration issue (maybe in your CCS-based app the cache is disabled, but in the EZSDK the cache is enabled and you need to deal with Cache Coherency?)?
Or a memory map issue - where are your input/output buffers coming from (provided from the A8? Or Memory_alloc()'d from the DSP? Or statically linked into the DSP executable? Or...?)? Are they accessed by the CPU or DMA (or both!)? Might check for alignment constraints on the ECU and/or cache usage.
Do you get errors returned from ECU? Or a crash? Or is it just bad data?
I think we need a little more info before we can provide further advice. If it's a build issue, we'll provide different advice than a runtime/integration/functionality issue.
Platform: TI8168 ECU:10.92.0.4 EZSDK:5_02_02_60
1. AER lib can work good in EZSDK. The same integration way is used to compile/link ECU.
Codec Engine is used to process voice data by ECU API.
ECU can't cancel echo, output buffer and input buffer is the same. No error returned from ECU.
2. I deal with Cache Coherency when cache is enabled, but the result is the same.
In the EZSDK, how to disable the cache ?
In all_syslink.cfg of Server part, I modify the code to disable the cache:
/* cache configuration for dsp*/ var Cache = xdc.useModule('ti.sysbios.family.c64p.Cache'); //Cache.MAR0_31 = 0xffffffff; //Cache.MAR32_63 = 0xffffffff; //Cache.MAR64_95 = 0xffffffff; //Cache.MAR96_127 = 0xffffffff; //Cache.MAR128_159 = 0xffffffff; //Cache.MAR160_191 = 0xffffffff; //Cache.MAR192_223 = 0xffffffff; //Cache.MAR224_255 = 0xffffffff; Cache.initSize.l1pSize = Cache.L1Size_0K; Cache.initSize.l1dSize = Cache.L1Size_0K; Cache.initSize.l2Size = Cache.L2Size_0K;
Is it right ?
3. In codec engine, input buffers and output buffers are allocated in APP part. Then Codec part get the input buffers to process. The processed data is filled to output buffers.
Each ECU instance references up to fifteen buffers. These buffers's alignment and size is satisfied.
I tried to use static array and/or MEM_alloc() to allocated these fifteen buffers.
But the buffer 5 (expand delay line buffer) is wrong when ecuSendIn() is called. One -32124 is in every two data. I have packed the samples correctly.
For example, rinBuffer(u law) is set to 0xFF, I can see that buffer 4 (delay line buffer) is all 0xFF. Expand delay line buffer should be all zero.
But expand delay line buffer :
0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
I think that this error is key point.
Which ECU libraries are you linking with? Jean-Denis just uncovered an issue when the "ecu_cm" library is linked. Depending on the linker order, the code from the "ecu_cm" library may be used in place of the code from the "ecu_a" library.
To be a little clearer... the "ecu_cm" library is the C-model (prototype) from which the Assembly code (ecu_a) is derived. The "ecu_cm" library is not intended to be linked, just the "ecu_c" and "ecu_a" libraries. I suspect a bug in the C-model code such that it was not updated for 8-bit atomic word size.
Please give this a try and let us know if this solves the issue.
I haven't tried to link ecu_cm libraries. But theProf must set to "whole_program_debug"(release), the ECU can work good. When theProf is set to "debug", the some APIs of ECU can't find defined. The "whole_program_debug" will cost much time to compile. I hope that "debug" can be supported, so can you offer the right ecu_cm library?
Many library have no *_cm library in VoLib. I only can use release model to compile, it cost much time in testing code.
However, the ECU can work good and thank you for your help.
I'm happy to hear that we finally understand this issue and that you can move on with your development.
I will enter an IR (issue report) for the CM library and be sure to include a fix in the next release.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.