Problems with McBSP Digital Loopback example

Hi Leonardo,

Just to be clear on what is going on. You're saying that you put the values in the tx address (as in the address of what will be sent out) and then you receive the values at the RX address in the McBSP of the them without their negative values? I don't think you need to call that function in order to get it to work in your example. I'm trying to figure out if the issue is the McBSP or the EDMA. I would lean towards the EDMA. McBSP basically is a peripheral that dumps out whatever data gets written to it by the CPU or EDMA. You shouldn't have to do a lot of work on it to get it to work, so it may be a configuration issue here. What exactly is your goal here, just to send some packets?

Here are some forum posts that may interest you where others have had McBSP issues, and have examples of how they fixed them. Try glancing at some of these, so we can narrow down what can be the issue and I can help you get through it:

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/40392.aspx

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/11359/44142.aspx#44142

Hi Katherine, thank you for your response.

I just found out I was mistaken about the values read in the  McBSP0 TX address (CSL_Mcbsp0_FIFO_DATA_REGS, 0x22000000). Those were the last values from my Tx Buffer, sorry for that mistake.  But is this normal? Here's a pic from the 0x22000000 address:

This happens right after this part of the code:

/* TX frame processing */
txFrame.cmd = Mcbsp_IOBuf_Cmd_WRITE;
txFrame.addr = (void*)bufTx[count];
txFrame.size = BUFSIZE;
txFrame.arg = (uint32_t)hMcbspTxChan;
txFrame.status = MCBSP_STATUS_COMPLETED;
txFrame.misc = 1; /* reserved - used in callback to indicate asynch packet */

status = mcbspSubmitChan(hMcbspTxChan, (void *)&txFrame);

The last values from the INTERNAL Tx Buffer are written from 0x22000000 to 0x22000FFC. Is this correct? 

About my McBPS Registers:

Here, you can note that: DRR is filled with the last values and so is DXR. The SPCR port (0x02F38037) is setting the flag RFULL to 1. The interruption is never set and my code never leave that "while" I showed before. 

But here it is my INTERNAL Tx and Rx buffers: 

Tx:

0x03020100 0x07060504 0x0B0A0908 0x0F0E0D0C 0x13121110
0x17161514 0x1B1A1918 0x1F1E1D1C 0x23222120 0x27262524
0x2B2A2928 0x2F2E2D2C 0x33323130 0x37363534 0x3B3A3938
0x3F3E3D3C 

Rx:

0x03020100 0x07060504 0x0B0A0908 0x0F0E0D0C 0x13121110

0x17161514 0x1B1A1918 0x1F1E1D1C 0x23222120 0x27262524

0x2B2A2928 0x2F2E2D2C 0x33323130 0x37363534 0x3B3A3938

0x3F3E3D3C 

Apparently my Rx is alredy filled but the interruption is never called and the edmaTxDone and edmaRxDone are never set to 1, hence, never finishing the example. 

So, yes, the problem is probably in the EDMA3 configuration. Am I forgetting to set any flag that is responsible for the interruption? It may be a rookie mistake, but I sincerely don't know what I might be forgetting.

The only changes I made to the default code were the modifications to the RX Clk and FS, I changed from EXTERNAL to INTERNAL. When I look in an osciloscope, the FS and the Clk from Rx and Tx are ok.

My goal is to just receive in the Rx what I set in the Tx, testing the serial port and getting familiarized with the serial port and EDMA3.

Thanks in advance.

Regards, 

Leonardo Batista

Hi Katherine, thank you again for your attention at this topic.

When I tried to plug the EDMA_intDispatcher into the interrupt vector table, I ran into the XGCONF, from BIOS 6 (and by the way, I'm using CCS5). I got to this page:

When I hit "add", it creates a handle called "hwi0". Instantly I get an error saying: "hwi0 alredy in use (by undefined)". I hit add again, creating "hwi1" (deleting "hwi0" afterwards) and, in ISR function, I put "_EDMA_intDispatcher" and in Interrupt number, I put 8 (I not REALLY sure that those are the corrects inputs) and get this error: 

Hwi 8 already in use (by &_EDMA_intDispatcher).

What am I doing wrong? I tried reading BIOS6 manuals but I didn't make any advances in this. The example from the other topic allows you to specify the interrupt source (EDMA). In XGTOOLS I can't do this (or don't know how to do). 

About the OPT field, the McBSP driver default setting is (in mcbsp_edma.c) 0x80024800, so, TCCMODE is set to 1. In mcbsp_device_init, these parameters are set:

/**< edma Transmit event number      

Mcbsp_deviceInstInfo[devId].obj.edmaTxEventNum =

(uint32_t)CSL_EDMA3CC2_XEVT0_MCBSP_A;  (0x25 -> 37)

/**< edma Receive event number      

Mcbsp_deviceInstInfo[devId].obj.edmaRxEventNum =
(uint32_t)CSL_EDMA3CC2_REVT0_MCBSP_A; (0x24 -> 36)

Thank you for your patience.

Regards,

Leonardo Batista

Hey Leonardo,

No problem. Okay, if it says it is already in use, that means it's already added in the vector. So either the value it's set to what we don't want, or it's not able to do tis job of creating an interrupt for you. Since the EDMA_INT dispatcher is already using it, that means either that's not being called or it's (again) not being used correctly. Usually the compiler user guide is where they tell you the details of how to setup the interrupts. So try looking there too, if you get lost. CCSv5 should be fine.

 The fact that it is in use by "undefined" does make me curious.

 The 8 value is correct, so don't doubt yourself there. To quote an SRIO example on the wiki:

Changing the GEM Interrupt Used by the sRIO Transport Module & Other TransportSrioSetup Parameters

TransportSrioSetup.dspIntVectId = 8  /* Desired GEM interrupt */

Adding the latter line to the .cfg file after creating the TransportSrioSetup variable allows the application developer to specify which GEM interrupt is used by the sRIO Transport module.

TransportSrioSetup.descMemRegion = 0;

Try these training guides. They go through the software interrupts (SWIS)  in detail, and may be helpful for you. http://processors.wiki.ti.com/index.php/SYS/BIOS_Online_Training . The SWIS has a PDF ppt which shows you how to create an object XGCONF. Try this.

Try looking at that! I think that will help a lot.

-Kat

Here are miscellaneous some links for help if need be:

http://processors.wiki.ti.com/index.php/Programming_the_EDMA3_using_the_Low-Level_Driver_%28LLD%29

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/241460.aspx

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/209155.aspx

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/439/p/11539/44963.aspx#44963

Hi Katherine, thank you again.

So, it FINALLY worked! And the solution was rather simple (too simple to the point it was frustrating): I went to project options and changed the compiler version from TI v.7.4.1 to TI v.7.4.2. Apparently it was everthing I did and it worked. I'll analyse carefully now and try to see what might've changed.

Thank you very much for your attention,

Regards,

Leonardo.

Great! Glad you solved it. If you need any more help, feel free to ask here.

Kat