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.

[wired]

I just tried doing a 2 second fade of my background image on my main screen. It actually took 11 seconds to complete (of course, my HCLK is 45 MHz). As I expected, there were jumps in the alpha value of each update, but nothing 'wrong' per se, with the screen.

I also tried setting my SYSCLK to 168MHz and changed divider back to 1, to be just like your configuration. My LCD-TFT clock is still 30 MHz, though. I added a 480x732 image and faded it in just fine, other than taking 5 seconds instead of 2.

[Tesla DeLorean]

Right, but the memory device and the STM32 both have to have a coherent understanding of the dummy cycles, the former being achieved by reconfiguring the device from the default it has. Make sure the BSP Init code does that.

>>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.

Perhaps the generated code doesn't account for clocking differences all the way down to the QSPI level? Or there's some differences in clock domains, and how the resynchronizers behave, and different beat frequencies and interplay that might occur with other bus users.

People that don't use the auto-gen tools typically have a better understanding of the clock trees and dependencies they've created. I tend to build code to unpack the PLL and Clocks so I can understand what should be coming out various pins if I were to scope them. Your QSPI case for 180/168 MHz would be a lot more powerful it the clock for the memory chips was also disclosed

The display clocks should have more wiggle room than the USB, 24 and 27 MHz might be more factorable within the constrains of ST's design.

[Exit0815]

I did not read about the known bug in the actual 4.19.1, thanks that is very good for me.

Yes, still using 480x800 display.

i tested several sizes, full size, 200x200 and so on. if i put a small image and fade it in i can see that other stuff on the screen also "flicker".

With flicker you are right, jumps in the alpha, brighter-darker but also a movement of the pixels of the complete screen. So some pixels up or down. Looks like a nice effect but it is not wanted.

The strange thing is that if i go with 180MHz everything is ok, i just change to 168MHz and the problem comes up.

I think i will go on creating a new project and test a bit more without using example project snippeds from the disco board.

[Exit0815]

Thanks a lot.

I want to understand all the clock stuff better, but for that i found it a nice way to start with the graphical gen tool and the IOC file.

But i will start a new project and try to do all the stuff manually. I have examples now where i can have a look.

[wired]

Regarding the bug I mentioned in 4.19 about slide transitions, it only applies to portrait mode. I realized I made an assumption about your configuration, so looked back at your original post and didn't see what mode you were in. The post pertaining to the bug is here.

[Exit0815]

Alright thanks. My config is:

Landscape 800x480 DSI Video Mode (Burst) RGB888

Display does not have TE signal like the original on the disco board had.

I should realy start complete from scratch to get rid of all that example stuff 🙂