Change SYSCLK from 180Mhz to 168Mhz - effect on Framebuffer if placed in external flash (dummy cycle issue?)

[Exit0815]

Hello,

I am using the STM32F469 Disco with a custom display connected.

Everything wiorks fine.

Now i want to use the USB Port, which needs 48Mhz.

For that i had to change the SYSCLK to 168 which was 180 Mhz originally.

Everything works still fine, but when i do a fade-in of a picture, it flickers.

Then i was looking to the Datasheet of the SDRAM N25Q128A and on some other websites i found that this may be a problem of the dummy cycles which needs to be changed.

APB1 was 90Mhz with 180 Sysclk and now i have 84Mhz.

This are the parameters in the header file of the N25Q128A:

#define N25Q128A_DUMMY_CYCLES_READ           8
#define N25Q128A_DUMMY_CYCLES_READ_QUAD      10

I played around, increase by 1, decrease by 1 and so on, no better result. Still flicker during a fade-in of a picture (Alpha from 0 to 255).

In the "stm32469i_discovery_qspi.c" there is the "s_command.DummyCycles" in every function like read, write, erase.... which is mostly set to 0, only in "Read" and "EnableMemoryMappedMode" is is linked to the "N25Q128A_DUMMY_CYCLES_READ_QUAD" define.

If i change back to 180Mhz Sysclk which gives me 90 Mhz it works. But i need the 48 Mhz for the USB so 168 needs to be set up.

Does anyone had the same problem and a solution or can explain the effect on changing the clock to other peripherals?

Thanks a lot.

[Tesla DeLorean]

Not an SDRAM

Y​ou know the QSPI has its own ClockDiv right? You can slow that down independent of the CPU/BUS clock.

W​ould want to confirm dummy cycles match memory side configuration. These cycles allow for an initial fetch to prime the buffers for a sustained data transfer at high speeds.

[wired]

FYI, I left my SYSCLK at 180 MHz, and lowered my HCLK to 45 MHz using the AHB1 Prescaler, and my fades don't flicker (but I'm not doing any full-screen fades). Not using the PLL48CLK, though.

Fades are very processor-intensive - do you have the same flickering with smaller pictures?

[Exit0815]

Like always, not SDRam right :)

I have not known that QSPI has its own ClockDiv. I just could see its own prescaler which is based on the AHB clock.

Specifies the prescaler factor for generating clock based on the AHB clock.
This parameter can be a number between 0 and 255

But what is my AHB clock? isnt it 168Mhz?

Well, now it seems that i do have a big problem understanding the QSPI clock. I thought it uses the APB1 frequency.

 

  /* QUADSPI parameter configuration*/
  hqspi.Instance = QUADSPI;
  hqspi.Init.ClockPrescaler = 1;
  hqspi.Init.FifoThreshold = 1;
  hqspi.Init.SampleShifting = QSPI_SAMPLE_SHIFTING_HALFCYCLE;
  hqspi.Init.FlashSize = 27;
  hqspi.Init.ChipSelectHighTime = QSPI_CS_HIGH_TIME_5_CYCLE;
  hqspi.Init.ClockMode = QSPI_CLOCK_MODE_0;
  hqspi.Init.FlashID = QSPI_FLASH_ID_1;
  hqspi.Init.DualFlash = QSPI_DUALFLASH_DISABLE;

[Exit0815]

Thank you for your answer.

Yes, on 180 MHz i do not have any problems. But i need to activate the USB and this needs 168 MHz, so the only way to get that is this setup:

 

I tested fullscreen fades and smaller ones. On smaller ones the whole screen got some "flickers" during the fade. Wipe transitions are ok.

[waclawek.jan]

If LCD_TFT clock could be lowered somewhat to 24MHz (I don't know what are the ramifications of this), 48MHz USB clock could be generated in PLLSAI, while retaining the 180MHz sysclk generated in "main" PLL.

JW

[Tesla DeLorean]

Can't you generate the 48 MHz clocks via the PLLSAI ?

Slow down the QSPI bus clock

hqspi.Init.ClockPrescaler = 1; // Make BIGGER, ie 2

 

[wired]

Yes, my point was only that all of my clocks driven off of HCLK are much slower than yours, and I have no issues with the display. My LCD-TFT clock was unchanged, at 30MHz, from using PLLSAI. I agree with others, definitely worth trying to get 48MHz from that.

[Exit0815]

Unfortunately my display works only perfect with 26MHz, i already tested for hours to play with the values of the display to get it working without strange behavior but i had no success.

But what are you guys thinking when everything works good with 180 MHz and with 168 MHz the display has problems only with stuff like fade-in functions.

Other movements like wipe/swipe (except slide transition, there i still have a lot of problems with a clear picture but not important now) work perfectly.

Changing from 180 to 168 MHz and some flickers at the screen during fade-in should be something wrong with the external memory (framebuffer) ?

I found this in one git repo:

/*
 * Read a sector from the flash chip (4K bytes)
 *
 * The Quad SPI peripheral starts when you write the
 * address register. 
 *
 * From the Data sheet for the flash, fast read needs
 * 7 dummy cycles at 86Mhz, 8 at 95Mhz. Since we're at
 * 168Mhz/2 = 84Mhz we're using 7. But if we went to 180/2
 * we would set it to 8.
 */

but it is complete different to the hal qspi i am using from the 469 disco board.

I will give it a try to use this one and see what happens.

[wired]

With respect to your slide transition, FYI if you are using 4.19.1 of the Designer there is a known bug when swipe transitions are used.

Is your screen size still 480x800? And when you say flickers, are you getting partial screen artifacts or is it just not 'smooth' fade, like you are missing some alpha value updates? Maybe the render time is causing you to skip frames. What is the size of image you are trying to fade?