TMS320F28335: McBSP configuration for SPI speed issue

Alice

Expert 4485 points

Part Number: TMS320F28335

Tool/software:

Hello，

Good day!

There is customer's issue, could you help? Thank you so much.

I would like to inquire about the speed issue after configuring McBSP as SPI.

I observed a delay of about 550ns from the moment data is written to DXR1 to when the data is actually sent out on the bus using an oscilloscope.

I couldn't find specific information in the manual regarding what causes this delay.

The oscilloscope image is as follows: The first falling edge of the blue line indicates the moment data is written to DXR1, the pink line is MCLKXA, and the yellow line is MDXA, with a baud rate configured at 9.425MHz.

I mainly want to understand: 1) What causes the delay? 2) Can the delay be reduced to improve bandwidth utilization?

Uint16 McbspBSpiTxRx8Bit(Uint16 txByte)
{
Uint16 rxByte = 0U;
Uint16 i = 0U;

while((gMcbspbRegs.SPCR2.bit.XRDY == 0U) && (i < MCBSP_TIMEOUT_LOOP_CTRL_200))
{
DELAY_US(MCBSP_DELAY_TIME_100NS);
i++;
}
gMcbspbRegs.DXR1.all = txByte & 0xFFU; /* send data */

i = 0U;
while((gMcbspbRegs.SPCR1.bit.RRDY == 0U) && (i < MCBSP_TIMEOUT_LOOP_CTRL_200))
{
DELAY_US(MCBSP_DELAY_TIME_100NS);
i++;
}
rxByte = gMcbspbRegs.DRR1.all & 0xFFU; /* receive data */

return rxByte;
}

       MCBSP配置代码如下：

Uint16 McbspConfig(volatile struct mcbsp_regs_t *mcbsp, const TY_SPI_CONFIG *config)
{
mcbsp->SPCR2.all = 0x0000U; /* Reset frame synchronization generator, sample rate generator, transmitter */
mcbsp->SPCR2.bit.FREE = 1U; /* debug, when a breakpoint is encountered, the transfer clock continues to run */
mcbsp->SPCR1.all = 0x0000U; /* Reset receiver, right set word, turn off digital loopback */

mcbsp->PCR.all = 0x0F08U; /* Configure as master */
mcbsp->RCR2.bit.RDATDLY = 1U; /* The data receiving delay bit is set to 1 on the master */
mcbsp->XCR2.bit.XDATDLY = 1U; /* The delay bit for sending data is set to 1 on the master */

mcbsp->SPCR1.bit.DXENA = 1U;

mcbsp->SPCR1.bit.CLKSTP = ((0xA >> 2U)& 0x03U); /* Get the second or third bit */
mcbsp->PCR.bit.CLKXP = ((0xA >> 1U) & 0x01U); /* Get the first bit */
mcbsp->PCR.bit.CLKRP = (0xA & 0x01U); /* Get the 0th bit */

mcbsp->MFFINT.bit.XINT = 0u;
mcbsp->RCR1.bit.RWDLEN1 = 0; /* Configure the word size to receive data, macros available */
mcbsp->XCR1.bit.XWDLEN1 = 0; /* Configure the word size to send data, macros available */
mcbsp->SRGR2.all = 0x2000U; /* Determine the value,CLKSM=1, frame synchronization pulse period FPER =1 CLKG period */
mcbsp->SRGR1.all = 7; /* Used to configure clock rate CLKG and CLKG cycle pulse width */
/* CLKG periodic pulse width defaults to 1 sampling period */
DELAY_US(MCBSP_DELAY_TIME_1US);
mcbsp->SPCR2.bit.GRST = 1U; /* Enable the sample rate generator */
DELAY_US(MCBSP_DELAY_TIME_1US);
mcbsp->SPCR2.bit.XRST = 1U; /* Enable sender from reset */
mcbsp->SPCR1.bit.RRST = 1U; /* Enable the receiver from reset */
mcbsp->SPCR2.bit.FRST = 1U; /* Enable frame sync generator from reset */
}

6 months ago

0 Benjamin Collier 6 months ago

TI__Mastermind 36526 points

Hi,

Our expert is currently out of office, please expect a reply at the end of this week.

Best Regards,

Ben Collier

0 Alice 5 months ago in reply to Benjamin Collier

TI__Expert 4485 points

Hello，

Thanks for your response.

Please update here if you have any suggestion.

In addition, the customer want to know:

Is there any relevant statistical data on the maximum effective bandwidth after testing the McBSP configured in SPI mode?

0 MatthewPate 5 months ago in reply to Alice

TI__Guru* 81560 points

Alice,

Can we ask what the McBSP clock is running at in the above? Max is 25MHz.

Looking at the delay, it is ~300ns. Assuming the C2000 is running 150MHz, this is ~50 clock cycles of delay. However, if we put that into McBSP clock cycles it is ~7.5 clocks. I still think this seems a bit much, i.e. I might expect there to be some delay of 1 to 2 clocks in the McBSP domain depending when the data is written by the C28x, something like 40-80ns, again assuming McBSP is at 25MHz.

Let's see what customer says on the McBSP clock and then we can see if this delay makes more sense.

Best,

Matthew

0 Alice 5 months ago in reply to MatthewPate

TI__Expert 4485 points

Hello Matthew，

