• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 366 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ECU can't work in EZSDK

golden tiger
Intellectual 625 points
Other Parts Discussed in Thread: SYSBIOS

Hi ,

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 ?

  • 0
    TI__Genius 17205 points

    golden tiger said:
    But   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.

    Chris

  • 0 in reply to Chris Ring
    Intellectual 625 points

    Hi Chris,

    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.

          

      

  • 0
    TI__Intellectual 1605 points

    Hi Tiger,

    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.

    Regards, Charlie

  • 0 in reply to CharlieF
    Intellectual 625 points

    Hi CharlieF,

    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. 

  • 0 in reply to golden tiger
    TI__Intellectual 1605 points

    Hi Tiger,

    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.

    Best Regards,
    Charlie