This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP DM3730 with Serial ADC on McBSP linux Driver

Other Parts Discussed in Thread: DM3730

Hi,

We had designed the DM3730 based board with Serial ADC, interfaced to McBSP3, can any one help the simple DMA based McBSP driver in linux to read ADC Samples?.

We had tried with some code, taken from forums, the result is we are to see the CLKX and FSX signals out, but no DMA.

We need the DMA to receive the data, because, we want capture the IF signal using the ADC.

Any help on this, it will be great.

Thanks

  • I am in a group working on using a Beagleboard, which features a DM3730 processor, and are looking to use the McBSP lines for serial communication to another device. We are also trying to get DMA transfers working. When (if?) we get it working, I'll try to post our solution. In the meantime, if you have success and are willing to share, you can probably save us a bunch of headaches.

    Thanks,

  • I would be very interested to hear the progress on your groups efforts Barrett and possibly take a look at your code if it has progressed to an alpha/beta stage. We are working towards a similar goal, with several ADCs multiplexed into McBSP. Currently we are focusing our efforts into using the audio driver/codec path in the linux kernel. Several ADCs in parallel can be conceptually mapped onto an equal amount of audio channels quite nicely. This will likely bring some limitations with regards to sample rate and sample size with it, but has the advantage of using existing and proven McBSP and DMA code paths in the linux kernel. The heavy lifting for the McBSP and DMA part is handled in two files in the sound/soc/omap/ directory of the linux kernel source tree:

    http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/sound/soc/omap/omap-mcbsp.c
    http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/sound/soc/omap/mcbsp.c

    Generic (ADC) data might be easiest to record using the SND_SOC_DAIFMT_DSP_B mode, which has no bit offset like the I2S audio interface does. The omap-mcbsp.c file seems to supports up to 16 recording channels. It all looks promising. Should you however be almost done with your approach of using McBSP natively it might be better to go that route. Best of luck and I will post any results back here, which given our development schedule should be in the next couple of days. Otherwise we will have to go about this in an entirely different way.

  • Unfortunately, we haven't made much progress. There has been a series of diversions from this task. Currently, we have a a kernel module compiling in bitbake, that creates a ipkg package. When the package is installed on the Beagleboard, then the module is inserted into the kernel, I get some initial debug output then it just hangs. I imagine I'm doing something terribly wrong, but haven't figured out what as of yet.

    Here's the output on the Beagleboard. The relevant source code is attached.

    root@beagleboard:/# cd /media/sda1
    root@beagleboard:/media/sda1# opkg install mcbsp-module_0.1-r102.9_beagleboard.ipk
    Installing mcbsp-module (0.1-r102.9) to root...
    Configuring mcbsp-module.
    root@beagleboard:/media/sda1# cd /lib/modules/2.6.39/kernel/drivers/mcbsp_module
    root@beagleboard:/lib/modules/2.6.39/kernel/drivers/mcbsp_module# ls
    mcbsp_module.ko
    root@beagleboard:/lib/modules/2.6.39/kernel/drivers/mcbsp_module# insmod mcbsp_m
    odule.ko
    [  119.503936] mcbsp_module: omap_mcbsp_set_io_mode(1,IRQ) returns 0
    [  119.512512] mcbsp_module: omap_mcbsp_request(1) returns 0
    [  119.518249] before XCCR = 0x829
    [  119.521514] before RCCR = 0x809
    [  119.524780] after XCCR = 0x9820
    [  119.528045] after RCCR = 0x808
    [  119.531250] after SPCR2 = 0x200
    [  119.534515] after SPCR1 = 0x80
    [  119.537689] after SRGR2 = 0x1000
    [  119.541381] after SRGR1 = 0x1
    [  119.544464] after RCR2 = 0xA1
    [  119.547546] after RCR1 = 0xA0
    [  119.550659] after XCR2 = 0xA1
    [  119.553741] after XCR1 = 0xA0
    [  119.556823] after PCR0 = 0xF00
    [  119.559997] mcbsp_module: calling omap_mcbsp_config()...    
    [  119.565917] mcbsp_module:                                   OK!
    [  119.565917]  
    [  119.573547] mcbsp_module: max_tx_threshold (1) = 112
    [  119.578918] mcbsp_module: max_tx_threshold (2) = 112
    [  119.584075] mcbsp_module: max_rx_threshold = 112
    [  119.588897] mcbsp_module: tx_threshold = 0
    [  119.593200] mcbsp_module: rx_threshold = 0
    [  119.597442] mcbsp_module: fifo size = 128
    [  119.601623] mcbsp_module: dma_op_mode = 0
    [  119.605804] mcbsp_module: omap_mcbsp_start(1,1,1) called

    Output stops here and the Beagleboard just hangs. This is an improvement over a few days ago when the omap_mcbsp_config() routine would hang. Running Linux kernel 2.6.39 with OpenEmbedded.
  • I had to take some time off of this project and am now getting back to it. We haven't had any success yet with the driver. Any chance someone out there has a working McBSP serial driver and is willing to share??

  • Hi Barrett,

    Did you get your driver working now or not?

    Thanks

  • Sadly, no. The board we were targeting was a BeagleBoard. One of the electrical engineers got confirmation that on the revision of the board we were dealing with, it would be impossible to use the McBSP channel we needed (for throughput) for anything but audio due to internal routing on the BeagleBoard.

  • Hi Barrett,


    I'm working on the design of a mcbsp driver to transmit some data to another board. I would like to know if you could post our code.


    Thanks