TMS320F28P659DH-Q1: SPI SIMO single follow the PTE

Kita,

I'm looking into this and will get back to you shortly.

Regards,
Jason Osborn

Kita, the behavior we're seeing in that waveform, where PICO goes high before PTE even goes low, is definitely unexpected.

Is PTE the built-in hardware functionality of the C2000 SPI, or is it a manually generated chip-select signal? If it is the latter, then this is likely an issue with SW timing.

Regards,
Jason Osborn

Hi Jason,

This is a manually generated chip-select signal. But when SOMI is driven as high, there is no clock signal. I am not clear why this is issue with SW timing.

Could you check this?

Best Regards

Kita

Hi Jason,

I have reproduced this issue with built-in hardware functionality of the SPI, first send the 0x0000, then send the 0xAAAA. If the sending data is 0xAAAA, the first bit is high, then the PICO and POCI are pulled up prematurely before the clock and PTE starts. 

The waveforms are PICO, POCI, CLK, PTE, GPIO36 from top to bottom. GPIO36 is toggled before SPIA and SPIB send out the data. 

Please help to check with design team.

I want to know the reason why POCI and PICO will change before PTE and clock starts. I also need to know when will the PICO and POCI will change. Is this time related to PTE enable time or is random?

I attack my test code here. 28P65 SPI DEMO.zip

Because this is an very urgent case, please check this and response today!! 

Thanks!

Best Regards

Kita

Kita,

• To answer the question on why PICO is valid before the clock: The current SPI clock configuration is Mode 1: Rising edge with delay. Refer to the following image from the SPI section of the device TRM:
  • 
  • It is expected behavior that POCI/PICO change before the SPI CLK.
    • Section 6.15.7.1.2 of the device datasheet shows the timing between PICO being valid and SPICLK being valid, based on the odd/even polarity of BRR+1.
      • 
        
        
• To answer the question on the relationship between PTE and PICO/POCI: Normally, I would say to refer to the device datasheet, which has spec information on the relationship between data, PTE, and the clock on both peripheral and controller side, but the relationship I'm seeing in your waveform appears atypical. Because this is an external loopback test, POCI should lead PICO, not the other way around- that doesn't make sense to me.
  • Additionally, you can note that based on the device datasheet, the delay time between PTE being asserted and CLK being valid should be measurable on the scale of ns (2*t_sysclk + 20 given min value), while your waveform shows something like 5us. That is, again, not typical.

I'm reaching out to see if we can track down the root cause of this, and have not yet heard back.

Regards,
Jason Osborn

Please note that my time zone is US CDT (GMT-5), and the timing of my responses will likely reflect this.

Hi Jason,

Do you have any feedback from team now? This is urgent case, please help to update today!

Thanks!

Best Regards

Kita

Hi Jason,

What I am asking is the time between A1 and A2, PICO go high timepoint->clk start.

In customer's test, PTE and PICO will work at the same time. PICO->CLK starts take 1.5 cycle.

Need your help to confirm this time.

Thanks!

 Best Regards

Kita