OMAP-L138 McBSP Port SW Issue

Hi, Can you please provide us some more information regarding your setup? Like, BIOS PSP version used? EDMA version used? Are you using the sample application provided by the PSP package or any modification in the configuration(as per your reqirement) for the application? In case you are using PSP 1.30.01, installed all the tools as mentioned in the Userguide, and using the exact sample application provided by the PSP package, and still observing any issues, please make sure you follow all the steps mentioned in the section 15.16(Mcbsp Sample application) of the Userguide (OMAPL138_BIOSPSP_Userguide.pdf) placed in - pspdrivers_01_30_01\docs\OMAPL138. Because, the setup for McBSP is something like this: You need to connect two EVMs with the McBSP instance 1 on one EVM connected to the McBSP instance 1 on the other EVM. The sample on the slave side is loaded and executed first. Next the sample application on the master side is loaded and executed. Then the output will be observed on both the master and slave sides once the application has completed successfully. This might not be the solution to your question, but just wanted to make sure of certain things before jumping into any conclusion. :) Thanks & regards, Raghavendra

I am having very much the same problem as several other people have seen with the L138 , and the L137 when trying to use the psp drivers for the mcbsp.

 

For example, here is the exact same problem as I am seeing described on the TI forum just a few weeks ago. He too is seeing exactly what I am seeing

 

http://e2e.ti.com/support/embedded/f/355/t/98255.aspx

 

Unfortunately the engineer responded with an answer unrelated to his question.

 

This person and I also are only using one of the mcbsp's, i.e. mcbsp1, and TI for some reason responded with just a guess really, that maybe perhaps this is related to using both mcbsps at the same time. 

 

TI's forum answer was no help since neither this guy, nor myself are using two mcbsp's, we are using just the one.

 

So no one has successfully answered this question yet. 

 

I have only one MITYdsp dev board not two as you mention so I cannot run the full example with a master and a slave.

 

So I am trying to run just the psp example mcbsp Master example and am trying to run it stand alone without a slave on the the other board since I do not have another board as I already told you.

 

This should not be a problem, right ? The master example is just a transmitter and does not care if the slave is even there so should work , right ?

 

Anyways, to make a long story short, mcbspMaster example from the PSP does work if I set the example into INTERNAL clock mode so

 

Mcbsp_ClkSetup mcbspClkConfig =

{

    Mcbsp_FsClkMode_INTERNAL,

    Mcbsp_TxRxClkMode_INTERNAL,

};

With this setting above the system seems to work.
Now , if I take this exact same mcbsp master example code, and I do not change a single line except for one single thing only, which is:

 

 I change the clock inputs to EXTERNAL,

 

it hangs forever on the very first call to SIO_reclaim which is in the mcbspSampleMaster_io.c file, in the mcbspStartDemo() function .

 

 

 

/**< clock setup for the TX section */

Mcbsp_ClkSetup mcbspClkConfig =

{

    Mcbsp_FsClkMode_EXTERNAL,

    Mcbsp_TxRxClkMode_EXTERNAL,

};

 

I am providing the external clocks from a different device and Marc has verified the clocks are actually getting to the correct mcbsp1 clock pins.

 

You can reproduce this yourself by taking this code and providing an external clock and trying to get this driver to work yourself by just changing those few params.

  

I also rewrote everything from the beginning,  i.e I dumped the mcbsp psp example completely and did everything from scratch.

 

I manually programmed the individual mcbsp1 registers one by one to be exactly as I want them using the CSL, the low level chip support library.

 

The upshot is I now seem to be transmitting out the mcbsp1.

 

I am doing the tx without EDMA, mind you, by polling after each and every every transmitted word on the mcbsp tx ready bit.

 

The good news is that this seems to work, ( I think .....)

 

I know the clocks are getting to the L138 mcbsp pins because of the following:

When I remove the external clock sources the poll on tx ready bit hangs forever, but when I apply the external clock the poll on txready bit does not hang so I can proceed to tx another word flawlessly.

This test confirms the external clock is getting to the chip because, correct me if I am wrong, but if the clocks were maybe not getting to the L138 ( assuming I set the mcbsp PCR bits to use the external clock, which I did ) then the poll on tx ready would hang but it does not hang so therefore the clocks are A-OK.

 

