• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 561 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.

How to recover MCASP when RSYNCERR was set?

user6000372
Intellectual 560 points


Hi, expert,

Our project is based on DRA78x, MCASP is configurated as slave mode, which use externel bit clock and sync signal,sometimes the RSYNCERR of register MCASP_RXSTAT is set, so dra78x can't receive any pcm data. how to recover MCASP works quickly? clear the RSYNCERR or Reset MCASP?

Best Regards,

Raul

  • 0
    TI__Mastermind 19880 points

    Hi Raul,

    I would like to recommend two things:

    1. Try to analize where the failure comes from. With a scope or logic analizer, see if the frame sync comes too early or too slow. Is this due to the external transmitter, or because the PCB traces are too long, too much inductance, capacitance, etc. The point is, even you recover from the error, you will continue to get the error if an issue in the hardware exists.

    2. Check the TRM chapter for MCASP. It covers pretty much of the MCASP hardware and has some low-level driver examples

    Regarding your question about RSYNCERR, what I understand from TRM is: MCASP flags the error condition to software, and MCASP will try to resynchronize at the next frame. Software must clear RSYNCERR (and  the interrupt condition, if enabled).

    Please refer to Unexpected Frame Sync Error in TRM.

    Regards,

    Stan

  • 0 in reply to Stanislav Stilyanov
    Intellectual 560 points

    Hi Stan,

    Many thank you.

    I think mcasp low level driver doen't clear RSYNCERR bit if dma mode is used,because when this issue occurs,mcaspIsr can't run.

    Please help to check, how to runs the function.

    Best Regards.

    Raul

  • 0 in reply to user6000372
    Intellectual 560 points

    Hi Stan,

    Our software is based on ti-processor-sdk-rtos-automotive-dra7xx-evm-04.03.00.05. we run the mcasp example on DSP1.

    If BUFLEN is 512,the bit "RSYNCERR" is set sometimes, if BUFLEN is 128,the bit "RSYNCERR" is set everytime, I think it may be software issue,not hardware issue.

    Could you give me any suggestion?

    Best Regards,

    Raul

  • 0 in reply to user6000372
    TI__Expert 8940 points

    Hi, Stan:

    Let me clear the current status.

    According to TRM, when there is a "RSYNCERR" happened, software needs to clear this bit in the interrupt routine.

    Customer will investigate the cause to "RSYNCERR". But at the same time, customer needs to implement such interrupt routine to recover from "RSYNERR" state.

    The problem is that when the "RSYNCERR" happens, it seems the McASP interrupt routine isn't triggered.

    We would like to get your guidance on the checklist for this problem.

    Please kindly advise.

    Thanks.

  • 0 in reply to Peter Li79
    TI__Mastermind 19880 points

    I'm sorry, I din't receive the email notifications for some reason.

    I will check and get back.

  • 0 in reply to Stanislav Stilyanov
    TI__Genius 9295 points

    Peter,

    If McASP ISR isn't running after unexpected frame sync error, please double check if MCASP_EVTCTLR[1] RSYNCERR and MCASP_EVTCTLX[1] XSYNCERR bits are set.

  • 0 in reply to Misael Lopez Cruz
    Intellectual 560 points

    Hi,

    When issue occurs,I checked above register, MCASP_EVTCTLR[1] RSYNCERR and MCASP_EVTCTLX[1] XSYNCERR bits are set 1.

    This issue occurs on MCASP3, and dsp local DMA is used.

    How to config rxMuxOutEvent and cpuRxEventNumber ?

    /* McASP2 Receive Event                                                       */

    #define CSL_DSP1_EDMA3_CHA_MCASP2_RX             18

    /* McASP2 Transmit Event                                                      */
    #define CSL_DSP1_EDMA3_CHA_MCASP2_TX             19

        hwInfo.rxDmaEventNumber = CSL_DSP1_EDMA3_CHA_MCASP2_RX;
        hwInfo.txDmaEventNumber = CSL_DSP1_EDMA3_CHA_MCASP2_TX;

         hwInfo.txMuxOutEvent=CSL_XBAR_INST_DSP1_IRQ_87;
         hwInfo.rxMuxOutEvent=CSL_XBAR_INST_DSP1_IRQ_86;
         /* The CPU event numbers corresponding to the above  */
         hwInfo.cpuTxEventNumber = 87;
         hwInfo.cpuRxEventNumber = 86;

    Thanks,

  • 0 in reply to user6000372
    TI__Genius 9295 points

    The configuration seems correct. I'm assuming that hwInfo was obtained using Mcasp_socGetInitCfg() with index of 2 (MCASP3). Could you confirm if you have also set hwInfo.muxNum? It must be set according to the IRQ crossbar for the core running your application:

    #define MUXINTCP_CROSSBAR_MUXNUM_DSP1 (0)
    #define MUXINTCP_CROSSBAR_MUXNUM_DSP2 (1)
    #define MUXINTCP_CROSSBAR_MUXNUM_IPU1 (2)
    #define MUXINTCP_CROSSBAR_MUXNUM_IPU2 (3)
    #define MUXINTCP_CROSSBAR_MUXNUM_MPU (4)

  • 0 in reply to Misael Lopez Cruz
    Intellectual 560 points

    Yes, I also set hwInfo.muxNum, but it can't work.

     hwInfo.muxNum=MUXINTCP_CROSSBAR_MUXNUM_DSP1; /* We use DSP1 for this demo */

  • 0 in reply to user6000372
    TI__Expert 5725 points

    Hi,

    In addition to your configuration, I just want to confirm that you are setting (or leaving default from mcasp_soc.c):

    • hwInfo.txMuxInEvent/hwInfo.rxMuxInEvent
    • hwInfo.txIntNum/hwInfo.rxIntNum

    Since you are using the correct hard-coded interrupt XBAR mapping and have confirmed that MCASP_EVTCTLR/MCASP_EVTCTLX bits are set to enable frame sync error interrupt, then I believe the above is the only other thing which would prevent interrupts triggering upon the error

    Are you able to set a breakpoint at the mcaspIsr symbol to see if the interrupt routine runs and you can hit this?

    Thanks,
    Stephen