• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 1401 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Echo Cancellation not working via HPI but working via JTAG.

Suresh Bijjam
Prodigy 70 points

Hi all,

I am using DDR cacheable memory to provide buffer for ECU in my system level echo cancellation testing .
    It has been observed that the echo cancellation is working fine when the code is loaded into DSP via JTAG, but while i boot the DSP through HPI i am getting zero in sout buffer for whatever data i give to ecusendin function.
    Am i missing some thing with respect to JTAG, HPI , DDR and ECU library. Is there any dependency ?

After the above observations i have shifted ECU Buffers in DDR to L2 and loaded the code via HPI.
    Then Echo was getting cancelled with regular test files i.e rin and sin are pumped into DSP via ethernet.
    After some time i gave a different file for echo cancellation to see that the co-efficient and delay between rin and sin get changed.
    Then once again i have given the rin and sin files to DSP to see if this is able to adapt for run-time changes in delay between sin and rin but this test case failed.

After above observation i have loaded the same code via JTAG.
    All the above test cases were performed  and it passed all the test cases.


Summary:  The observation is code loaded via JTAG is working properly but when DSP is booted via HPI the test cases Fail.
                    From my observation i feel that the is some problem while loading ECU code via HPI.
                    Please suggest a solution for the same. 

  • 0
    TI__Guru* 81335 points
    Hi Suresh,
    I am not expert on ECU lib. From the above issue description, i suspect there may be dependency with DDR which causes this issue.

    While loading the code via JTAG, the gel file is used for initialize the DSP that includes pll, clock and ddr etc., Please ensure to do the same initialization before the loading the ECU code via HPI.

    Thank you.
  • 0 in reply to Raja
    Prodigy 70 points

    Hi Raja,

    We are not using any GEL file for loading code via JTAG.

    We are doing the initialization for pll, clock and ddr in the code itself in core0.
    As we are doing all the initialization with in the code and same binary is used for JTAG and HPI booting the observations should not be different.
    I think there is some unknown parameter that gets changed while loading code via HPI  and that does not change while we load through JTAG, we are still unclear what it is.

  • 0 in reply to Suresh Bijjam
    TI__Mastermind 43296 points
    Suresh,

    >>After the above observations i have shifted ECU Buffers in DDR to L2 and loaded the code via HPI.
    >>Then Echo was getting cancelled with regular test files i.e rin and sin are pumped into DSP via ethernet.
    Was the code loaded from HPI in the test case? And what's the Volib/ECU version and DSP type?

    >> After some time i gave a different file for echo cancellation to see that the co-efficient and delay between rin and sin get changed.
    So you observed ECU stop working after injecting different file which may have no any correlation with previous rin/sin files?
    Are the files, i.e. PCM samples still sent in from ethernet port?

    Instead of switching to a different file (rin2/sin2), if you combine the two files (rin+rin2/sin+sin2) to one, do you see ECU still works?

    ECU has no dependance on JTAG/HPI. And if you are able to get ECU work with HPI with first rin/sin set, it's more likely the PCM samples are not provided to ECU properly after you switch files. You may need capture the rout/sout to find out when the sout starts to become zero.

    Did you verify your PCM driver with ECU disabled? Are you able to consistently get correct data from Ethernet port with the code loaded via HPI?

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Prodigy 70 points
    Hi Garret,

    >> >>After the above observations i have shifted ECU Buffers in DDR to L2 and loaded the code via HPI.
    >> >>Then Echo was getting cancelled with regular test files i.e rin and sin are pumped into DSP via ethernet.
    >> Was the code loaded from HPI in the test case? And what's the Volib/ECU version and DSP type?

    Yes, code was loaded using HPI in this case.
    Voclib version -> volib_C64P_2_1_0_1
    DSP type -> TMS320TCI6486

    >> >> After some time i gave a different file for echo cancellation to see that the co-efficient and delay between rin and sin get changed.
    >> So you observed ECU stop working after injecting different file which may have no any correlation with previous rin/sin files?
    >> Are the files, i.e. PCM samples still sent in from ethernet port?

    Yes.

    >> Instead of switching to a different file (rin2/sin2), if you combine the two files (rin+rin2/sin+sin2) to one, do you see ECU still works?

    This i did not test. But if i test with original rin and sin after sending rin2, sin2 the Echo was not getting cancelled.

    >> ECU has no dependance on JTAG/HPI. And if you are able to get ECU work with HPI with first rin/sin set, it's more likely the PCM samples are not provided to ECU properly after you switch files. You may need capture the rout/sout to find out when the sout starts to become zero.

    >> Did you verify your PCM driver with ECU disabled? Are you able to consistently get correct data from Ethernet port with the code loaded via HPI?

    Yes. The code was working fine when ECU is disabled.
    I am getting correct data from Ethernet port.

    Regards,
    Suresh Bijjam.
  • 0 in reply to Suresh Bijjam
    TI__Mastermind 43296 points

    Suresh,

    When you test with original rin and sin after sending rin2, sin2, the echo path actually has been changed and the internal adaptive filter will retrain and update coeffcients. You may capture the composed rin+rin2/sin+sin2 and aligned rout+rout2/sout+sout2, so we can look into the tail length, echo path etc...to understand what should be expected result. Also, you can run test with simulation code in the VoLIB to check if it matches your real-time output with the same rin+rin2/sin+sin2 samples.

    Regards,Garrett