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.

C6727 McASP re-initialization

I am using the McASP to receive 16 audio channels (4 channels per serializer on 4 serializers) with an external clock and frame sync.  Programming is done using CSL with code initially derived from the Lyrtech PADK examples.  The received data is sent to buffers via the dMAX peripheral.  Everything works perfectly on startup.  But in my target environment, at some point, the external clock and frame sync stop for a period of time (i.e. seconds or minutes).  The DSP code is alerted via I2C to when this is going to happen.  So it shuts down the McASP and disables events and clears TCCs on the dMAX.  This could occur at any time during a McASP frame and dMAX transfer.  Eventually the code is told via I2C to start up its audio reception again.  The code allows for a change in clock rate at that point, but so far it has always remained at 48KHz.  The code then restarts the McASP and dMAX using the same McASP code that it initially used to start them on the first occurence.  My problem is that after the first session of audio processing which is always correct, the subsequent sessions are out of alignment 75% of the time.  Since there are 16 channels, it ends up being off by 0, 4, 8, or 12 channels in the dMAX receive buffer.  It seems to be random. 

To turn off the McASP and dMAX, I use the following CSL functions:

    CSL_mcaspHwControl( hMcasp1, CSL_MCASP_CMD_REG_RESET, NULL );

    CSL_mcaspRegReset( hMcasp1);

    CSL_dmaxHwControl( hDmaxAdc, CSL_DMAX_CMD_EVENTDISABLE, NULL );

    CSL_dmaxHwControl( hDmaxAdc, CSL_DMAX_CMD_CLEARTCC, NULL );

My code exactly follows the PADK example on initializing audio data.  And it also conforms to the initialization steps outlined in the McASP reference guide.

Is there any setting of McASP or dMAX registers that needs to be performed on reinitialization that does not need to be performed initially? 

Or perhaps there are dMAX registers that also need modifying after they've been used?  On reinitialization, the only dMAX call I make is:

   CSL_dmaxHwControl( hDmaxAdc, CSL_DMAX_CMD_EVENTENABLE, NULL );

Perhaps I need to write the "Active" values (1st 3 words) of the dMAX Transfer Entry Table myself?  But I believe that I already tried that once, but it did not help.

  • Hi, Craig,

     

    I found a bug in the (old) drivers several years ago when we built a system around a da707 (c672x).  Here is a section from my notes at that time, 2006.  Perhaps it will help:

     

    BUG REPORT:
    ===========
    It was found that the driver appears not to reset all the device registers during init.
    While this may not be a problem when starting from a cold boot, this did cause a bit of
    difficulty during debug on a warm system.  The troublesome spot occurs when the serializer
    control regs are not reset to zero.  I would suggest a sequence of calls like
    this, in DMD_init()  (called before main() to initialize the DMD device), or perhaps
    the authors could identify a better place.

        CSL_McaspHandle hMcasp;
        CSL_McaspObj    mcaspObj;
        CSL_Status        status;

        ...
        ...
        ...

        // CP 1/9/2006
        // Reset all McASP regs for all McASP devices
        hMcasp = CSL_mcaspOpen( &mcaspObj,
                                CSL_MCASP_0, NULL, &status);
        CSL_mcaspRegReset(hMcasp);
        CSL_mcaspClose(hMcasp);

        hMcasp = CSL_mcaspOpen( &mcaspObj,
                                CSL_MCASP_1, NULL, &status);
        CSL_mcaspRegReset(hMcasp);
        CSL_mcaspClose(hMcasp);
        hMcasp = CSL_mcaspOpen( &mcaspObj,
                                CSL_MCASP_2, NULL, &status);
        CSL_mcaspRegReset(hMcasp);
        CSL_mcaspClose(hMcasp);

    Best Regards,

    Cameron

  • I appreciate you looking at the issue.  Since my code already calls CSL_mcaspRegReset(hMcasp) before a warm start, that appears not to be the issue here.  But perhaps it is necessary to wait for the value of GBLCTL to be 0 in CSL_mcaspRegReset()?  I believe that it is the only time that CSL sets that register without waiting to check that the value has been set before continuing.  I will try that out next week when I have access to the target hardware again.  But since my code usually doesn't touch the GBLCTL register for many seconds after it has been cleared, that is not likely to be the problem.

    My guess is that there is some issue with the dMAX peripheral that also needs special handling on a warm start.  The dMAX document doesn't get very deep into issues like that.

    Craig