• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 485 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.

Original question:

TMS320C6657: EDMA3 BUSERR with ERRDET.STAT=0x9

TMS320C6657: EDMA3 BUSERR

Koichiro Tashiro
Mastermind 22945 points

Part Number: TMS320C6657

Hi,

This is related question to the original thread.(see linked item above)
Customer did some more tests based on the feedback from the original post.

Here are some additional information.
a) There are three threads running in DSP. They are high priority, mid priority and low priority.
- Each thread is triggered by associated interrupt and each interrupt priority is also prioritized (high, mid and low).
- The high thread and the mid thread use EDMA and these EDMA cause the bus error.

b) The similar program has been used in previous product and it worked fine without any issues.
- The difference between the old program and the current program is amount of process handled by the high and the mid threads.
The new program handles much more processes in the high and the mid threads.
- Even the handled processes are increased, both the high and the mid threads finish these process before next interrupt comes.
So customer expects it should not be an issue.
- Customer tried to reduce amount of process handled by the high and the mid threads. The bus error disappeared.

c) EDMA destination addresses are calculated inside these threads.
Customer suspected address calculation failure may causes the bus error, so he tried to use the fixed addresses (no address calculation is made).
But the results were the same. The bus error still happened.

Any debug suggestions?

Thanks and regards,
Koichiro Tashiro

  • 0
    TI__Guru* 85925 points

    Tashiro-san 

    If the BUSERR value is the same as you indicated in your previous post, than the only way to get that error is if the EDMA TC is writing to illegal address in memory. 

    Can you share the "fixed" address values and have you confirmed that these are legal addresses in the memory map , including calculation for base address + transfer size address?

  • 0 in reply to Mukul Bhatnagar
    TI__Guru 56957 points

    Tashiro-san,

    As Mukul mentioned in the other thread.... The ERRSTAT.MMRAERR bitfield indicates that a reserved address inside the TC was read/written.  Can you confirm that this is a side effect of a CCS memory window being opened?  Or is this happening sometime during the application.  You should make sure this isn't somehow contributing to the problem.

    The ERRSTAT.BUSERR indicates that an error was reported back to the TC related to a read/write transaction (usually to an invalid address location).  

    ERRDET.STAT = 0x9 indicates a write addressing error.

    Can you also report back the ERRDET TCC TCINTEN and TCCHEN register settings?  You may be able to trace that back to the TCC code that is set in one of the PaRAM entries, or maybe even to the transactions in the TC FIFO registers.

    Regards,

    Kyle

  • 0 in reply to kcastille
    TI__Mastermind 22945 points

    Hi Mukul, Kyle,

    Customer checked below points, but so far no clues.

    kcastille said:
    Can you also report back the ERRDET TCC TCINTEN and TCCHEN register settings?  You may be able to trace that back to the TCC code that is set in one of the PaRAM entries, or maybe even to the transactions in the TC FIFO registers.

    Please clarify below point.
    Customer observes ERRSTAT.MMRAERR and ERRSTAT.BUSERR.
    This means;
    - EDMA Host (CPU) accesses invalid EDMA configuration register
    AND
    - EDMA TC accesses to invalid memory as SRC/DST
    So two different errors are detected. Correct?

    Or one error may trigger both bits?

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru 56957 points

    Tashiro-san,

    Clarification on your point for TC ERRSTAT.MMRAERR:
    - EDMA Host (CPU) or CCS via Memory Window accesses invalid EDMA configuration register.

    My guess is that they are accidentally triggering the MMRAERR by opening a memory window which may touch reserved locations.

    Yes, these signify two different errors as you summarized and cannot be triggered by one error only.

    Regards,

    Kyle

  • 0 in reply to kcastille
    TI__Mastermind 22945 points

    Hi Kyle, Mukul,

    I had a call with customer and got more detailed information about the issue.

    - There are 4TCs used and they are triggered by below three periodical interrupts.
    TC0 and TC3: 48kHz cycle
    TC1: 12kHz cycle
    TC2: 6kHz cycle

    - The system works fine in normal operation. The issue happens only after one of fault injection tests.
    The test is below:
    Inside 48kHz interrupt ISR, the code is put in loop and EDMA transfer is stopped on purpose.
    This mimics unexpected EDMA transfer hold. => EMDA hold is detected by an external FPGA and notified to an operator.
    Then the system is manually power-off and power-on again for recovery.
    After the system is power-on, the issue (EDMA causes bus error) happens often (not always).
    If the issue happens, the system needs to be power-off and power-on again. It may be recovered with only one power cycle, but sometimes more than a few dozen of power cycles are needed.
    Customer also tried to keep power-off period longer (1 day maximum), but the issue persisted after power-on at that time.

    - While the power is off, all power rails are completely 0V for C6657 and other components on the board are also off.
    Only an external SRAM contents are retained by backup capacitor.
    These SRAM contents will be used after power-on. So customer tried not to use these parameters in SRAM, instead fixed values are used.
    Still the issue is observed.

    - At device power-up, the initialization code checks whether the boot is from scratch or reboot from a failure.
    In case the reboot from a failure, some initialization steps are skipped. These steps are the same for all kinds of failures.
    Customer does some fault injection tests. Only the test explained above causes the issue.

    - Regarding EDMA bus error, the channel causes the error varies each time. DRRDET values are not always the same.

    - Customer tried to use only 48kHz cycle interrupt to trigger all TCs. In this scenario, no issue is observed so far.

    - Customer tried to reduce CPU load (processing not related to EDMA transfer). In this case, no issue is observed so far.

    I suspect some non-volatile settings remain inside C6657 and it cause the issue.
    But I do not have any idea exactly what it is.

    Thanks and regards,
    Koichiro Tashiro

  • 0 in reply to Koichiro Tashiro
    TI__Guru 56957 points

    Tashiro-san,

    I don't believe there is any non-volatile information in the SoC that can survive a day long power off cycle.  I would suspect that there is some important difference in the boot from scratch (always pass) vs boot from failure (sometimes fails) software initialization.

    Regards,

    Kyle