28x McBSP Clock Generation

John -

This requirement is applicable to 281x also (see page 1-14/ pg28 of spru061c - 281x).  There are some subtle differences between the 2833x McBSP and 281x McBSP, mostly around the fact that there is no FIFO support on the 2833x McBSP - so if your 281x code enabled any logic around the FIFO, it will not work on the 2833x. The 2833x instead interfaces the McBSP to the DMA module. Specifically, MFFTX, MFFRX, MFFST, and MFFCT registers do not exist on the 2833x. Additionally, the MFFINT XEVTA and REVTA interrupt enable bits do not exist on the 2833x devices.

Hope this helps.

Hi Chrissy,

Thanks for your response. There is a subtle difference between the requirement I pasted from the 2833x manual and the one you point out in the 281x manual. Specifically, the 281x note states that "The McBSP cannot operate at a frequency faster than 1/2 the LSPCLK frequency." The 2833x manual has this same requirement on page 23 of SPRUFB7a, but on page 32 it also states that "The McBSP cannot operate at a frequency faster than 1/2 the source clock frequency." It is this latter note that is missing from the 281x manual.

The crucial difference here is the words 'source clock' as opposed to 'LSPCLK'. In my application, the source clock for my transmit clock generator is the clock that appears on the CLKR pin. While the transmit frequency I desire is less than half LSPCLK, it is the same as the CLKR frequency, i.e. the source clock. The application in 281x has worked fine in this way for a number of years - but after porting to 2833x it works no more, the generated clock is of poor quality, the frequency and mark to space ratio are not constant. I have got around the problem by using the LSPCLK as the source with the appropriate divide down and it all works again - but, sadly, I have now lost the link between incoming and outgoing clocks which means that my system is less efficient and less automatic than it used to be.

I appreciate the changes regardling the FIFO and the DMA, I had to make these changes when I did the port from 2812 to 28335. However, I do not see how these changes have a bearing on the clock generation logic - I think that there must have been a subtle change there too.

Cheers,

John.

John:

I checked with the design team, and there are no changes in the design with regard to the clocking logic in the McBSP between 2833x and 281x. The LSPCLK was also optimized to 75 Mhz same as on the 281x devices.

One of the engineers on the team checked out the following configuration and the CLKX looked fine when scoped..  Is the below the same configuration that you have?

1.      CLKR as the input source clock to SRG.

2.       CLKX transmit clock is < 1/2 x LSPCLK, but the CLKX frequency is the same as the CLKR frequency.

Hi Chrissy,

Thanks for your response. Yes, that is the configuration of my working 2812 application. If I configure the 28335 like this it does not work. I can send you the code that configures the port if you think this would be useful? I also have oscilloscope screen shots of the resulting transmit clock from a 28335 if that will help.

The LSPCLK is 75MHz and CLKR (and therefore CLKX) is 30MHz. Since 30MHz is an odd multiple of the 150MHz main clock I see an uneven mark/space ratio (2:3) which is expected. With the 2812, this is a stable clock signal, With the 28335 though, the ratio flips between 2:3 and 3:2 meaning that the clock edges jitter. This sometimes leads to a clock edge being mistimed with the data and results in bad data being received.

If there are no changes to the McBSP logic itself, could this behaviour be down to some difference in the input/output buffering of the i/o lines? Or the GPIO mux logic?

Cheers,

John.