After succesfully developing and testing EW application over STM32F769-Discovery, now I am trying to adapt software to LCD and Touch that will be used in our board.
We have not yet our board designed, so I am debugging LCD and Touch drivers with some leds and oscilloscope.
As far as I can tell after testing , I think I have succesfully integrated the Touch driver, since in oscilloscope I can see periodically I2C read requests from BSP_TS_GetState()
Now I have replaced otm8009a.c for my LCD driver. It seems to go through all init steps succesfully, using DSI_IO_WriteCmd to interface with DSI. However, application gets freezed when arriving to EwUpdate into ewmain. Concretely, EwEndUpdate() is never returning:
/* redraw the dirty area of the screen */
if ( bitmap )
GraphicsCanvas__AttachBitmap( canvas, (XUInt32)bitmap );
updateRect = CoreRoot__UpdateGE20( aApplication, canvas );
GraphicsCanvas__DetachBitmap( canvas );
EwEndUpdate( aViewport, updateRect );
This is because there is no the right LCD attached, so it is normal get freezed here?. Or it could be because I have missed something thoruh driver integration process?
We are using LCD with ILI9806E driver.
Yes, it is a DSI display. I am not sure of which mode we are using. We have adapted the stm32f769i_discovery_lcd.c and ew_bsp_display.c to use our ili9806e.h definitions instead of the ones from otm8009a.h. We have not changed anything else in code. We are using DSI_IO_WriteCmd() to init our driver.
I mean that program enters into EwEndUpdate() and never returns. As a consequence, DeviceDriver_ProcessData() is only executed first time, and as I am refreshing watchdog there, it is never refreshed and board resets constantly.
the LCD that is mounted on the STM32F769 Discovery of Evalboard can be driven by using the DSI video mode or the DSI command mode.
In our Build Environment we are using the the DSI command mode. This is more efficient because it uses graphics memory of the display (GRAM) and only updates are transferred to the display. As a result the memory bandwidth is reduced.
I'm not sure if the ILI9806E is compatible (set of commands and parameters) with the OTM8009A.
In case the application does not return from EwEndUpdate() I assume that it is waiting in WaitForDsiTransfer() until the transfer is complete...
Ok, ILI9806E has no GRAM, so I understand we should use DSI video mode. Do you any example of interfacing with LCD through DSI video mode?
I guess WaitForDsiTransfer() is waiting a response from the LCD, and since that it's not connected, WaitForDsiTransfer() is never receiving confirmation. It is right?
we do not have a ready-to-use example for DSI video mode - please have a look to this question and answer.
I have verified that is never entering into WaitForDsiTransfer(), and I can't go into EwEndUpdate() to check what is hapenning because it seems to be precompiled.
I want to remember that there is no LCD connected.
Could I share with you the project?Maybe you could debug until find the issue.
EwEndUpdate() is inside the Graphics Engine library - but there is no dependecy to the DSI display. The function calls GfxEndUpdate() that you will find in the module ewextgfx.c. In principle, the file ew_bsp_display.c is the only location where you should make modifications in case you change the display.
Maybe you should first try to get the display itself up and running based on the DSI video mode example from STM32 cube firmware. In a second step you can integrate that.
Porting to customer specific hardware is offered as a separate service - please contact us in case you are interested.
Ask Embedded Wizard
Welcome to the question and answer site for Embedded Wizard users and UI developers.
Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!