McBSP as SPI not working sometimes... what could I check?

James Thorton

Hello, I have McBSP on evmdm6437 working as SPI slave, and sometimes it is not working properly, sometimes, when it receives clocks from the master, he does not read the data or transmit anything, it is like it is in reset state for a while, and an instant after he just "wake up" and begin to work properly. It only happen in some transmittion, for example, I need to do 4 transmissions:

           -First and second are achieved perfectly

          -Third needs a lot of clocks (for example, I need to transmit like 100 bytes, and it needs like 4000 bytes before start transmit) from the master until McBSP "wake up" and begin to serve the transmision well

          -Fourth transmission works without problems.

Regarding your transmission, would you be able to clarify what you mean by transmission?  Is this just a single value, like a 8-bit byte, or something similar?  Or does a transmission mean a series of bytes sent in one frame.  The next transmission would then be defined as the next series of bytes in another frame, etc?

James Thorton

        And always fails in the third transmission. I have checked all the McBSP registers in the middle of a "bad" transmission (when McBSP is not able to read either transmit), and are equal to a good transmission. I have checked pinmux registers and no changes either. So it looks like everything is just the same, but not working well in that third transmission.

      More data: I use Edma to server the McBSP and I am integrating this McBSP transmissions in a third part application, so probably this malfunction is caused for that "external code", but I wonder what registers could I check because, it is not like the transmission is not working, because if my EDMA channel was not serving well the McBSP, I still would be able to read the DRR register in the middle of a bad transmission. I mean:

         -I stop when McBSP is not working well in the third transmission. Just in the middle of that "bad" transmission. Master is sending always 0x55, for example, and I just read in DRR the last byte of the second transmission, not 0x55. So is not EDMA fault, it is like the McBSP would be in reset state; but again, I can tell that the registers of McBSP are with no changes and McBSP is not in reset. If I write at that moment something in DXR, anything is tranmitted either.

       -I am quite sure that the McBSP is well configured, as I have check it for a long transmission with the master in another application and works without no error in a very long transmission.

In this other application, is the McBSP configured as a slave as well?  If so, are you indicating that this other application does not have any transmission issues that are you currently reporting?

              Thanks for your interest Bradon, my transmission are only 8bits, so only 1 frame and 1 byte (8 bits), but I transmit a lot of bytes in one step (like 20, 80, 100, it depends about the message transmitting), and then wait for awhile, and then a new transmission start. And as I say, third needs a lot of clocks to finally start sending the "real" data (before of this, there is no any transmitted)

              The other application that I said, use the same configuration code for McBSP, and it is configured as slave too. It is doing the same thing, but without anything more. Now I am integrating this code in a third application, and that's when I'm getting trouble.

              So, my main question, is what register should I check to see that McBSP is properly configured and working well. I have checked McBSP registers, and Pinmux... what else could I look for? And just in case someone is thinking about maybe is related with powerdown or something like that, I do not think that could be related with the power module, as the application is running on the evaluation board where the power management is not really important.

Thank you

We can certainly look at how you have configured the McBSP, that would help provide some background information.

In your original post, you mentioned using the EDMA to service the McBSP.  How do you have this configured?  In particular, since you are sending various size frames of data across, how does the McBSP and EDMA interpret this?  Do you service just every byte of data, or do you process in blocks?

       Hello again, here is the configuration that I use. I only transmit 1 byte every frame (= 8bits per frame). I just reused some code example from texas. But as I said I don't think it is a McBSP configuration problem, as it works well inside a simple program (I did long time transmissions without any issue with this simple program). The trouble comes when I try to integrate in my third part application (which no use McBSP for anything, which is still weird).

void device_init2(void)
{
  CSL_PscRegsOvly pscRegs = (CSL_PscRegsOvly)CSL_PSC_0_REGS;

  // deassert MCBSP0 local PSC reset and set NEXT state to ENABLE
  pscRegs->MDCTL[CSL_PSC_MCBSP0] = CSL_FMKT( PSC_MDCTL_NEXT, ENABLE )
                                 | CSL_FMKT( PSC_MDCTL_LRST, DEASSERT );
 
  //move MCBSP0 PSC to Next state
  pscRegs->PTCMD = CSL_FMKT(  PSC_PTCMD_GO0, SET );
 
  //wait for transition
  while ( CSL_FEXT( pscRegs->MDSTAT[CSL_PSC_MCBSP0], PSC_MDSTAT_STATE )
          != CSL_PSC_MDSTAT_STATE_ENABLE );
}


