C5502 SPI performance problems

Hi,

I'll follow up your question. I need more information from you.

1. Are you using your custom hardware?

2. What version of CCS are you using?

3. Can you tell me your Cogen tool version and BIOS version?

Regards,

Hyun

Hi,

1- Yes is a custom hardware. The SPI slaves, some are COTS, some are custom.

2- CCS 3.3

3- CodeGen v3.3.2, BIOS 5.41

Thanks,

Sebastien.

Hi,

Thanks for your info. One more question, are you using DMA?

Regards,

Hyun

Double-check that you've met every requirement listed in Table 6−3. Bit Values Required to Configure the McBSP as an SPI Master.

Hi,

No DMA, I tried two method to wait for the McBSP:

1- Interrupt and SEM. SPI thread SEM_wait. SEM is posted with HWI from McBSP when X/R Ready.

2- Polling. While loop waiting for the X/R Ready bit from McBSP register.

Thanks

Sebastien.

I re-check the McBSP registers and did not find anything wrong. Here the values:

SPCR1 0x3000

SPCR2 0x0100

PCR 0x0F0C

RCR1 0x0000

RCR2 0x0001

XCR1 0x0000

XCR2 0x0001

SRGR1 0x00FF

SRGR2 0x2000

Can you post your SPI_wait() code and some screenshots of what you see on a scope?

You might also check out this wiki page:

http://processors.wiki.ti.com/index.php/SPI_Boot_on_5502_EVM#Writing_the_Image

That code programs the SPI flash on the 5502 EVM using the McBSP.  I didn't even use CSL in that code.  Instead I created my own header files.  I don't recall seeing any large delays like you are experiencing.

I tried 2 different version of SPI_wait():

Interrupt:

void SPI_Wait (MCBSP_WaitType WaitType)
{
   switch (WaitType)
   {
      case XRdy:
         SEM_pendBinary(&sem_mcbsp0_xrdy, SYS_FOREVER);
         break;
        
      case RRdy:
         SEM_pendBinary(&sem_mcbsp0_rrdy, SYS_FOREVER);
         break;

      default:
         break;
   }
}

Void C55XX_SPI_READY_TO_WRITE_isr(void)
{
   XINTCount++;

   SEM_postBinary(&sem_mcbsp0_xrdy);

   IRQ_clear(xmtEventID);
}

Void C55XX_SPI_READY_TO_READ_isr(void)
{
   RINTCount++;
 
   SEM_postBinary(&sem_mcbsp0_rrdy);

   IRQ_clear(rcvEventID);
}

Polling:

void SPI_Wait (MCBSP_Handle   Handle, MCBSP_WaitType WaitType)
{
   switch (WaitType)
   {
      case XRdy:

         while( !MCBSP_xrdy(Handle)) {};
         break;

      case RRdy:
         while ( !MCBSP_rrdy(Handle) ) {};
         break;

      default:
         break;
   }
}

For the screen shot, I use a old logic analyser. I see what I can do to extract something from it

Thanks,

Sebastien.

What kind of improvement did you see (if any) going from semaphores to polling?  I would expect all the semaphore task switching to delay by several hundred CPU cycles, but since the CPU is so much faster than the SPI it should not be nearly as large as you see.

Hi,

I experimented above McBSP_SPI write program. I see about 36 SPI clock cycles between SPI access.

              offset = 0;

              while (1) {

                             spiflash_write_byte(offset, 0x0F);

                             spi_val = spiflash_read_byte(offset);

                             spiflash_write_byte(offset, 0x36);

              }

You can also try this program to check your SPI. 

Regards,

Hyun

Thank you both for your inputs.

I have now a 8 usec  delay between 2 SPI write. The problem wasn't the McBSP but scheduling of the BIOS. To get 8 usec, I used polling within SPI_wait and I disabled HWI between the transactions. This won't be the final solution but now I know where to look to optimize it.

Thanks again,

Sebastien.