I am trying to use the Mcbsp_Edma_example sample code from the EVMC6474_V1\csl_C6474\examples\mcbsp\mcbsp_edma directory, but need to port it to a DSP/BIOS environment.
The code as it stands works. I am having difficulties porting it to a DSP/BIOS wrapper.
The area that I think I am having problems with are with the interrupt enabling aspects.
I have commented out all INTC related parts of the code, and am now trying to determine what the DSP/BIOS replacements should be, but am not managing to make much progress.
I have been looking in SPRUG11.pdf, SPRUG17.pdf, SPRS552.pdf and also SPRA491a.pdf, but am making no progress.
The sample code, appears to have about 3 areas where changes are needed, all to do with the interrupt initialisation and event mapping.
====
The first section at about line 158, defines various structures used by the other sections.
Section 2 at about line 316:
intcContext.eventhandlerRecord = EventHandler;
intcContext.numEvtEntries = 10;
CSL_intcGlobalNmiEnable();
intStat = CSL_intcGlobalEnable(&state);
vectId = CSL_INTC_VECTID_4;
hIntcEdma = CSL_intcOpen(&intcObjEdma, CSL_INTC_EVENTID_EDMA3CC_INT0, &vectId, &status);
Section 3 at about line 440:
EventRecordTx.handler = &eventEdmaHandler;
EventRecordTx.arg = (void*)(hModule);
CSL_intcPlugEventHandler(hIntcEdmaTx, &EventRecordTx);
CSL_intcHwControl(hIntcEdmaTx, CSL_INTC_CMD_EVTENABLE, NULL);
Any pointers or additional documentation links would be helpful. Or an example which uses DSP/BIOS with EDMA+McBSP.
My final goal is to use McBSP+EDMA to transfer a boot image from DSP memory to an FPGA connected to the McBSP port.
Hi James,
Unfortunately we do not have an example with the McBSP working with DSP/BIOS.
If you want to adapt the code, you could look at this article (as an example on how to do it):
http://tiexpressdsp.com/wiki/index.php?title=Converting_from_INTC_to_BIOS
EDIT: I removed my answer with the C6747 part because I saw that you were using C6474. But the article is still good.
- Mariana
---------------------------------------------------------------------------------------------------------Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------
Thank Mariana, I had seen that document previously, I had missed a few items.
I now have a BIOS port of the sample code, but am still having problems with it.
The code manages to do the single DMA transfer and passes the test at the end.
If I then try to modify the code so that I attempt to send a second DMA transfer after the first one has finished, I find that although setting up the PARAMSET structures for the TX and RX, the EDMA transfer does not start. I can not see what I am missing, but it is as if either the McBSP is nolonger requesting data from the EDMA, or the EDMA has stalled and is not aware that it needs to start sending a new transfer.
The documentation on EDMA (sprug11.pdf) and McBSP (sprug17.pdf) do not really give me much of a clue as to what I may be missing.
Additionally if I split out the code into two separate applications, one for TX and one for RX, and then run these on CORE0 of the 2 DSP's on the C6474 EVM board, I find that the RX version appears to be receiving data continuously, even though I am not running the TX application, so am not sure if this is a configuration issue, or something else, the data that gets copied to my RX buffer is all 0x00 nulls, so I do not think it is real data, but am unsure what is actually occuring.
Again I suspect that it is my code that is at fault, but I can not see what is causing the EDMA to repeatedly raise the RX completion interrupt. It appears to be a one shot deal, in that when I reset my code and run, the PARAMSET[13] (RX) entry starts with initialised data:
OPT = 0x8010d200, SRC = 0x30000000, A_B_CNT = 0x00100004, DST = 0x800004d0, SRC_DST_DIDX = 0x00040000, LINK_BCNTRLD = 0x0001ffff, SRC_DST_CIDX = 0x0, CCNT = 0x01
Then when the interrupt occurs, all entries have become 0x00 except for LINK_BCNTRLD which has changed to 0xffff.
One thing that I do not currently do, which may impact on the stalled TX interrupt, is wait for the last data word (32bit) to transfer from the DXR to XSR register, so potentially at the start of sending the second block of data (in interrupt routine), the last word could get trashed, but I do not think that is an issue yet, as the second transfer does not start, the EDMA does not modify the PARAMSET[12] (TX) data, so I assume does not even begin the transfer.
Any suggestions would be greatly accepted.
Hi Gareth,
It is hard to suggest what could be wrong.
One common error that comes to mind is that as the INTC examples usually do not leave main, local variables are used for Param structures and other important handles. When you use DSP/BIOS, you are going to leave main, so you need to make sure that all the variables used by EDMA and all other important handles are global. Could you check that?
I had moved the main() function into a thread/task, and made the various parameters global.
Another thought about what I am trying to do:
I want to send a number of blocks of data (about 1.3MByte) out of the McBSP to a FPGA. This obviously requires the data to be sent in a number of DMA actions. At present, using the sample program, this only demonstrated what appears to be a single block transfer. When the interrupt occurs, then all the DMA data (except possibly the final word/byte) will have transfered out of the McBSP on to the wire, so the DMA hardware is probably idle, and the McBSP is probably requesting more data, so the hardware effectively stalls in this condition.
When I service the interrupt, I set up a new DMA transfer, but I appear to be missing some step, as the DMA transfer does not start.
If I wanted to stream data out of the McBSP without any interuptions to data flow, what method should I be using, I guess that I need to set up a sequence of DMA parameter blocks in PARAMSET so that when an interrupt occurs, I just add a new PARAMSET entry linked to the existing entries, so they play out in sequence. Is this correct, or am I again missing something. Is there a working example of this (INT or BIOS)?