void init_mcbsp(void)
{
  //serial port control register SPCR
  mcbspRegs->SPCR = CSL_FMKT(MCBSP_SPCR_DLB,DISABLE)    //disable loopback mode   
                  | CSL_FMKT(MCBSP_SPCR_CLKSTP,NODELAY);
                
  // receive control register               
  mcbspRegs->RCR = CSL_FMKT(MCBSP_RCR_RWDLEN1,8BIT);   //receive word 8bit
 
  //transmit control register
  mcbspRegs->XCR = CSL_FMKT(MCBSP_XCR_XWDLEN1,8BIT);   //trans word 8bit
 
  //sample rate generator SRGR
  mcbspRegs->SRGR = CSL_FMKT(MCBSP_SRGR_CLKSM,INTERNAL) //internal clock
                  | CSL_FMK(MCBSP_SRGR_CLKGDV,0x01);      //clock divider value

  //pin control register
  mcbspRegs->PCR = CSL_FMKT(MCBSP_PCR_FSXM,EXTERNAL)    //internal frame sync
             | CSL_FMKT(MCBSP_PCR_SCLKME,NO)  //=0
                 | CSL_FMKT(MCBSP_PCR_CLKXM,INPUT)    //trans clock mode
             | CSL_FMKT(MCBSP_PCR_FSXP,ACTIVELOW) //FSXP=1
         | CSL_FMKT(MCBSP_PCR_CLKXP,RISING); //

  //start the mcbsp running
  CSL_FINST(mcbspRegs->SPCR,MCBSP_SPCR_RRST,ENABLE);    //receiver enable
  CSL_FINST(mcbspRegs->SPCR,MCBSP_SPCR_XRST,ENABLE);    //transmitter enable
  CSL_FINST(mcbspRegs->SPCR,MCBSP_SPCR_GRST,CLKG);      //SRGR out of reset
  CSL_FINST(mcbspRegs->SPCR,MCBSP_SPCR_FRST,FSG);       //enable frame sync

}

regards

Your third party application may be trying to use the same edma channel as the McBSP.  Try running your code without touching the edma channel, then check for activity/changes in that channel when your third party app runs.

Yeah, I had supposed that too in the beginning. But the application ONLY use edma for acpy3, and use a typical configuration, see below:

DMAN3.paRamBaseIndex = 78;
DMAN3.numQdmaChannels = 8;

So, I guess it is only using param 78 to 86, right? And to serve mcbsp there is only edma channel 2 and channel 3, so I do not see any conflicts here.

Plus, I have checked too that in the middle of a bad transmission, I am only to read '0x00' instead of '0x55' (the master is always sending this byte) in the McBSP drr register. So I assume that is McBSP trouble, and not related with edma.

And as channel 2 and channel 3 are only for servicing McBSP, and the third application do not use this harware I still have found this problem stranger and not related with EDMA.

So, as I said what my plan is watch registers in the middle of a bad transmision, but I do not know if I still need to look more registers apart from McBSP and PINMUX register to certify that mcbsp should be working well. suggestions?

Thank you

Is there anything connected to CLKR or FSR on the evm?  I see a note on page 49 of spru943c that says these lines are not used in the clock stop mode b/c they are internally connected to their transmit counterparts, clkx & fsx.  I wasn't sure exactly what this meant, so I left those pins unconnected on my hw and haven't had any problems.  Any chance you have something attached to those lines (gp101 and gp102) that gets driven during your problem?

Thanks for you interest Matt, but unfortunately they are unconnected as you do. By the way, I do not think that it could be a hardware issue, as the problem always fails in the third transmission (and this third transmission do not have anything different to previous, so it is not a problem of my code). I think the application is doing something it just that moment, that indirectly affects to McBSP, but I can't imagine what could be (as I said, pinmux for example are unchanged). Very weird...

I still stuck in this point, but I have some news:

I have checked SPCR just before a transmission start and it seems that when SPCR=0x00C31007 the transmission does not start. The transmission starts right when SPCR is equal to 0x00C51007. In other words, when XRDY=1 (transmiter ready for new data in DXR) and XEMPTY=0 (XSR is empty) it works well. But if the previous state is the opposite, XRDY=0 (transmiter not ready) and XEMPTY=1 (XSR is not empty) does not run.

This "bad" SPCR state always happen in my third transmission, but if I place a breakpoint before this third transmission I check SPCR register, it shows 0x00C31007, ok, and then I write any data in  DXR via CCS registers, then SPCR turns to 0x00C51007, and transmission works now.

Could someone give me a hint about what could be happenning?

Thank you

EDIT: it looks like XRDY already generated a XEVT that edma does not registered and then not serviced, then as edma not write again in DXR mcbsp could not generate the next XRDY and XEVT. Does this theory has any sense? The ER (event register of EDMA) shows only 0 in the bits of recpectionand transmission mcBsp

Looks like the dma is not keeping up with your transmission.  I say this because the receive overrun bits are set in your spcr.  If the dma channel servicing the mcbsp is locked out by another channel on the same transfer controller or on the same endpoint, it will not service your mcbsp peripheral.  I'm not sure what the behavior is after a miss like this, but that sure sounds like your problem.

Oh, I did an error writting the previous post. I do not have receiver overrun bits, it is not 0x00C51007, it is 0x00C51001. I obtain the 7 in a later issue, not related with this. The key is the 17 and 18 bits (XRDY and XEMPTY). I still can't imagine what can be cause this malfunction

James,

Did you ever solve this problem? We are observing similar symptoms in a TMS320DM6437 project and I would be very interested in any solutions you may have discovered since your last post.

James Thorton

Oh, I did an error writting the previous post. I do not have receiver overrun bits, it is not 0x00C51007, it is 0x00C51001. I obtain the 7 in a later issue, not related with this. The key is the 17 and 18 bits (XRDY and XEMPTY). I still can't imagine what can be cause this malfunction

Dear Sir,

I met the same problem as you, have you resolved this problem?

Hi,

did any body ever solved the issue ? is it possible to run the EDMA mode of SPI on DM6437 without any error?

I am facing similar kind of issue with interrupt mode. ..in http://e2e.ti.com/support/embedded/bios/f/355/t/177501.aspx. 

I feel the issue I am facing might be differrent one to this one but hoping for some inputs.

It would be great if any TI person can share some update on these issues.

many thanks

regards,

Sri