• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 849 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.

C6745 McASP Driver To AIC3007 Codec Lock Up Issue

Dennis Nguyen
Expert 1690 points

Hi,

We used the C6747 starter kits with AIC3106 codec, CCS v3.3, BIOS 5.33.05, PSP 1.30.01 and we were able to have our application sample and playing audio wave files successfully.  We moved to our C6745 and AIC3007 codec and we resolved all the issues except this start up issue.  We pinpoint the issue down (through audioMdCreateChan() and aic31CreateChan()) to McASP.C Mcasp_localActivateSmFsForXmt() where:

mcaspBitSetGblXCtl(instHandle, CSL_MCASP_XGBLCTL_XSMRST_MASK);

did not return.

When I load my application through CCS v3.3 JTAG, the first run start will have the lock up.  However from CCS v3.3, I could restart the DSP (Debug->Restart) and run again then McASP is happy.  The problem is my application has to boot from the bootloader.  I can not restart the DSP unless from a cold boot with power on.

Please advice on what could be the root cause.

Here is my trace from UART that we dumped out before the application locked:

9:14:22.097> audioMdCreateChan
9:14:22.097> aic31MdCreateChan
9:14:22.097> << 0 0 1 // I2C write (<<) codec register, value, count
9:14:22.097> << 1 80 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 8 0 1
9:14:22.097> << 8 c0 1
9:14:22.097> << 9 40 1
9:14:22.097> aic31SetSamplingRate
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 2 0 1
9:14:22.097> << 2 6 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 7 0 1 // I2C read (>>) codec register, value, count
9:14:22.097> << 7 0 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 3 0 1
9:14:22.097> << 3 90 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 66 0 1
9:14:22.097> << 66 2 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 65 0 1
9:14:22.097> << 65 0 1
9:14:22.097> << 62 20 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 3 0 1
9:14:22.097> << 3 92 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 4 0 1
9:14:22.097> << 4 1c 1
9:14:22.097> << 5 52 1
9:14:22.097> << 6 80 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> b 0 1
9:14:22.097> << b 1 1
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 7 0 1
9:14:22.097> << 7 80 1
9:14:22.097> aic31SetSamplingRate 0
9:14:22.097> aic31InitDac
9:14:22.097> aic31RegWriteBf
9:14:22.097> >> 7 0 1
9:14:22.097> << 7 8a 1
9:14:22.097> << 25 e0 1
9:14:22.097> << 26 6 1
9:14:22.097> << 29 42 1
9:14:22.097> << 49 8 1
9:14:22.097> << 2a 6c 1
9:14:22.097> << 2b 0 1
9:14:22.097> << 2c 0 1
9:14:22.097> << 2f 80 1
9:14:22.097> << 33 9 1
9:14:22.097> << 40 80 1
9:14:22.097> << 41 9 1
9:14:22.097> << 52 80 1
9:14:22.097> << 56 9 1
9:14:22.097> << 5c 80 1
9:14:22.097> << 5d 9 1
9:14:22.097> << 2c 0 1
9:14:22.097> channel creation is successful
9:14:22.097> aic31MdCreateChan done...
9:14:22.097> aic31MdControlChan
9:14:22.097>     cmd: 139
9:14:22.097> GET_CODEC_INFO retVal: 0
9:14:22.097> DEV_match...
9:14:22.097> mdCreateChan...
9:14:27.222> mcaspMdCreateChan begin
9:14:27.222> calling mcaspInit
9:14:27.222> channelMode 0
9:14:27.222> isDataPacked 1
9:14:27.222> mcaspConfigureFifo
9:14:27.222> IOM_OUTPUT
9:14:27.222> AFSXCTL
9:14:27.222> CALLING mcaspRegisterInt // This the last trace before calling Mcasp_localActivateSmFsForXmt()

Thanks,

