Communication between two 28069 through McBSP

Fei,

If you have not changed any of the configuration, the McBSPs should be able to communicate. Have you put an oscilloscope on the pins? Have you looked at the single ended operation of the McBSP? If you disconnect DSP1 McBSP, are you able to see any data being transmitted? likewise for DSP2.

McBSP can be thought of as having an independent transmitter and receiver since each TX and RX have their own CLK and Frame Sync. In the Loopback example, the transmitter is generating the clock (CLKX is output) and the receiver is receiving the clock (CLKR is input). If you want DSP1 to read data from DSP2, while having DSP1 control the communication, you can have DSP2 CLKX be an input and DSP1 CLKR be an output. This is just one suggestion of how to do this.

As you can see by reading the TRM chapter, the McBSP is highly configurable. If you can provide more details on what exactly is going on and what you have tried so far, I can be a little more specific in my response.

Thanks,
Mark

Hi Mark,

Thanks for your reply.

I disconnect DSP1 and DSP2 and use scope to observe the data transmitted. Data transmission is perfect. I can see the data pattern on scope which matches the data I want to send. The problem is when I connect them with the above HW configuration, I can not receive any data.

The following is my steps. I want to get the simple case working first, where DSP1 is master, DSP2 is slave.
1. On DSP 1, I modify a little bit on the loop back example:
for(;;)
{
mcbsp_xmit(sdata1,sdata2);
//sdata1++;
//sdata2--;

//while(McbspaRegs.SPCR1.bit.RRDY == 0 ) { } // Check for receive
//rdata2 = McbspaRegs.DRR2.all;
//rdata1 = McbspaRegs.DRR1.all;
//if(rdata1 != rdata1_point) error();
//if(rdata2 != rdata2_point) error();
rdata1_point++;
rdata2_point--;

__asm(" nop");
}
2. On DSP 1, I disable the lookback mode
3. On DSP2, I modify a little bit on the loop back example:
for(;;)
{
// mcbsp_xmit(sdata1,sdata2);
//sdata1++;
//sdata2--;

//while(McbspaRegs.SPCR1.bit.RRDY == 0 ) { } // Check for receive
rdata2 = McbspaRegs.DRR2.all;
rdata1 = McbspaRegs.DRR1.all;
//if(rdata1 != rdata1_point) error();
//if(rdata2 != rdata2_point) error();
rdata1_point++;
rdata2_point--;

__asm(" nop");
}
4. On DSP2, I disable the loopback mode
5. On DSP 1 and 2, I do not need to change other McBSP registers. Because the setting in this example is: transmitter is the master and provides clocks and frames to the receiver. What I need to do is in the HW, connect DSP1 MCLKXA <-> DSP2 MCLKRA, DSP1 MDXA <-> DSP2 MDRA and DSP1 MFSXA <-> DSP2 MFSRA.
6. When I do the test, I first run the code on DSP2. It is sitting in the for loop and receiving the data from DRR1 and DRR2. Then, I run the code on DSP1, sending data for ever.
7. The problem is I cannot receive any data on DSP2.

Thanks
Fei

Fei,

You will probably want to add some delay in both the receiver and transmitter. Without waiting on any status pins, you are just constantly writing and reading without knowing if there is data available.

In your transmitter, after the mcbsp_xmit() function, poll on the XRDY bit. This will tell you that the last word has been copied from DXR registers to the transmit shift register. Likewise on the receiver side, you want to poll on RRDY bit. This will tell you that there is data available to read.

-Mark

Hi Mark,

Thanks for your reply. Your answer is very helpful. I add XRDY check on transmitter and RRDY check on receiver. I also set a break point on receiver DSP after it receives something. What I find is the receiver always receive 65535 no matter what the transmit data is. It seems like the receiver always receives all "ones".

Thanks
Fei

Fei,

I am glad to help. Please verify your Pin-Mux settings on the receiver side. don't forget EALLOW when writing to the Gpio control registers.

-Mark

Hi Mark,

For the pin mux setting, the example uses TI API: InitMcbspaGpio, which sets the pins and also EALLOW before write.
void InitMcbspaGpio(void)
{
EALLOW;

/* Configure McBSP-A pins using GPIO regs*/
// This specifies which of the possible GPIO pins will be McBSP functional pins.
// Comment out other unwanted lines.

GpioCtrlRegs.GPAMUX2.bit.GPIO20 = 2; // GPIO20 is MDXA pin
GpioCtrlRegs.GPAMUX2.bit.GPIO21 = 2; // GPIO21 is MDRA pin
GpioCtrlRegs.GPAMUX2.bit.GPIO22 = 2; // GPIO22 is MCLKXA pin
GpioCtrlRegs.GPBMUX2.bit.GPIO58 = 1; // GPIO58 is MCLKRA pin
GpioCtrlRegs.GPAMUX2.bit.GPIO23 = 2; // GPIO23 is MFSXA pin
GpioCtrlRegs.GPBMUX1.bit.GPIO44 = 1; // GPIO44 is MFSRA pin

.....
}

One thing I have to mention is that MFSRA of the receiver is GPIO 44 on this chip. It is Pin 68 on the DIMM 100 control card. But on the docking station, pin 68 is mapped to the pin that is labelled "GPIO-59". I am using this pin as MFSRA.

Thanks
Fei