McBSP C6748 PDK driver porting to C6657

Hi,

Thanks for your post.

To my opinion, though peripheral wise, McBSP on both C6657 & C6748 are identical but the memory mapping, peripheral configuration, interrupt handling would all differ from C6748 to C6657 and I personally think, the development and porting efforts would be complex to migrate McBSP driver from C6748 pdk to C6657 platform. Kindly think about it.

Thanks & regards,

Sivaraj K

---------------------------------------------------------------------------------

Please click the "Verify Answer" button on this post if it answers your question.

---------------------------------------------------------------------------------

Hi Sivaraj,

Thank you for your prompt feedback.

Can you then perhaps suggest an alternative way to get the McBSP on the C6657 to behave similarly to the way it is used with the C6748 PDK? We have been using the C6748 McBSP drivers for a while now and its been quite solid. In my opinion, it seems that hacking the existing the C6657 MCSDK McBSP driver would be even more complex.

Hi,

I would suggest you to modify the McBSP digital loopback example code to try it for EDMA ping pong configuration and this would be the better option i believe so. As i already informed in your previous post that, you could review the existing EDMA PING PONG test code source which  is available in pdk_C6678_1_1_2_6 and I would suggest you to implement the PING-PONG configuration in the C6657 existing McBSP digital loopback example project which would be the better choice in my opinion.

Thanks & regards,

Sivaraj K

---------------------------------------------------------------------------------

Please click the "Verify Answer" button on this post if it answers your question.

---------------------------------------------------------------------------------

Hi Sivaraj,

Would you perhaps humor me on porting the C6748 McBSP driver to the C6657 platform, before I try the digital loopback example you suggested? If I can get this driver up and running, I can provide the source to you guys and the community and then its a win-win situation.

 7853.product-c665x_dev_framework.rar 

Attached is the porting that I have done so far.

I have stripped out everything that is C6748 specific, which was mostly the power management  module (PSC) stuff.

I have mapped the correct addresses of the McBSP registers on the C6657. 

I have added two C6748 CSL EDMA files to the C6657 CSL in order to configure the EDMA PaRAM options:

- cslr_edma3cc.h

- cslr_edma3tc.h

I believe that for now the CPU interrupts are not that important, since the C6748 driver in any case only triggers a CPU interrupt on a SYNC error, so it should not affect the functionality of the driver.

However, I am a bit unsure with the handling of the critical sections, since the C6657 is a multicore device, although I am only programming core 0 now.

I suspect the handling of the cache coherence should not be an issue either, since it uses the standard SYS/BIOS calls.

I also suspect that the configuration of the EDMA LLD should not be a problem, since the interface is the same for the entire C6000 family. Is the assumption correct?

So far I would just like to continuously transfer a known pattern with McBSP0, say 0xAA, so that I can measure it on a scope. It appears that the configuration of the McBSP seems okay, since I can measure the frame sync and bit clock on the scope (although the frame sync is measured at 115.8 kHz and I expect 115.2 kHz).

With the emulator, the EDMA callback (Mcbsp_localEdmaCallback) is also called regularly, so it appears that the EDMA is also configured correctly to some extend at least.

However, at the moment I am not seeing any data on the Dx pin and I do not know why.

Can you please assist me in debugging this problem?

EDIT: I somehow did not add the McBSP drivers in source/dependencies, but I have uploaded this now.

Hi Sivaraj,

I have managed to do some further debugging on the porting.

I am quite confident that the McBSP peripheral in configured correctly. However, I believe the EDMA is not configured properly, but I have not been able to pin point the problem.

I managed to see some data on the Dx pin, but this only happened once I inserted a Task_sleep() between GIO_reclaim() and GIO_issue() calls (see hw_def.cpp). This is somewhat unexpected, as this was never necessary on the C6748.