Thanks for your support.

Please check the customer's reply:

The DSP operating frequency is 150MHz, Lspclk is 75MHz, and SRGR1.CLKGDV is configured to 7, so the calculated result clock should be 9.375MHz.

As you mentioned, it is currently uncertain which part introduces the delay, and why the delay is so large.

Additionally, the delay time observed on the oscilloscope is approximately 500ns.

0 MatthewPate 5 months ago in reply to Alice

TI__Guru* 81560 points

Alice,

Thanks for this, so at 9.375MHz, the McBSP period is 107ns. So we are seeing ~5 McBSP clock cycles of delay, assuming 500ns from GPIO pulse to data start.

In terms of delay in writing the register from the C28x to McBSP to initiate code, I think we could expect 1-2 McBSP clock cycles depending on the clock alignment between the core and McBSP. So we still have ~3 clock cycles(~320ns) of delay to understand.

Is the code running from Flash or RAM? If flash, then the code execution would have some extra delay based on the flash waitstates setting(I believe min is 3 WS), if from RAM then it won't have that lag.

Essentially, I'm trying to see if the GPIO pulse may appear to be further delayed due to code execution reasons, etc.

Best,

Matthew

0 Alice 5 months ago in reply to MatthewPate

TI__Expert 4485 points

Hello Matthew,

Thanks for your support.

Please check the customer's reply:

The code runs in RAM.

Do you have evidence for the 1-2 McBSP clock cycle delay you mentioned?

Why would there be a delay of 2 McBSP clock cycles?

Could the allocation of code in L4-L7 SARAM and L0-L3 SARAM introduce a delay of 200-300 ns in execution time?

I feel that L4-L7 SARAM should not introduce such a significant delay.

Please assist in analyzing this, thank you.

0 MatthewPate 5 months ago in reply to Alice

TI__Guru* 81560 points

Alice,

I'm basing the 1-2 McBSP delay on the difference in clock domains and a worst case assumption that when the write to the McBSP transmit happens from CPU we fall on the clock immediately after the local McBSP clock has transitioned.

Code being in RAM is best, so we can eliminate flash waitstates as a potential timing issue.

Just so we are on the same page, are there any other system interrupts that may be coming in, like from ADC/etc that would delay the write? Or for the sake of this debug, should I consider that only McBSP/C28x is active.

Best,

Matthew

0 Alice 5 months ago in reply to MatthewPate

TI__Expert 4485 points

Hello Matthew，

Thanks for your support.

The customer have some confusion, please help to clarify, thank you so much.

MatthewPate said:
when the write to the McBSP transmit happens from CPU we fall on the clock immediately after the local McBSP clock has transitioned.

How should this sentence be understood? Does it mean that the CPU clock and the McBSP clock are asynchronous, or does it mean something else?

2 When validating the McBSP function, all interrupts are in a disabled state; additionally, the writing delay you mentioned refers to the time taken by the application to write to DXR1, right? From the oscilloscope's perspective, the current delay is related to the delay in data transmission after writing to DXR1, rather than the application writing to DXR1.

MatthewPate said:
Or for the sake of this debug, should I consider that only McBSP/C28x is active.

How should this sentence be understood?

0 Alice 5 months ago in reply to Alice

TI__Expert 4485 points

Hello,
Good day!
Please update here if you have any suggestion, thank you so much.

0 Alice 5 months ago in reply to Alice

TI__Expert 4485 points

Hello，

Good day!

Regarding the customer's reply, the customer is waiting for further support.

Please update here if you have any suggestion, thank you so much.

0 Alice 4 months ago in reply to Alice

TI__Expert 4485 points

Hello，

Good day!

Regarding the customer's reply, the customer is waiting for further support.

Please update here if you have any suggestion, thank you so much.

0 MatthewPate 4 months ago in reply to Alice

TI__Guru* 81560 points

Alice said:
1

MatthewPate said:
when the write to the McBSP transmit happens from CPU we fall on the clock immediately after the local McBSP clock has transitioned.

How should this sentence be understood? Does it mean that the CPU clock and the McBSP clock are asynchronous, or does it mean something else?

They are not asynchronous, since McBSP clock is derived from the CPU system clock; but McBSP clock is divided down value from CPU clock. So it may happen that write to McBSP registers which is initiated from the CPU domain comes in between McBSP clocks; giving rise to a delay

Alice said:
2 When validating the McBSP function, all interrupts are in a disabled state; additionally, the writing delay you mentioned refers to the time taken by the application to write to DXR1, right? From the oscilloscope's perspective, the current delay is related to the delay in data transmission after writing to DXR1, rather than the application writing to DXR1.

Yes, but the CPU/instruction that sets the GPIO will come at least 1 SYSCLK before the write to DXR1 based on the pipeline of the C28x CPU. But to be fair this is only a few CPU clocks of delay at 150MHz

Alice said:
3

MatthewPate said:
Or for the sake of this debug, should I consider that only McBSP/C28x is active.

How should this sentence be understood?

I meant that the code isn't doing anything else, like ADC ISR or something that may be stalling the write of data to DXR.

Best,

Matthew

0 Alice 4 months ago in reply to MatthewPate

TI__Expert 4485 points

Hello Matthew，

Thanks for your support.

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28335: McBSP configuration for SPI speed issue