After much reading , it would seem that the McBSP poll read and write functions in the API do not work for the omap 3530 out of the box. They refer to DXR1 and DXR2 (the 3530 only has a 32bit DXR)... Changing everything to DXR and DRR brought them back to life. My char driver can send and receive data using the low speed poll methods. Now that it works, I'm turing my attention to trying to get all this working with DMA. Does anyone out there have any pearls of wisdom about the mcbsp library in the kernel? Has anyone used the DMA base omap_mcbsp_xmit/recv_buffer calls successfully?

Any help would be greatly appreciated!


On Tue, Dec 29, 2009 at 12:38 PM, Alex Stewart <> wrote:
Hello group!
Maybe a kind sole out there can point out my error or miss configuration. I'm trying to get a char driver written that uses McBSP3 on the Overo Chestnut breakout board. I'm using an overo water (no bluetooth or wifi) and I've recompiled u-boot with McBSP3 Muxed out over what used to be the pwm gpio (see previous post below for Mux settings). I've also disabled the init code that sets those lines up for the LCD as GPIO, and disabled the bluetooth daemon. Currently my McBSP config is as follows:

static struct omap_mcbsp_reg_cfg mcbsp_regs = {
        .spcr2 = FREE,
        .spcr1 = RINTM(0),
        .srgr1 = FWID(15) | CLKGDV(50),
        .srgr2 = CLKSM | CLKSP  | FPER(255), //| FSGM
        .pcr0  = FSXM | CLKXM | CLKRM | FSRM | FSXP | FSRP | CLKXP | CLKRP,
        //.pcr0 = CLKXP | CLKRP,        /* mcbsp: slave */

My driver sets up McBSP3 for polled mode, when I start it up with the FSGM bit set, I see my FSX line toggling as expected, however when I look at the DX line and try to send a byte:
ret = omap_mcbsp_pollwrite(OMAP_MCBSP3, 0x53);

Nothing happens. With the FSGM bit not set (IE FSX happens when the transmit buffer is not empty), my FSX lines stops toggling. Any call to omap_mcbsp_pollwrite does not generate a FSX or any data on DX. I'm sure its something simple I'm missing here. Printing the value of SPCR2 before and after calling pollwrite shows the XSR always empty....

Any help or pointers would be very appreciated.  


ps - Also in the above scenarios, the McBSP lib never returns an error, all the pollwrites and configures return 0.

On Mon, Dec 28, 2009 at 10:02 AM, Alex Stewart <> wrote:
Hi Thomas,
 Thanks for the information! Greatly appreciated. I was leaning in the direction you mentioned actually since I was not sure what kind of signal I'd get out of the ALSA libs. (ie scaled, or processed into float etc.) I've got the skeleton of a char driver written, and I've been trying to transmit some data out of McBSP3 using a Chestnut board (no LCD attached). So far, I've re-compiled u-boot with the following in my overo.h file:

MUX_VAL(CP(MCBSP3_DX), (IEN  | PTD | DIS | M4)) /*GPIO_140*/\
MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M4)) /*GPIO_141*/\
MUX_VAL(CP(MCBSP3_FSX), (IEN  | PTD | DIS | M4)) /*GPIO_143*/\
MUX_VAL(CP(UART2_CTS), (IDIS | PTD | DIS | M1)) /*McBSP3_dx*/\
MUX_VAL(CP(UART2_RTS), (IEN  | PTD | DIS | M1)) /*McBSP3_dr*/\
MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M1)) /*McBSP3_clkx*/\
MUX_VAL(CP(UART2_RX), (IEN  | PTD | DIS | M1)) /*McBSP3_fsx*/\

I'm using (and always will be) an Overo Water, so there is no bluetooth mounted. The above should route McBSP3 to the GPIO144,-147 on the 40pin header if I read and understood everything correctly.

From there my omap_mcbsp_reg_cfg looks like this:

struct omap_mcbsp_reg_cfg ads1274_cfg = {
0x0000 | FREE, //spcr2
0x0000, //spcr1
0x0000, //rcr2 RPHASE (bit 15) | RFRLEN2 (14 - 8) | RWDLEN2 (7-5) |RREVERSE(4-3) | RSVD 2 | RDATDLY
0x0038, //rcr1  -- 24 bits 4 words
0x0000, //xcr2
0x0038, //xcr1
GSYNC | FSGM | FPER(200), //srgr2 -- sample rate generater
FWID(10) | CLKGDV(8), //srgr1
0x0000, //mcr2
0x0000, //mc1;
CLKXM | CLKRM | FSXM | FSRP | FSXP , //pcr0;
0x0000, //rcerc;
0x0000, //rcerd;
0x0000, //xcerc;
0x0000, //xcerd;
0x0000, // rcere;
0x0000, // rcerf;
0x0000, // xcere;
0x0000, // xcerf;
0x0000, //rcerg;
0x0000, // rcerh;
0x0000, // xcerg;
0x0000, //xcerh;
0x0000, // xccr;
0x0000, //rccr;
0x0308 //syscon

I can request the BSP, start it, and poll write to it with no error. The problem is after I start the McBSP I see my clock on the header, but I never see any data on any of the lines. DX and FSX never change. I'm almost positive it's something simple like not configuring the clocks correctly. You were correct about my goal, the ADC I'm interfacing to will be running at 96 KHz on 4 channels. So my goal is to use the internal SRG to run everything and DMA the four 24 bit frames into memory.

I also tried the SPI wrapper found in the platform driver code with similar results, I'd get a free running clock, but no data would ever come out. Ideas anyone? 

Best Regards,

On Sun, Dec 27, 2009 at 7:39 AM, Thomas Søhus <> wrote:
Hi Alex,

Depending on your specific use case for the ADC, I would not consider using
the ALSA drivers. I guess you want to use McBSP in SPI mode and use the
frame sync signal for sample generation? – Then the best choice is to write
an ADC char driver that utilizes the McBSP library directly.
I have written an ADC char driver that does exactly this. I had to correct a
few small errors in the Linux McBSP library code and in the DMA library as
well to get it to work, but other than that it went pretty smooth.
If you have any additional questions, feel free to ask.

Best Regards,
Thomas Søhus, CeePro | Embedded solutions,

From: Alex Stewart []
Sent: 22. december 2009 15:28
To: General mailing list for gumstix users.
Subject: [Gumstix-users] ADC/ McBSP advice and questions about writing a

Hello gumstix list!
Hopefully some kind sole can  help me.
My goal is to connect a serial ADC to McBSP3. It must be a McBSP (and not
McSPI) so we can use the sample rate generator to run the sample clock. I've
got an overo water and a chestnut board. My question is what is the best way
to go about writing the code. I see I can either write a driver that
interfaces to the McBSP library in the kernel, or add the ADC into the ALSA
framework. Initially I thought adding to the ALSA framework would be the
easier task, but as a hardware engineer I quickly got lost in the layers of
abstraction and could not figure it out. So I tried writing a simple char
driver wrapper for the McBSP library. Am I correct in thinking the steps to
get this all working are to request the bsp, stop the bsp, configure it,
then issue a mcbsp start, at which point I can call things like
omap_mcbsp_xmit_word? Thats what my code currently does but it hangs at the
"wait_for_completion" line in the xmid_word code.

I realize seeing my driver code would help, but I wanted to get to the root
question first. Is writing a simple char driver to DMA my raw adc data into
a userspace buffer easier than simply not reinventing the wheel and adding
support for my adc into the ALSA stuff...? 

Thanks for the help and advice!

No virus found in this incoming message.
Checked by AVG -
Version: 9.0.717 / Virus Database: 270.14.117/2581 - Release Date: 12/22/09

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
gumstix-users mailing list