Dennis

  • 0
    Expert 1690 points

    I added more debug trace and here is what I got:

    Mcasp_localActivateSmFsForXmt function activates the transmit section state machine and the corresponding frame sync.  When this function starts the Serializer, State M/C and Frame Sync Generator.  It calls mcaspBitSetGblXCtl as the followings:

    Void Mcasp_localActivateSmFsForXmt(Mcasp_Object *instHandle)
    {
        assert(NULL != instHandle);

        (instHandle->hwInfo.regs)->XSTAT = (CSL_MCASP_XSTAT_XERR_MASK
                                           | CSL_MCASP_XSTAT_XDMAERR_MASK
                                           | CSL_MCASP_XSTAT_XSTAFRM_MASK
                                           | CSL_MCASP_XSTAT_XDATA_MASK
                                           | CSL_MCASP_XSTAT_XLAST_MASK
                                           | CSL_MCASP_XSTAT_XTDMSLOT_MASK
                                           | CSL_MCASP_XSTAT_XCKFAIL_MASK
                                           | CSL_MCASP_XSTAT_XSYNCERR_MASK
                                           | CSL_MCASP_XSTAT_XUNDRN_MASK);

        /*Start the Serializer, State M/C and Frame Sync Generator                */
        mcaspBitSetGblXCtl(instHandle, CSL_MCASP_XGBLCTL_XSRCLR_MASK);
        mcaspBitSetGblXCtl(instHandle, CSL_MCASP_XGBLCTL_XSMRST_MASK);
        mcaspBitSetGblXCtl(instHandle, CSL_MCASP_XGBLCTL_XFRST_MASK);
    }

    The DSP was stuck when XGBLCTL register set to bitMaskVal of CSL_MCASP_XGBLCTL_XSMRST_MASK 0x800.

    static 

    Void mcaspBitSetGblXCtl(Mcasp_Object *instHandle, Uint32 bitMaskVal)
    {
            Uint32 timeout = 1000u;
            Bool   isTask  = FALSE;

            assert(NULL != instHandle);

            DebugPrintf( "SetGblXCtl 0x%x 0x%x\n", (instHandle->hwInfo.regs)->GBLCTL, bitMaskVal );

            /* If already this bit is set then don't set again                        */
            if (((instHandle->hwInfo.regs)->GBLCTL & bitMaskVal) != bitMaskVal)
            {
                if (FALSE == instHandle->XmtObj.isDmaDriven)
                {
                    ECM_disableEvent(instHandle->XmtObj.cpuEventNum);
                }

                DebugPrintf( "isDmaDriven %d\n", instHandle->XmtObj.isDmaDriven );
                (instHandle->hwInfo.regs)->XGBLCTL =
                    ((instHandle->hwInfo.regs)->XGBLCTL | bitMaskVal);


  • 0 in reply to Dennis Nguyen
    Expert 1690 points

    Hi,

    With all the debug traces, the actual question to TI is what cause the DSP hung when the driver order Transmitter Global Control Register (XGBLCTL) to release transmit state machine from reset.

    Thanks,

    Dennis

  • 0 in reply to Dennis Nguyen
    Expert 1690 points

    We made a mistake to use MCASP.C from PSP 1.20.0 for troubleshooting this issue.  We loaded the correct PSP 1.30.1 MCASP.C.  The start up code is hung at calling

                DebugPrintf("calling mcaspRegisterInt\n" );
                    mcaspRegisterInt(
                            chanHandle,
                            (Uint32)instHandle->instNum,
                            (Uint16)chanHandle->cpuEventNum,
                            (ECM_Fxn)&mcaspIsr);

    in mcaspMdCreateChan().

    Sorry for the confusion.

    Thanks,

    Dennis

  • 0 in reply to Dennis Nguyen
    TI__Guru* 84110 points

    Dennis Nguyen said:
    When I load my application through CCS v3.3 JTAG, the first run start will have the lock up.  However from CCS v3.3, I could restart the DSP (Debug->Restart) and run again then McASP is happy.  The problem is my application has to boot from the bootloader.

    This tells me that all the right program is there, somewhere, since there is a way to get the application to run correctly. At this level, we can see that there is something being initialized poorly or incorrectly, but it can be recovered and done correctly with the sequence you have described. The easiest solution will be, in my opinion, to figure out the right startup sequence rather than trying to delve deeply into a driver call.

    In CCS, when you connect JTAG and load a program and restart the program, GEL scripts will usually run. Are you using standard GEL scripts? Can you look at what exactly is running in each of the steps you take that will end up with the application working correctly?

    In the GEL file, the StartUp() function will run when CCS is initialized. Then OnTargetConnect() will run when you connect JTAG to the device, whether this is automated or manual. OnPreFileLoaded( ) runs just before loading the program via JTAG, and OnFileLoaded() will load just after the program is loaded, although this is not always implemented. OnRestart() will run when you do the Debug->Restart and OnReset() will run when you do the Debug->Reset.

    Whenever an application will work under JTAG loading conditions and will not work under cold boot or bootloader conditions, the most common problem is that some initialization that is done in the GEL file functions is not being done in the bootloader sequence. If these missing components can be identified and then added to the bootloader or secondary bootloader or the bootloaded application, then the problem may be solved.

    You have a bit more complicated situation in that you have found 2 steps required - load/run followed by Debug->Restart/run. So there may be a combination of steps that execute in the GEL file and in the application initialization that lead to the correct operation. But if we can identify these steps, then the application will work.

    The two main questions that need to be figured out are

    1. Which GEL operations are required but not implemented in the application code?
    2. Which application initialization must be repeated or done in a different order to get the correct operation?

    You are already good with breakpoints and debug, but I can add some suggestions if you are ready to go down this path.

  • 0 in reply to RandyP
    Expert 1690 points

    Thanks for the inputs, Randy.

    RandyP said:

    This tells me that all the right program is there, somewhere, since there is a way to get the application to run correctly. At this level, we can see that there is something being initialized poorly or incorrectly, but it can be recovered and done correctly with the sequence you have described. The easiest solution will be, in my opinion, to figure out the right startup sequence rather than trying to delve deeply into a driver call.

    I already spent a good amount of time on anylyzing the gel (and gel.c) but I could not find any discrepancy.  First without mcasp enable.  I was able to boot my application from bootloader successfully.  With mcasp enable, mcasp uses HW interrupt 8.  Looks like mcasp was hung right after enabling hwiNumber 8 and during restoring the interrupt (_restore_interrupts).  We are using the same hardware interrupt 8 with interrupt selection 1 and it is defined in the ECM configuration of TCF file.  As far as I understand, there is nothing in the gel/gel.c for the hardware interrupt.

    Because OnRestart() clears EDMA events and interrupts.  I also added Disable_EDMA() at the end of OnTargetConnect() but that didn't help either.  I will attach the gel.c file.

    Thanks,

    Dennis

  • 0 in reply to Dennis Nguyen
    TI__Guru 62975 points

    Dennis,

    Are you using external clocks for the McASP?  I've been told that in order to safely reset/initialize the McASP logic, the clocks need to be reverted back to internal clock sources to ensure proper reset clocking.

    Are you able to detect if an interrupt was generated for McASP?  Perhaps it's throwing an error code.

    -Tommy

  • 0 in reply to tlee
    Expert 1690 points

    Randy, Tommy,

    Thanks for your inputs.  While we troubleshoot the volume control for the codec, we messed up the device codec RESET line.  We fixed the RESET line and we are get our device boot up consistently now.

    With your helps, we were able to achieve our first milestone.  Thaks a lot for your supports. 

    Dennis Nguyen