I have a project which is running GUIX + 64MB QSPI - W25Q64JVSSIQ (which is used to store only resources such as images and icons).
The problem is: the screen flickers if a particular gadget (a menu, a button, a text or something) is updated. After many trials and errors, I found out that the problem seems to be in a particular place of the QSPI region. If this gadget is stored there, then the screen will flicker when it is retrieved from the memory.
Here's what happens.
Say this is my GUIX project and whenever SCREEN_2 is used, it causes a flickering.
However, if I rearrange the order of the screens (by adding/removing another screen , or icon, text, etc - doesn't matter what as long as I modify their order), like the following:
Here, a NEW_SCREEN was added, which probably changes the address of where the images are going to be located in the QSPI.
However, now SCREEN_3 will flicker and SCREEN_2 won't cause flickering anymore.
This means that there is always one gadget that will flick the screen when updated. All I can do is randomly choose which one will.
If I "fix" one gadget (by moving it up/down the images table in the GUIX project), whichever other gadget gets this "bugged" memory location (NOT necessarily the same table position) is going to flicker.
I don't know why moving the memory location around causes this, but Is there any way to fix?
Changing the QSPI to another part number will help? Maybe one with less memory space (I don't need that much)?
- This is a custom board that I have, and I'm using the R7FS5D97E3A01CFC microcontroller
- This problem has never happened when I was using the internal flash (2 MB)
- The QSPI is using currently using only 3 MB of data
- Most of the gadgets NEVER causes flickering, wherever they are located in the screenflow. It is usually only a particular one.
- I couldn't find any other relation/explanation to what causes a particular gadget to flick, except the explanation above.
- I have tried with 3 other boards/displays and the results are the same
- Changing transparency settings (either GUIX or the image itself) doesn't help
- Changing the image type (JPG, PNG, etc) and its characteristics also doesn't help
The W25Q64JV is a 64M bit device, so 8MB . The W25Q64JV doesn't seem to support "Continuous Read Mode", whereas the W25Q64JV-DTR part from Winbond does support "Continuous Read Mode" (Continuous Read Mode is Winbond terminology, XIP Mode is the QSPI peripheral terminology for the same thing).
This means you can't enable XIP mode in the QSPI peripheral of the S5D9 when using the W25Q64JV, so the command will always have to be sent, which will add some extra clock cycles to the access to the QSPI device.
I'll try the part number you mentioned and as soon as I test it, I'll let you know if it worked or not.
Thanks a lot for the tip
I don't know how much of a difference it will make to the issue you are seeing. You will also need to modifiy the QSPI setup code in the BSP to enable XIP/Continuous Read Mode for the W25Q64JV-DTR.
Do you use the Dave2D in you GUIX project?
Jeremy said:Do you use the Dave2D in you GUIX project?
The only info I could find about Dave2D was in my Synergy Configuration as seen below.
However, in GUIX Studio, there is nothing about DAVE2D.
Do you want me to test something about this?
The Dave2D is used if it is set in the GUIX Studio project in Configure-> Project/Display->Advanced Settings if the 2D Drawing Engine is enabled :-
and in the e2studio project, in the Properties for GUIX on gx :-
What is the resolution of the LCD you are using? are you doing any rotation of the screen :-
These are my settings (800x480 resolution):
No screen rotation used.
The only difference I noticed is that I don't have PNG software decoder on. However, it is enabled now but makes no difference (still flickering in a particular widget).
The PNG software decoder is only required if you use PNG images in your project.
The LCD screen probably flickers because the GLCDC is suffering from Data underrun (i.e. it cannot fetch the data from the framebuffer in time to display it on the LCD). There is an interrupt associated with the data under run. The Dave2D could be taking too long to fetch the resources from QSPI, which is causing the GLCDC to suffer from data underrun.
Where is the framebuffer located, internal RAM or external memory (e.g. SDRAM)?
What is the framerate that the GLCDC is outputting the data to the LCD at?
Jeremy said:The PNG software decoder is only required if you use PNG images in your project.
Which is my case for all pictures and icons. So I'll leave it on
Jeremy said:Where is the framebuffer located, internal RAM or external memory (e.g. SDRAM)?
External - https://www.lapis-tech.com/en/semicon/memory/memory-product.php?PartNo=MSM56V16161NP
I noticed that, according to my calculations (2*800*480*16/8), the SDRAM is storing two framebuffers. However, how can I check if they are in fact being used?
I thought it would be here:
I noticed that my SDRAM is under a group called "Unitialized Data". Not sure if this is relevant.
Jeremy said:What is the framerate that the GLCDC is outputting the data to the LCD at?
Do you mean the clockrate?
If so, I couldn't find where it says the clock of this particular pin. However, I measured it with an scope and it is 30 Mhz.
By the way, you reminded me of something. I've set the Drive Capacity of most pins related to the LCD (all the RGB lines, LCD_CLK and some others, etc) to Low to help with EMI compliance (we were having trouble with certain digital frequency spikes and lowering the drive capacity totally removed them).
Not sure if this is relevant.
The GLCDC can use 1 of 2 clock sources, either the internal PLL, or an external clock. The clock source chosen is then divided down, and that clock is then used as the pixel clock (LCD_CLK). The clock source that is used as the source of the pixel clock, and the divider used is configured in the properties of the r_glcd driver.
The framerate of the LCD is based on the total number of pixels per frame, and the pixel clock frequency. To reduce the framerate, use a larger divider, or increase the total number of pixels per frame.
The data in the .sdram section is not initailised by default in an SSP project as the SDRAM is only used for image or graphics buffers, so it doesn't need to be initlaiised by the C runtime environment.
To check if the GLCDC is using the framebuffer in SDRAM that you have configured, you can check in the IO registers view while debugging the project, stop the execution, and look at the registers of the GLCDC, the registers GR1_FLM2 and GR2_FLM2 hold the base address of the framebuffer for each of the 2 graphics planes that the GLCDC has, though only one of the graphics planes of the GLCDC is actually used.
The driver strength of the LCD pins won't cause the GLCDC to suffer a data underrun, as I suspect a data underrun is the cause of the flicker on the LCD panel. To confirm that a data underrun is occuring, in the GLCDC driver, enable the Underflow Interrupt for the graphics plane being used, and see if the GLCDC underflow interrupt occurs.
Jeremy said:To check if the GLCDC is using the framebuffer in SDRAM that you have configured, you can check in the IO registers view while debugging the project, stop the execution, and look at the registers of the GLCDC, the registers GR1_FLM2 and GR2_FLM2 hold the base address of the framebuffer for each of the 2 graphics planes that the GLCDC has, though only one of the graphics planes of the GLCDC is actually used.
Done! The display is in fact using double framebuffer accordingly.I even set it to a single framebuffer to make sure and some graphical rendering issues appeared, which makes sense.
Jeremy said:To confirm that a data underrun is occuring, in the GLCDC driver, enable the Underflow Interrupt for the graphics plane being used, and see if the GLCDC underflow interrupt occurs.
Done! Every time the particular gadget caused flickering, it triggered underflow interruptions. All the other gadgets/screens that are working fine don't trigger underflow interruptions.
Now that it is confirmed that data overrun is occurring, do you have any additional insight about this?
I ordered a lower memory capacity QSPI (16 M bit with DTR) to see if that helps. Futhermore, I also ordered the same one I used (64M bit) but with DTR. It will arrive this week.
As usual, thanks a lot for helping
You will have to make sure the timings for accesses to QSPI and SDRAM are optimised, and try to stop the data underrun of the GLCDC. Things you could try or check are :-
1) SDRAM timings are optimised in the SDRAM controller for the SDRAM you are using.
2) QSPI timings are optimised in the QSPI peripheral, the DTR parts should allow you to use XIP mode to remove a few clock cycles from accesses to the QSPI as it looks like the non DTR parts don't support XIP (continuous read access) from looking at the Winbond datasheet. Make sure that all 4 IO lines are being used transfers from the QSPI memory, is the prefetch enabled in the QSPI peripheral? Is the QSSL extension function enabled in the SFMSMD (SFMSE bit set to other than 0)?
3) Check the framerate of the LCD, you could try reducing the framerate of the LCD by using a larger divider of the source clock in the GLCDC driver.
4) Try disabling the Dave 2D framebuffer cache in the properties of the GUIX Port on sf_el_gx. This means the Dave2D doesn't do burst accesses to the framebuffer, so the Dave2D accesses are shorter and interspersed betwen the GLCDC accesses to the SDRAM.
5)Try disabling the Dave2D support in the project (both in the GUIX Studio project and in the e2studio porject), both the GLCDC and the Dave2D use the GPX bus internally in the S5D9, this makes the CPU transfer the data from the QSPI to the SDRAM when accessing the GUIX elements, but means the GLCDC has exclusive use of thr GPX bus.
Also, which version of the SSP are you using?