SPI non-DMA max speed ?

[Gossamer]

I am communicating with a TFT LCD and trying to speed things a little bit. At the moment I dont have DMA library written, so I am using standard SPI mode.

I configured the SPI clock as 5Mhz on STM32F407 mcu.

My main clock is PLL on 96Mhz. With APB2 = 2 and APB1 = 4.

Not sure if relevant, but Flash latency is 6 CPU cycles.

Gpio port output speed on CLK,MISO,MOSI is set to Highspeed. (no difference with low speed).

What I am seeing on the logic analyzer is the gaps between each SPI clock. Measuring one byte transmission speed, I am getting average of 300ish Khz instead of 5Mhz.

I only have one interrupt running in the code and that is Systick with 100us tick.

EDIT: One thing was definitely wrong in my setup. CPU WS latency. As my PLL clock is set to 96mhz and mcu works on 3.3v, I had to set 4CPU cycles WS instead of 6 that I originally had. Problem still persists.

[Nikita91]

How do you get a 5 MHz SPI clock from a 96 MHz sys clock ?

[Gossamer]

>What's the primary clock source?

I am using external 8Mhz crystal.

>Is this a "known good" board like Nucleo/Disco?

Board is custom made STM32F4 (should be genuine mcu)...

I will try to use SPI2 and see what I get there.

[Gossamer]

You are correct. While my code sets demand for 5Mhz clock, I actually set the 6Mhz instead. I got mislead by looking at the logic analyzer output seeing 5Mhz.

[S.Ma]

Starting debugging with a logic analyser instead of an oscilloscope is a red flag.

If I really want to break the HW shift register from operating, I would simply play with the clock itself, such as peripheral clock/enable/disable on the fly, which is also a red flag.

[MM..1]

I dont write on first post , that your code must be bad, i mean you underrstand.

Use CubeMX and set pins and function as spi . Then in main code use

 HAL_GPIO_WritePin(SPI_CS_GPIO_Port, SPI_CS_Pin, GPIO_PIN_RESET);

 HAL_SPI_Transmit(&hspi2, (uint8_t *)buff, 1, 5);

 SPI_CS_GPIO_Port->BSRR = SPI_CS_Pin;

[Gossamer]

>I dont write on first post , that your code must be bad, i mean you underrstand.

I think that assumption is correct and needles to state :) Chances that my code is good and there is a bug in hardware is 0 to none.

It is just matter of figuring out which part of the code is responsible for such behaviour.

[MM..1]

=) Chances that my code is good ... as you write without code only you can help you with your code