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.

C6713 McASP to program the ADC

Other Parts Discussed in Thread: ADS8556

Hi,

I am using a TI DSP C6713.

In the design, the McASP1 is connected to the control interface of ADC ADS8556

as well as the serial data interface.

I am trying to program the ADC ADS8556 using McASP and have a couple of questions.

1) Can we program the ADS8556 (precision A to D Converter) using McASP?

2) After initialization of McASP, I can see clock and framesync (probed on the respective pins

of ADS8556), but cannot see the data coming from the McASP Xmt pin of the DSP.

3) I think the reason could be that the McASP cannot function in clock-stop mode and so

it generates an error since the framesync and clock are continuous and since there is only one

control register in ADS8556, I transmit only one word on the McASP data lines.

Is this reasoning correct?

4) What is a possible way to program an ADC using McASP pins of C6713?

If possible can you guys give me some source code for McASP initialization for this case.

Thanks,

Aditi.

  • Hi Aditi,

    1) From reading the ADS8556 DS, per Figure 37, I think it is possible to program it using the McASP.

    2) Is the McASP Xmt pin connected to ADS8556 SDI pin?  

    3) You can’t just stop the clocks.  You have to keep them running.  If your clocks stop, you get an error condition, and you have to handle that before you can continue processing.  Any code written for it should include resetting the McASP upon an overrun/underrun, clock stop, etc.  It needs to be sure to follow the init sequence, one of whose requirements is that any external clocks need to be running before you take McASP out of reset.

    4) Unfortunately the McASP does not support the SPI like the McBSP which can be used to to program an ADC here.

    Let me get back with you on example code, I am checking with my colleague.

    Thanks,

    Tai Nguyen 

  • Tai,

    Thanks for the prompt reply.

    Yes the AXR1[n] pin of the DSP is connected to the SDI pin on the ADS8556 (just for

    more info, HW/SW = 1, and PAR/SER = 1).

    Aditi.

  • Hi Aditi,

    I have checked with my colleagues and we have nothing for the ADS8556.  

    For the AIC3106 – there is code here – but it’s developed on the OMAP-L1x / C674x and it should be still valid setup code for C671x devices.

    http://processors.wiki.ti.com/index.php/QuickStartOMAPL1x_rCSL

    Thanks,

    Tai

  • Tai/Aditi,

    It doesn't look like you need SPI or clock-stop mode to program this device.  The McASP should be able to program it.  

    Aditi,

    Look at the "Burst Transfer Mode" operation of the McASP in the user guide (SPRU041).  Using 16-bit slots you should be able to send the required commands to the ADC.  Although we don't have example code, the programming steps for this mode are given in the user guide.

    Gus

  • Hi Gus,

    Thanks for the reply. It gave me a hope (using burst transfer mode).

    But again a quick question. For burst transfer mode, the frame-sync is a

    single-bit frame-sync, but if you look at the Control register update timing diagram

    in document SBAS404A on page 28 (PAR/SER = 1),

    the frame-sync should last for the whole 32-bit control word.

    How do I implement a frame-sync like that using Burst transfer mode?

    Can you give me a suggestion?

    Thanks,

    Aditi.

  • Gus,

    Here is a flow of steps of how I am initializing the McASP to program the ADC.

    Please let me know if I am missing any important steps.

    1) Configure the DEVCFG register of C6713 to set the multiplexed pins for McASP function.

    2) Disable all interrupts.

    3) McASP open port and reset

    4) McASP init ---

        i) configure receive registers to be all zeros (since to program the ADC, we only transmit the control words)

        ii) configure the transmit registers

        iii) configure the serializer registers

       iv) configure the global registers like the PFUNC, PDIR, DITCTL, DBLCTL, etc

        v) start serial clocks by taking the state machines out of reset for the transmitter

    5) Initialize the ADC by sending control word over the XBUF1[n].

     

    Let me know if this procedure is correct. 

    Also, once we write to the XBUF registers, the transmit should take place....correct?

    I can see the clock running correctly. But I cannot see any control word being transmitted

    even after I write the control word to XBUF.

    Is there some step I am missing?

    Please help ASAP.

    Thanks,

    Aditi.

     

  • Hi Aditi,

    The frame sync is not really a single bit frame but rather it is a whole data word pulse. In this case, the data word needs to be set to the 32 bit mode then the frame sync pulse is a pulse of 1 bit clock high and 31 bit clocks low.

    Please refer to section 3.2.1 of the McASP UG (spru041J) to configure the McASP in transfer mode. You would need to be in 1 bit delay mode.

    Thanks,

    Tai Nguyen  

  • Tai,

    I know the McASP frame-sync is a pulse of 1 bit clock high and 31 bit clocks low.

    But can you look at the ADC datasheet SBAS404A on page 28 (PAR/SER = 1).

    The ADC expects the frame-sync to be low for the whole 32-bit word.

    Please confirm if I am looking at it correctly?

    Thanks,

    Aditi.

  • Tai,

    I configure the McASP such that the peripheral data bus is selected (XBUSEL =0 in XFMT register).

    In my code when I do the following,

    XFMT->XBUSEL = 0;

    PDIR -> AXR5 = OUT; (for transmit)

    *(volatile uint32_t *) XBUF5 =0xffc003ff ;(control word);

    After this I should be able to see the control word in the memory corresponding to McASP1 -> XBUF5

    (0x01b5 0214 accg to SPRS294B page 24). But I can only 0x00000000. This means the

    control word was not written to XBUF5 (McASP1).

    Is there any other keyword used to write to the XBUF registers-?

    Or is there something minor that I am missing?

     

    Please reply ASAP.

    Thanks,

    Aditi.

     

  • Tai,

    Do I have to setup the EDMA channel to program the control word for ADC?

    Thanks,

    Aditi.

  • Hi Aditi,

    No you don't have to setup the EDMA unless you plan to use the EDMA to read/write data from/to the McASP data registers.

    One thing, since you need the frame to be low for 32 bit clocks, you would configure the frame sync to 33 bit clock long.

    Regarding to the transmit data not written to XBUF5, were you able to see any of the other contents of the McASP control registers properly? If not I suspect the problem is somewhere else.

    Thanks,

    Tai

  • Aditi,

    I agree with Tai regarding the frame sync.  In burst transfer mode the frame-sync signal will stay high and go low only during the transmission of a data word.  It will go high after the data word has been transmitted and it will stay high until you write another data word to the serializer register.  

    You don't need to program the EDMA for this.  Actually, I recommend you figure out the correct McASP configuration before you add another level of complexity with the EDMA.

    You need to have XBUSEL = 1 to be able to write to AXR5 through address 0x01B50214 using the CPU.  This might be your problem.  

    Gus

  • Tai,

    I can see the other McASP1 registers being setup correctly.

    But I cannot see the XBUF register being written even after I do the following

    I am polling the XRDY bit to write to the XBUF register.

     

    #define XBUF5 0x214

    data = 0xFF0503FF;

    temp = *((uint32_t *)(mcasp_base + SRCTL5)) & 0x0010;     //check if XRDY is set

       while (!temp) {
          temp = *(uint32_t *)(mcasp_base + SRCTL5) & 0x00010;
       }
    // write output Xmt buffer reg 5

       *(volatile uint32_t *)(mcasp_base + XBUF5) = data;

     

    Let me know if this is correct to write to the XBUFx register.

    And as mentioned in you reply, I am now using the peripheral configuration bus to set up the McASP registers.

     

    Also one thing I observe is the data is being written to 0x01b5 01d4 (for Serializer 5).

    When I look what the address refers to in the datasheet (SPRS294B page 23 ),

    the adress range 0x01b5 01a0 - 0x01b5 01fc is RESERVED.

    These might be the internal rergisters being used by the McASP1 but I cannot see the data in the XBUF registers.

    Also I cannot see the data being transmitted on the AXR[n] pin of the DSP.

    Aditi.

  • Tai/ Gus,

    Here is the code that I use

     

    MCASP_Handle hMcasp;

    void main(){
       
        int i,port;
        uint32_t temp_val=0;
       
        CHIP_Config devCfgReg = {

              CHIP_DEVCFG_RMK(
                   CHIP_DEVCFG_EKSRC_ECLKIN,
                   CHIP_DEVCFG_TOUT1SEL_MCASPPIN,
                   CHIP_DEVCFG_TOUT0SEL_MCASPPIN,
                   CHIP_DEVCFG_MCBSP0DIS_1,
                   CHIP_DEVCFG_MCBSP1DIS_1)
         };    // Programs the DEVCFG register so that the muxed pins on the C6713 device functions as MCASP pins.    

           
        CSL_init();
       
        /*---------------------------------------------------------------*/
        /* Initialization                                                */
        /*---------------------------------------------------------------*/    
        /* Sets GIE = 0 and NMIE = 1.  Also disables all interrupts, */
        /* clears all interrupt flags. */

        IRQ_globalDisable(); /* GIE=0 */

        for (i = 4; i < 16; ++i)
        {
            IRQ_reset(i);
        }   
       
        /* Programs the DEVCFG register so that the muxed pins on the
                C6713 device functions as MCASP pins.
         */ 
     
        CHIP_config(&devCfgReg);

        port =1 ;     
       
        /*---------------------------------------------------------------*/
        /* Initialization                                                */
        /*---------------------------------------------------------------*/      

        hMcasp = MCASP_open(port, MCASP_OPEN_RESET);   
         
        InitMcasp_Codec(port);  
       
        MCASP_enableSers(hMcasp, MCASP_XMT);
       
        MCASP_enableFsync(hMcasp, MCASP_XMT);
       
        temp_val = *(uint32_t *)(MCASP1_ADDR + GBLCTL);
       
        *(uint32_t *)(MCASP1_ADDR + GBLCTL) = temp_val | 0x0000800;
       
        temp_val = *(uint32_t *)(MCASP1_ADDR + XSTAT);
        *(uint32_t *)(MCASP1_ADDR + XSTAT) = 0xffffffff;

       Codec_Init(); 

    }

    void InitMcasp_Codec(int port)
    {

         /*---------------------------------------------------------------*/
         /* Define structures for later use                               */
         /*---------------------------------------------------------------*/
         MCASP_ConfigRcv rcvRegs = 
         {  0,0,0,0,0,0,0,0            
         };

         MCASP_ConfigSrctl srctlRegs =
         {
              MCASP_SRCTL_RMK(
                   MCASP_SRCTL_DISMOD_LOW,
                   MCASP_SRCTL_SRMOD_INACTIVE),  /* SRCTL0 */
              MCASP_SRCTL_RMK(
                   MCASP_SRCTL_DISMOD_LOW,
                   MCASP_SRCTL_SRMOD_INACTIVE),  /* SRCTL1 */
              MCASP_SRCTL_RMK(
                   MCASP_SRCTL_DISMOD_LOW,
                   MCASP_SRCTL_SRMOD_INACTIVE),  /* SRCTL2 */
              MCASP_SRCTL_RMK(
                   MCASP_SRCTL_DISMOD_LOW,
                   MCASP_SRCTL_SRMOD_INACTIVE),  /* SRCTL3 */
              MCASP_SRCTL_RMK(
                   MCASP_SRCTL_DISMOD_LOW,
                   MCASP_SRCTL_SRMOD_XMT),  /* SRCTL4 */
              MCASP_SRCTL_RMK(
                   MCASP_SRCTL_DISMOD_LOW,
                   MCASP_SRCTL_SRMOD_XMT),  /* SRCTL5 */
              MCASP_SRCTL_RMK(
                   MCASP_SRCTL_DISMOD_LOW,
                   MCASP_SRCTL_SRMOD_INACTIVE),  /* SRCTL6 */
              MCASP_SRCTL_RMK(
                   MCASP_SRCTL_DISMOD_LOW,
                   MCASP_SRCTL_SRMOD_INACTIVE),  /* SRCTL7 */
         };

         MCASP_ConfigGbl globalRegs =
         {
              MCASP_PFUNC_RMK(
                   MCASP_PFUNC_AFSR_MCASP,
                   MCASP_PFUNC_AHCLKR_MCASP,
                   MCASP_PFUNC_ACLKR_MCASP,
                   MCASP_PFUNC_AFSX_MCASP,
                   MCASP_PFUNC_AHCLKX_MCASP,
                   MCASP_PFUNC_ACLKX_MCASP,
                   MCASP_PFUNC_AMUTE_DEFAULT,
                   MCASP_PFUNC_AXR7_MCASP,
                   MCASP_PFUNC_AXR6_MCASP,
                   MCASP_PFUNC_AXR5_MCASP,
                   MCASP_PFUNC_AXR4_MCASP,
                   MCASP_PFUNC_AXR3_MCASP,             
                   MCASP_PFUNC_AXR2_MCASP,             
                   MCASP_PFUNC_AXR1_MCASP,             
                   MCASP_PFUNC_AXR0_MCASP),             
              MCASP_PDIR_RMK(
                   MCASP_PDIR_AFSR_OUT,
                   MCASP_PDIR_AHCLKR_OUT,
                   MCASP_PDIR_ACLKR_OUT,
                   MCASP_PDIR_AFSX_OUT,
                   MCASP_PDIR_AHCLKX_OUT,
                   MCASP_PDIR_ACLKX_OUT,              
                   MCASP_PDIR_AMUTE_DEFAULT,
                   MCASP_PDIR_AXR7_OUT,
                   MCASP_PDIR_AXR6_OUT,            
                   MCASP_PDIR_AXR5_OUT,            
                   MCASP_PDIR_AXR4_OUT,            
                   MCASP_PDIR_AXR3_IN,            
                   MCASP_PDIR_AXR2_IN,            
                   MCASP_PDIR_AXR1_IN,            
                   MCASP_PDIR_AXR0_IN),                      
              MCASP_DITCTL_DEFAULT,
              MCASP_DLBCTL_RMK(
                   MCASP_DLBCTL_MODE_XMTCLK,
                   MCASP_DLBCTL_ORD_XMTEVEN,
                   MCASP_DLBCTL_DLBEN_DISABLE),
              MCASP_AMUTE_DEFAULT    
         };

         /*---------------------------------------------------------------*/
         /* 2. Configure all registers except GBLCTL                      */
         /*---------------------------------------------------------------*/ 
         // Step 2a: Leave PWRDEMU at default.
        
         // Step 2b: Receiver registers    
     
        MCASP_configRcv(hMcasp, &rcvRegs); 
         
        // Step 2c: Transmitter registers
        MCASP_configXmt(hMcasp, &xmtRegs);             

        // Step 2d: Serializer registers
        MCASP_configSrctl(hMcasp, &srctlRegs); 
         
        // Step 2e: PFUNC, PDIR, DITCTL, DLBCTL, AMUTE.
        MCASP_configGbl(hMcasp, &globalRegs);  
        
        
        /*---------------------------------------------------------------*/
        /* 3. Start Serial Clocks                                        */
        /*---------------------------------------------------------------*/ 
        
        // Step 3a: Take clk dividers out of reset
        // Step 3b: Read back GBLCTL to make sure the clock resets are written to errorfully         
        
        MCASP_enableHclk(hMcasp, MCASP_XMT);
        while(!(  MCASP_FGETH(hMcasp, GBLCTL,XHCLKRST)));
        
        MCASP_enableClk(hMcasp, MCASP_XMT);
        while(!(  MCASP_FGETH(hMcasp, GBLCTL,XCLKRST)));

        
    } /* end of InitMcasp() */

    void Codec_Init(){
       
        uint32_t data;
       
        data = 0xFF0003FF;
        mcasp_write_poll(MCASP1, data);

    }

    Plese take a look and let me know if you see anything wrong.

    I thought this was a better way.

    Might be you can see something that I am not able to.

     

    Thanks,

    Aditi.

     

  • Tai/ Gus,

    Can you guys please answer.

    I am sorry to bug you. But getting the ADC control register programmed

    has become a bottleneck and I can't go further with my work without doing that.

     

    Thanks,

    Aditi.

  • Tai,

    A couple more things to say.

    In Burst mode (XMOD = 0 in XFMT reg), even if I set the word size to be 32 bits and

    frame-sync width to be a WORD, the frame-sync is only one-bit wide (when probed and looked at on the scope).

    ALso one more thing I observe is that the XCKFAIL bit is being set in the XSTAT register.

    What could this mean? I can see the clock coming out correctly.

    Aditi.

  • Tai,

    It looks like in the Burst transfer mode, the frame-sync can only be one-bit wide.

    Can I use the AFSX1 pin as a GPIO and configure/ cause it to go low for 32 clocks so I can

    generate the frame-sync manually ? If so, I might need some help with setting it up for exactly 32 clocks long.

    I only have to write one control word to the ADC.

    Thanks,

    Aditi.

  • Would it be possible for you to post a picture of AFSX, ACLKX, and AXR5?  I wouldn't recommend you set AFSX as GPIO.  It would be impossible to control the timing between the AFSX pin and the AXR5 bits.  

  • Gus,

    Here is the picture of ACLKX, AFSX and AXR5.

    As you can see from the picture, the Frame-sync is just low for one clock.

    To program the control register of ADS8556 with DSP6713 McASP, the frame-sync should be low for 32 clocks.

    Can you suggest as to what can be done to get a frame-sync like that (presently I am using Burst-mode on the McASP).

    The data being written is 0xFF0003FF (as you can see this is being transmitted correctly).

     

    Thanks,

    Aditi.

  • Hi Aditi,

    I think you can invert the frame sync signal by changing the FSXP bit. You might have to change the delay bit so the data seeing by the ADS8556 is correct.

    Thanks,

    Tai 

  • Tai,

    If I invert the frame-sync signal by changing the FSXP bit,

    is there not a chance that because the frame-sync is low from the beginning (even before we transmit

    a control word), the ADC tries to read something from the SDI line.

    Also, the frame-sync does not go high after writing a control word (it goes high for one cycle and then stays low)

    Will this not cause any problem as I think the ADC ADS8556 (according to page 28 of SBAS404A) expects the

    frame-sync to go high after 32clocks.

    Let me know if I am ignoring any facts or if this will work.

    For you convenience I am attaching the timing diagram of the serial interface from ADS8556 datasheet.

    Thanks,

    Aditi.

  • Aditi,

    First, the frame sync should not be active at the beginning (before transmitting anything) rather it is hi-z if it is not transmiting.

    Come to think of the attached waveform, I think you can configure the frame sync active low, in word mode, with 32-bit slot size and word size set to equal the slot size. 

    Thanks,

    Tai

     

     

  • Tai,

    Because I am working in Burst-mode, the frame-sync equal to 32bit word/slot size will not work.

    As you can see from the McASP Ref Guide (SPRU041J page 39), it says the following

    AFSRCTL/AFSXCTL: Clear RMOD/XMOD bits to 0 to indicate burst mode. Clear FRWID/FXWID bits
    to 0 for single bit frame sync duration. Configure other fields as desired.

    I tried to configure the McASP for Burst Mode with frame-sync width equal to word, but that does not work.

    If you have tried at your end, can you please send me the code so that I can try and see at my end.

    Thanks,
    Aditi.

  • Aditi/Tai,

    Since burst mode cannot generate a frame sync pulse longer than one clock bit, perhaps TDM mode can be used.  Admittedly, this is a convoluted approach, but it might work if there are no other options possible:

    - Set McASP for TDM mode

    - Set XMOD to 32 (max number of slots)

    - Enable only the first slot  in XTDM register

    - Set FXWID to 1 (single word)

    After enabling the transmitter, use CPU to write ADS register data (write as many words as required).  After the last word is transmitted, disable the McASP transmitter.  This will hopefully get you the required signaling out of the McASP pins.

    It would be good to have a full description of the use case for the McASP and ADS.  In other words, aside from writing to the control register, what else is required?

    Gus

  • Tai,

    I tried to invert the Frame-sync and increase XDATDLY to delay the data.

    But as I see if I increase the XDATDLY, the width of the frame-sync looks to increase to 2 clock widths.

    Is this what you expect?

    Because as far as I understand from the timing diagrams in the McASP ref guide, XDATDLY= 1-bit should delay the

    transmit data by 1 clock. Is there something else that needs to be set?

    FYI, I am using CCS v4.2.3, DSP/BIOS 5.41 for C6713 DSP.

    Thanks,

    Aditi

  • Gus,

    Thanks for that reply. I will look try to do as you said and get back to you.

    As for the use, we have some Sensor data coming in (atleast 7-8 channels) that has to be sampled at a high rate

    (have 4 ADC's on the board).

    So we have used the ADS8556 in the design.

    To program the ADC, writing the control word to the register in ADS8556 the only thing

    After this task, I have to invoke the EDMA for data transfers.

    Will have more questions regarding EDMA once this thing works.

     

    Aditi.

  • Aditi,

    That is strange. I would not expect that. My understanding is the same as yours.

    I am asking another teammate who is more familiar with the McASP to look into this issue.

    Thanks for your patience.

    Tai

  • Gus,

    I have tried the procedure as you mentioned.

    Here are the steps I tried

    1) Change XMOD to 32 (for 32 slot TDM).

    2) Word size id 32-bit

    3) Set XBUSEL = 1 to use configuration bus

    4) XTDM = 1 (only first slot is active)

    Here is the step of sequence that I am doing


    Initialize the McASP, Enable the serial clock, take the transmit state machine out-of-reset,

    enable Framesync, send the control word, reset the transmit state machine.

    In the first place, will this work?

    This is what I found

    1) XCLKFAIL bit as well as XUNDERRUN bit are being set. I am using the internal clock so the external AHCLKX pin of the McASP is no-connect.

     

    Please let me know if the procedure is correct

    or if there is anything else that needs to be looked at please let me know.

     

    Thanks,

    Aditi.

  • Gus,

    A quick question.

    If I write to the XSTAT register the bits should be reset (please check page 113 of SPRY041J).

    I am doing this

    *(volatile uint32_t *)(MCASP1_ADDR + XSTAT) = 0x000000F7;

    basically to clear all the status bits.

    Even after doing this, the XSTAT register still shows a XCKFAIL =1.

    What does this mean? Where do I look?

    Thanks,

    Aditi.

  • Aditi,

    You can ignore XCLKFAIL for now.  It deals with specific clock failure logic in the McASP which you are likely not using right now.  The XUNDERRUN status may be due to the serializer register not having any data at the time you enable the transmitter.  Try writing a value into XBUF before enabling frame-sync.  

    Gus

  • Gus,

    Here is what I am doing

    Init_McASP();

    MCASP_enableClks(hMCASP_XMT);

     *(uint32_t *)(MCASP1_ADDR + GBLCTL) &=0x00000800;    //enable Xmt state machine

     MCASP_enableFsync(hMcasp, MCASP_XMT);


       *(volatile uint32_t *)(MCASP1_ADDR  + XBUF6) = out_data;

     *(uint32_t *)(MCASP1_ADDR + GBLCTL) &= 0xFFFFF7FF;    // reset the Xmt state machine

     

    Let me know if the procedure is correct and if this should work.

    Thanks,

    Aditi.

  • Aditi,

    The init sequence is actually give in the McASP user guide (see section labeled Transmit/Receive Section Initialization).  The frame sync enable should be done as the last step.  Let us know if you are getting any activity on the serializer output pin.

    Gus

  • Gus,

    I have followed the McASP user guide (transmit/receive section guidelines).

    As you can see above, the framesync is enabled just before writing out data to the serializer.

    I am able to see the control word along with the framesync. Looks correct, but just want to confirm from you guys.

    Because after transmitting the control word, I disable the transmit state machine. Will this help ?

    And not send another word of all 0's ?

    Please confirm.

    Aditi.

  • Aditi,

    Aditi Akula said:
    I am able to see the control word along with the framesync. Looks correct, but just want to confirm from you guys.

    Good to hear you are seeing the correct signals on the McASP pins.

    Aditi Akula said:
    As you can see above, the framesync is enabled just before writing out data to the serializer.

    Write the data to the serializer before enabling the frame sync, otherwise you run the risk of getting an under run error.  

    Aditi Akula said:
    Because after transmitting the control word, I disable the transmit state machine. Will this help ?

    Poll the XRDY bit before resetting the transmitter.  Actually, I would recommend you disable the frame sync generator as well to avoid generating further frame sync pulses to the A/D.

    Gus