Thus I conclude that the external clocks are okay, and also my settings of the mcbsp registers are also similarly okay,

 

The only problem is that I must have missed something in the psp when I tried to change the example mcbsp_master from INTERNAL to EXTERNAL.

 

The firmware architect wants me to use the mcbsp SIO driver rather than this manual word by word mcbsp polling method, so I would appreciate the help in fixing my psp driver. 

 

Hi,

As you have mentioned,

MT said:

I am trying to run just the psp example mcbsp Master example and am trying to run it stand alone without a slave on the the other board since I do not have another board as I already told you.

 This should not be a problem, right ? The master example is just a transmitter and does not care if the slave is even there so should work , right ?

Running McBSP sample app in master mode alone should not be a problem. It should work without the slave being connected since it(MASTER) is transmitting only.

After going through your query completely, it looks like the primary requirement of your setup is to use an external clock. And for this,  you need to follow certain things.

Referring to the (Figure 2. Clock and Frame Generation) of  McBSP User's Guide, the Sample rate generator is driven by either the internal clock source or CLKS(External Clock). With respect to your requirerment, you need to feed the external clock to this(CLKS) pin. So in the (mcbsbSampleMaster_main.c) file under mcbspUserInit() function, change the "srgInputClkMode" from Mcbsp_SrgClk_CLKCPU(which uses Mcbsp internal clock) to Mcbsp_SrgClk_CLKS(to use external clock) and then change the parameters srgFrmPulseWidth and srgrInputFreq of mcbspSrgParams appropriately depending on your requirement.

Since you are configuring the McBSP in MASTER mode, the FsClkMode(Framesync clock) and the TxRxClkMode should be INTERNAL. This is because, when it is said a MASTER, the master itself would/should generate the clocks(Frame sync and bit clock). Hence mcbspClkConfig should be,

Mcbsp_ClkSetup mcbspClkConfig =

{

    Mcbsp_FsClkMode_INTERNAL,

    Mcbsp_TxRxClkMode_INTERNAL,

};

Hope this answers your question and solves the issue..

 

Thanks & regards,

Raghavendra

I think I confused the issue with the use of the term master/slave.

 

I am using the "master" project example project but I am trying to configuring the mcbsp in "slave" mode in terms of the Frame and TxRx clocks.

 

The use of the word "master" in the TI example project name just refers to it being the one to transmit the packets as opposed to the matching so-called TI "slave" example project which receives the packets.

 

The confusion arises because these example project names "master" and "slave" have nothing at all to do with the master or slave configuration of the clocks.

 

This really was a very unfortunate of choice of names TI picked to call these examples.

 

TI should have called the so-called "master" project "transmitter" or "source" or something like that, and should have called the so-called 'slave project "recover " or sink" or something like that.

 

Because in reality both what TI calls the "master" and what they call the "slave" are both running default in master mode in terms of the clocks. IE both generate their own FsClk and TxRxClk.

 

In my case, I really do need to use the EXTERNAL FsClk and TxRxClk coming from a different device altogether so I do need to change the default code in mcbsbSampleMaster_main.c  to :

Mcbsp_ClkSetup mcbspClkConfig =

{

    Mcbsp_FsClkMode_EXTERNAL,

    Mcbsp_TxRxClkMode_EXTERNAL,

};

 Thanks,

 

Oh ok.. So in that case, I would like to suggest you one thing. Instead of using the "master" project example, use the "slave" project example. In the "slave" project example, do not make any changes in the configuration.

You will have to just change the "mcbspStartDemo(..)" function of mcbspSampleSlave_io.c to continuously write data rather than what it is doing now(read!!). You can do this modification by taking reference from the "mcbspStartDemo(..)" function of mcbspSampleMaster_io.c file. By doing so, you will be configuring McBSP in slave mode and also use external clocks.

Section 15.16.1.3 of OMAPL138_BIOSPSP_Userguide gives the setup information. Reffering this, On the slave side (For Ex: Instead of connecting CLKR1(17) to CLKX1(65)) just feed external clock to CLKR1(17). Basically, instead of taking clocks from MASTER(as done in SLAVE sample application) feed external clock. Similarly check for other pins and make sure you are providing the appropriate clocks.

Hope you understood what I meant.. Please try this and let me know the results. In the meanwhile, I will try to debug on this issue further.

Thanks & regards,

Raghavendra