Increasing the clock speed on the C6748 EVM

> However, it still does not work

Please give details as what does not work.  Can you connect to the DSP via the emulator?  Can you read the external memory?  I moved from 300 MHz to 375 MHz on a C6747 DSP and I had no issues.  If you are using external memory you have to make sure the clock dividers are correct.  I had to modify mine as my clocks to the sdram were (300*2)/4.5=133 MHz and after the move to 375 I had to do 375/3=125 MHz.  Note at no time can you clocks go over 600 MHz.

Look here

http://processors.wiki.ti.com/index.php/Programming_PLL_Controllers_on_OMAP-L1x8/C674x/AM18xx

Regards,

Fawad

Okay, so far I figured out that the clock frequency should be changed in the following places:

- GEL file

- soc_C6748.h --> #define CSL_SYSCLK_1_FREQ (line 1111)

- The platform being loaded in the TCF script should be the generic platform ("ti.platforms.generic"), since "ti.platforms.evm6748" configures the system for 300 MHz.. The generic platform should then be configured for the particular frequency.

Having applied these changes, I recompiled the UART and I2C PSP (v01.30.01) drivers for different clock frequencies (400 MHz and 450 MHz) and it worked just fine. However, I also want to use the Audio driver that came with PSP, which in turn use the McASP, I2C, AIC31 and EDMA LLD drivers. In the soc_C6748.h header file, the clock frequencies appear to have no influence on the McASP and AIC31 drivers and to my knowledge should also not affect the EDMA LLD driver. I found that the PSP Audio driver only works fine when the system is configured for the default 300 MHz clock frequency. For higher configured clock frequencies, it seems to get stuck somewhere in the McASP driver, yet I cannot figure out why.

Can someone please provide me with some insight into the problem?

Hi Fawad,

Thanks for your reply.

I played around with the spread sheet from the link you provided and configured my CPU clock to 432MHz, using this gel file: 4214.C6748.gel. I also recompiled the appropriate PSP drivers.

The spread sheet showed no violations for this configuration, yet my program still hangs. I can connect to the DSP via the emulator, but I'm not yet sure if I can read external memory.

Any ideas?

Regards

  Reinier

Hi Reinier,

Reinier Coetzer said:

For higher configured clock frequencies, it seems to get stuck somewhere in the McASP driver

Could you please mention where exactly it is getting hung in the mcasp driver? During device creation/open/submit?

After opening the channel(channel creation), try probing and check if the desired bit clock and sampling frequency is coming appropriately. What is the bit clock when the system is configured at 300MHz and 450MHz?

Best Regards,

Raghavendra

Reinier,

Does your code uses external memory?  Confirm you can run some other code at 450 MHz.  I wrote a very simple memory check for the external memory to confirm everything was fine running at the higher frequency.  if that works then do as Raghavendra suggests and you should be able to debug into the McASP code.  I have done so many times.

Regards,

fawad

Raghavendra,

I have tried a few other frequencies as well, including 360MHz and 384MHz, and at these frequencies the McASP works fine. I have configured the McASP to receive all the clocks, i.e. frame sync, bit clock and high frequency clock externally from the AIC3106 codec I'm using.

The problem seems to occur above 400MHz, and it occurs when I try to create the channel with a SIO_create() call; it never returns from this function. By stepping through the code of the McASP driver, the program hangs when the mcaspRegisterInt() function finishes (called from mcaspMdCreateChan() ). From what I gathered, the interrupts are registered here, and immediately occurs once mcaspRegisterInt() finishes.

Upon further investigation, it appears as though the program is never allowed to exit the ISR, mcaspIsrOutput(), and it receives a Mcasp_TX_CLK_FAIL interrupt. I have to investigate this in more detail, but at the moment I'm not sure why I get a Tx clock failure.

How does the PLL0 clocks affect the McASP? From the C6748 documentation, it appears as though only AUXCLK goes to the McASP, which is not configurable.

