Sample code for McBSP in SPI mode does not work when switched from McBSP0 to McBSP1

Hi Sreenath,

Loooking into your issue, I can comment few things..

The sample application provided by the PSP package is configured to McBSP0. To configure it to operate on McBSP1,

You should make the following changes:

1. Create a McBSP1 device in the .tci file with correct device id (you hav done it in .tcf file and its fine).

2. Make sure you pass the correct intrNum. (You have done it, but make sure the intrNum is correct).

3. By doing so, your sample application should work for McBSP1 directly since driver supports both the instance of McBSP. (Create only one instance of the device to make debugging easier, since code provided by you has both instances operating).

So, in your case just create McBSP1 instance and proceed with the application.

This seems to be quite tricky.. In this case, you have to debug and look into it and firstly confirm that the correct instance number is passed throughout, and check that the corresponding base address of the McBSP instance is assigned. If the base address is proper, then there is no way that the data transaction will occur on  McBSP0 by using the McBSP1 handle.

When the device instance is created for perticular instance, the code flow would be like UDEV_create() -> mcbsp_mdbindDev() -> PSP_mcbspCreate() -> LLC_mcbspOpen(). In here, the base address will be assigned.

If you are using CCS, then open memory window for register set of both the instance, and check which instance's register is getting modified. 

Could you please verify the hardware connection also? (I know it will be fine, but i just want to make sure) 

Thanks and Regards,

Raghavendra M

Hi Raghavendra,

Thanks for your response. The simple change that you suggest - making sure right interrupt number is used, does not help me. I still am not able to make McBSP1 work. 

After logging the issue on the e2e forum I was also able to trace through the driver code and see that right indexes are being passed (0 for McBSP0 and 1 for McBSP1). The following are the handles / addresses I see while tracing the device driver code:

McBSP0

------

Port Handle: 0x810352f8

io Handle: 0x81031c5c

EDMA channel Tx: 2U

EDMA channel Tx: 3U

McBSP0

------

Port Handle: 0x8103532C

io Handle: 0x81032698

EDMA channel Tx: 4U

EDMA channel Tx: 5U

In the case when I create both the devices I see that right handles are being accessed too.

Please look at the attached image for register dumps. The base addresses that are being linked to McBSP are from soc.h which defines them as below:

/** @brief Base address of MCBSP memory mapped registers */

#define CSL_MCBSP_0_REGS                (0x01D00000u)

#define CSL_MCBSP_1_REGS                (0x01D00800u)

I am curious, were you able to reproduce the defect? If you are able to make transmission happen on McBSP1 by modifying the sample code, it would mean we have no issue at all. Then it would mean - either I am doing some silly mistake or my software packages are not appropriate or something like that. Let us ignore the anamolous behavior of McBSP1 handle sending data out on McBSP0. The anomoly might have been a case when the h/w was not properly loaded or some such thing. Let us focus on just getting the sample code to work with McBSP1 instead of McBSP0.