We use the 2812 DSP for motor control. We recently migrated to Delfino and have hit a problem with SPI timings.
The Delfino is about 1.7 times slower per byte. The added time occurs between the 8th clock cycle of a transmission and the 1st clock cycle of the next transmission. This part of the whole cycle takes 4 times as long on the Delfino
On 2812, the timings on the scope are:
280 ns time between chip-select going low and first clock cycle
749 ns time for 8 clock cycles
380 ns time between the 8th clock cycle of a transmission and the 1st clock cycle of the next transmission
160 ns time before chip-select goes high
On Delfino, the timings on the scope are:
640 ns time between chip-select going low and first clock cycle
760 ns time for 8 clock cycles
1220 ns time between the 8th clock cycle of a transmission and the 1st clock cycle of the next transmission
760 ns time before chip-select goes high
Tim,
Can you send a waveform? Is this the exact code you used on the 2812? If you're sending data consecutively I wouldn't expect STE to return high.
Kris
Hi Kris,
I had actually included the wave form in the post but it got lost somehow.
Here it is.
Yes, the code is exactly the same as on 2812.
Thanks Tim,
Can you tell me about the clocking for each system? This includes Sysclk, LSPCLK, and SPICLK.
I am Tim's colleague, a hardware engineer working on the same project. The answers to your questions are:
PLLCR = 6;
(50*PLLCR)/2 = 150MHz
LSPCLK = SYSCLKOUT/1
LSPCLK = 150MHz** (see note below)
9.375 MHz (SYSCLKOUT/(SPIBRR+1)
(150MHz / (15 + 1))
**Oh. I just nocticed that we are running LSPCLK at 150MHz in both cases which exceeds the maximum limit of 75Mhz as stated in the data manual. How did we get away with this?
LSPCLK operation at 150 MHz is not guaranteed which is why we say don't use it. This may be fine on some devices, but on the corners of the process you may run into a device where it causes problems. There is no way to know what will be in the shipment, just that it passed the appropriate tests during manufacturing. I don't think this is the source of the variation.
Do me a favor, for each device, toggle an IO when you load the SPITXBUF register, scope that out along with the data, and let's see how that waveform looks. Is this using the FIFO or no?
Thanks for your support so far Kris,
While we were trying to do the test you asked for, we realised that we have mistakenly placed one of our SPI-related functions in Flash (in 28335 code), whereas all other 28335 and 2812 SPI functions ran in RAM. Once we moved that function into RAM where it belongs, we got much more sensible timing figures.
It all makes sense... :)