For PLL frequencies above 400 MHz, the UART and I2C peripherals work fine and I'm also able to succesfully read and write to the external DDR memory.

I'm slightly baffled here! Any ideas?

Regards

  Reinier

Reinier,

In the McASP driver, there is a check if the clock has stablised without any errors or not (Mcasp_localConfigXmtSection(..) func). Check if the clock is stabilised and if its returning successfully from that func. After its stabilised, then it proceeds further and registers the error interrupts. Generally, once stabilised you should not get a clock failure(since you are using the Codec as master). But,

If you refer the McASP User guide,  

'XCNT' depends on the McASP system clock (This is not the same as AUXCLK. The DSP uses SYSCLK2 as the McASP system clock - Read section 2.4.7.6.2 of User guide). And if this is not stable, you might get transmit clock error.

For experimental purpose, try running your application without enabling the "clK error" interrupt and check its behavior. This can be done by changing the ".xintctl" parameter of 'mcaspXmtSetup' in the application. Change its value to '0x00000003'.

Best Regards,

Raghavendra

Raghavendra,

Thank you for pointing me in the right direction.

I've been doing some fierce bug-hunting the last day or so, and I believe I have found a bug in the McASP driver of the PSP drivers (v01.30.01) . In mcasp.c in the Mcasp_localConfigXmtSection() function, there is the following piece of code:

        /* check if the clock has stablised without any errors                */
        while (retryCount-- > 0)
        {
            /* write to the XCLK FAIL register to clear the failure bit       */
            tempVal = (instHandle->hwInfo.regs)->XSTAT;

            (instHandle->hwInfo.regs)->XSTAT = tempVal;

            TSK_sleep(10);

            /* verify if the clock failure is detected. if not detected then  *
             * we can retry else we can continue with the intialisation       */
            if (Mcasp_TX_CLK_FAIL !=
                ((instHandle->hwInfo.regs)->XSTAT & Mcasp_TX_CLK_FAIL))
            {
                break;
            }
        }

        if (0x00 == retryCount)
        {
            /* setting the clock failure interrupt failed                     */
            status = IOM_EBADARGS;
        }

If the maximum number of retries have been reached, i.e. retryCount reaches zero, the check will be performed in "while (retryCount-- > 0)", and the while() loop will indeed finish. However, retryCount is again decremented and is now 0xFFFFFFFF, instead of remaining zero. The implication is that "if (0x00 == retryCount)" can never become true and the function will never raise the error and the driver will happily continue and then silently die without warning. The possible solution is to only decrement retryCount inside of the while() loop.

Once I fixed this in the driver, I found that the channel creation [(SIO_create()] failed because of the clock failure interrupt not being successfully cleared. In turn I played around with a few values for XMAX and XMIN, which eventually allowed the clock to become stable and my program now works for higher frequencies above 400 MHz.

This bug is also present in Mcasp_localConfigRcvSection().

Even if this bug was not present, its quite a subtle problem to sort out and I believe the documentation is not clear enough about this, especially considering the vast amount of possible configurations for the McASP.

Anyways, I hope this helps someone in the future somewhere.

Regards

  Reinier

Raghavendra,

I also have another question/observation: Why is XMAX and XMIN set according to XCNT in the Mcasp_localConfigXmtSection() function?

In this function XCNT is read from XCLKCHK and then XMAX is set to XCNT + 3 and XMIN is set to XCNT - 3. The implication is that it does not matter what you set XMAX and XMIN to in your Mcasp_HwSetupData structure, since it won't be used in any case. I guess there was a specific reason for doing it in this way, but I believe it would be useful if there was some define in a header file that could be used to tweak this setting.

Regards

  Reinier

Thanks for extensive post on how to get McASP working with higher DSP clock rate.
The erroneous code is still present in the McASP driver in PDK L138!
XMAX and XMIN values need to be adjusted to max values for clock to stabilize @DSP clk rate greater than 400Mhz