MCBSP SPI Operation Using Clock Stope Mode

Hello Iain,

The User Guide, SPRUGJ6, should be used if you are using OMAP-L138 or C6748 device and you are correct that the Clock Stop mode on OMAP-L138/C6748 McBSP is not supported. But there are two SPIs on these two devices that you can use can use to do just what you need. Please refer to the OMAP-L138 DM (SPRS586) or C6748 DM (SPRS590), section 5.17 for some information on how to use the SPI module. For more details, please refer to the SPI UG (SPRUFM4I) for OMAP-L138.

Hope this helps.

Thanks,

Tai Nguyen   

Hello Tai,

Thanks for that information.

Unfortunately there is only one SPI available on my hardware, SPI1, because SPI0 pins are taken up with something else.

I already have other devices connected to this port and am concerned with the loading.

Also I am having problems with using DMA control to transmit >16 bits of data on SPI(see my other BIOS thread).

I have access to an FPGA and, if there is no way of configuring the DSP to provided this SSI interface, I am thinking of passing the McBSP clock and frame sync through the FPGA and stopping the clock within it. Will the McBSP have any problems with reading the received data coming in 32 cycle bursts in this mode?

Regards Iain

Hello Iain,

Yes, the McBSP will have a problem to receive the data if the clock is stopped within it. In the non CLOCK STOP mode, the McBSP needs a few clocks to copy the shifted-in- received data from receive shift register (RSR) to the data receive register (DRR). So if the clock is stopped you will not see the data getting in the DRR, but eventually it will get copied into the DRR if the clock is running again on the next data reception. If you are in the CLOCK STOP mode, after the clock is stopped, the McBSP will turn on the internal clock to copy the shifted receive data in the RSR into the DRR.

Regarding to the concern with the loading, please note that you will have 6mA on these IOs. It should be able to handle many devices. I think.  

Thanks and regards,

Tai 

Hello Tai,

Thanks for your suggestions, we are looking at continuously clocking the McBSP to solve the interface problem. Iain is actually now on leave now until the 28th June but will be picking this up again as soon as he returns and will let you know the results.

Thanks

John

Tai,

I'm having somewhat of a similar problem using the MCBSP in slave mode and not using a continuous external clock.  The linux kernel build we're using does not support CLOCK STOP mode.  What sort of symptoms would we see if not using CLOCK STOP mode?  I guess what I'm also asking, will the behavior of the MCBSP be undefined?

Al

Al,

You are correct. The behavior of the McBSP, and EDMA if it is used, would be underfined since the data are not transmitted/received at a proper time.   

Thanks,

Tai

Thanks, Tai.

We've been able to successfully get data across the MCBSP channel from our FPGA using a non-continuous clock but we did find that additional clocks before AND after the valid data frame were necessary (in our case, we used 64 clocks on both sides).  Further testing to verify this approach will need to be carried out, however, to ensure no spurious errors occur.

Al