no lcd image after wakeup from sleep mode

[enrico.dallavia]

Hi,

I have a strange behavior with a stmf429-discovery board, used together with chibios 3.0.2.

I need to put the board on standby mode, which I successfully had. But when the board wakeup, the lcd remain blank (but if I perform a reset the lcd shows the text)

I thought that after wake-up from standby the board behave like from a cold boot.

Cortex-M4 deepsleep mode.

Voltage regulator disabled.

1.2V domain consequently powered off.

PLL, HSI and HSE RC oscillators disabled.

SRAM and register contents are lost except for the RTC registers, RTC backup registers, backup SRAM and Standby circuitry.

Any suggestion?

Thanks !

[inmarket]

Hmmm. Interesting.

This is not somethung we have tried but i have a few suggestions that may help...

1. You can try using the gdisp api display power down before going into deep sleep and the the gdisp api power up after returning from deep sleep. This would be the proper way of doing it but i am not sure if those are implemented in the stm32f4-discovery driver. Perhaps you would like to implement them for us?

2. In the absense of driver support, the another way would be to deinit and then reinit gfx itself. This may not be very successful as the deinit code is by no means complete and the gfxInit was never designed to be called more than once.

3. Alternatively manually call the driver init call again when returning from sleep. Normally this is a static routine. You will need to write a wrapper call in the driver file so that you can access it externally and call it from your code.

If you would like to attach your code for entering and leaving deep sleep, we will look at the problem when we get some time.

[Joel Bodenmann]

To clarify: These are the API functions for the display power management: http://wiki.ugfx.org/index.php?title=GD ... er_control

The display driver needs to implement these features in the gdisp_lld_control() functions but for a driver implementation it is of course not mandatory to handle them and as inmarket already mentioned we haven't implemented those for each display controller. Here you can see a working implementation for the SSD1289: https://bitbucket.org/Tectu/ugfx/src/50 ... 1289.c-279

When looking at the GDISP driver for the STM23F429i-Discovery board you will see that this driver doesn't implement that function at all.

If you have any questions regarding the implementation of that function please do not hesitate to ask.

~ Tectu

[enrico.dallavia]

Hi, thanks to all for the suggestion, I will do some test today.

For the initialization/de-initialization,when it returns from standby imply that the program would start again from the first line of main, the function gfxInit is always called. But maybe there are some registers inside the lcd controller that are messed up during standby procedure.

[enrico.dallavia]

I try to write some command inside gdisp_lld_control but they seems to not have any effect

like

acquire_bus(g);
write_data(g,ILI9341_CMD_DISPLAY_OFF);
release_bus(g);

the display won't turn off

in the same way what manual wrote about going in and out from sleep has no effect at all.

Am I missing something about write command to lcd controller?

[inmarket]

The stm32f4-discovery is a bastard display. It uses the stm32 ltdc to run the display but uses a ili9341 controller to initialise it. The interraction between the two, that is a very good question and very badly documented.

I suspect that after deep sleep everything is corrupt with the display, both the init provided by the ili9341 and the ltdc stm32 registers. It could even be that the external sdram is now corrupt and needs to be reinitialised or the fmsc registere that allow talking to the sdram.

I would suggest starting by looking at the sdram when you come back from deep sleep. If you can read and write from the sdrsm yhen the problem is with the ili9341 or the ltdc. If you cant read/write the external sdram then look at the fmsc registers first and then at the sdram itself.

I hope that will lead you to which part is not being restored properly after cpu deep sleep so that you can reinitialise.

[enrico.dallavia]

Yes it true that every thing must be re-initialized, but since the wakeup from standby is very similar to a cold boot and the sw begins from first line of main, I thought that sdram and everything are initialized again, since I had the calls to

halInit();
chSysInit();
// Initialize and clear the display
gfxInit();

but something inside the display maybe keeps something dirt.

My question are now the command issued to the display. Why the screen won't turn off if I send the command? I hope command are sent through SPI (and I'm quite sure original ugfx initialization send them like I do) because if I can't send properly the command I can't handle the wakeup from sleep.

Cheers

[inmarket]

Send your code to enter and leave deep sleep and we will have a look as soon as we get a free moment.