I also noticed that the data I copy to a reclaimed buffer is never actually transmitted, but only the data from the loopjob buffer. I have traced the problem to the mcbspIsValidPacket() function in Mcbsp_edma.c. It appears that the pending list queue is always empty so this function always returns Mcbsp_STATUS_INVALID and simply transmits the contents of the loopjob buffer.

Do you perhaps have any ideas?

5037.product-c665x_dev_framework.rar

Hi,

Thanks for your update.

In general, the GIO object (created through a GIO_create() call), has doneList and freeList pointer fields that point to a queue internally represented as doubly linked-list.

The freeList maintains a list of free packets while the doneList maintains a list of packets that have been processed. When a packet needs to be sent to the device, a free packet is dequeued from the freeList and sent/submitted to the device's channel (GIO_issue() would for example do this). Once the packet is processed, it is added to the doneList and can be reclaimed i.e. put back on the free list (GIO_reclaim() would be the example to do this).

For a more complete understanding of the GIO model, please read the section on "GIO Drivers" and "IOM Interface" in the SYS/BIOS (TI-RTOS kernel) user guide

GIO_create() allocates one large buffer whose size is (Size of IOM_Packet * number of IOM_Packets specified in GIO_Params). This buffer gets broken up into individual packets and added to the free list. These packets are tracked through the free and done lists which is mentioned above.

So, when the application calls GIO_issue() for example, an IOM_Packet is removed from the free list and filled with the buffer addres, size, etc. This packet is then sent to the device for processing.

However, I need to look into this issue in detailed insight to see anything which turns out better.

Thanks for your understanding.

Thanks & regards,

Sivaraj K

---------------------------------------------------------------------------------

Please click the "Verify Answer" button on this post if it answers your question.

---------------------------------------------------------------------------------

Hi Sivaraj,

Upon closer inspection, it actually seems that the existing C6657 PDK McBSP driver is already a port of the C6748 PDK, but without using the GIO/IOM model!! The way in which the McBSP peripheral and the EDMA is configured is almost identical. It is likely that I have been chasing my tail for the last two days!

It also appears that the author of the C6657 PDK McBSP driver ditched the GIO/IOM model, possibly for the same reason why I cannot get it up and running.

I basically just want to get the C6657 McBSP driver going synchronously, even if it is without the GIO/IOM model, since it is connected to another master McBSP which operates synchronously and by using the existing C6657 PDK driver, I observe data loss on the C6657 side.

I saw that the C6678 EDMA PING-PONG example uses only the CSL and not the EDMA3 LLD. Would you recommend the CSL approach over using the EDMA3 LLD?

Can you please advise a suitable course of action, since I am a bit stuck at the moment!

Hi,

Yes, ofcourse, you could go for CSL approach rather than EDMA LLD which would be more complex to handle and would prefer CSL approach since it is easily adpatable code which involves lesser complexity. Would recommend CSL approach best suitable EDMA ping pong example.

Thanks & regards,

Sivaraj K

----------------------------------------------------------------------------------------------------------------

Please click the "Verify Answer" button on this post if it answers your question.

----------------------------------------------------------------------------------------------------------------

Hi Sivaraj,

I managed to properly configure the McBSP with CSL and I am now trying to configure the EDMA for PING PONG.

I am currently working through the C6678 CSL EDMA examples that you pointed me to, so I just have a couple of questions:

1) QDMA is probably not the best suited for transferring data synchronously between memory and a peripheral, since it appears that it is not possible to trigger a QDMA transfer by means of a peripheral EDMA event. So I believe the normal EDMA channels would be better suited? Am I correct with this observation?

2) With the EDMA CSL it is not immediately obvious how you would configure the triggering of a transfer with a McBSP peripheral event using SYS/BIOS.

It seems as though the McBSP -> EDMA event mapping should not occur using CSL if I am going to use SYS/BIOS. Should I rather use something like CpIntc API?

Can you please provide an example?

3) Similarly, can you perhaps also provide an example of how you would hook up an EDMA interrupt to the C6657 (when a transfer is completed) by means of SYS/BIOS?