STemWin and Waveshare Open746I-C development board

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • STemWin and Waveshare Open746I-C development board

    Hi,

    Working on Waveshare Open746I-C development board on the STM32F746 MCU with firmware development samples from STemWin based on emWin V5.28 from Segger.
    I know that support should normally come from ST and/or Waveshare, but I’m submitting my case here just in case an easy solution pops up to someone right from the beginning with this post. For my part, even after days of searches, I'm totally unable to figure out what could be the issue.

    Some part of the GUI demo samples just work fine and other parts are crashing. The GUI samples code were originally done for a 4.3-inch ST discovery board and adapted to the Waveshare board which includes a 7-inch 1024 X 600 display. I took the code from Waveshare written for uVision 5 and convert it to my development tools based on VisualGDB.

    For some GUI samples the firmware crashes with the “Call Stack Debug Window” always showing the same functions called just before the break. It seems to come from a “memcpy” called after emWin library function
    “_DrawBitmap()”.

    > HardFault_HandlerC() C++ (gdb)
         <signal handler called>()
    memcpy() C++ (gdb)
         _DrawBitmap()
    _DrawBitmap()
    _FlushBuffer.isra.5()
    _SetBkIndexBuffered()
    _SpriteDraw()
    GUI_SPRITE__CreateEx()
    GUI_SPRITE_CreateEx()
    _DemoTreeview() C++ (gdb)
         GUIDEMO_Treeview() C++ (gdb)
         GUIDEMO_Main() C++ (gdb)
         MainTask() C++ (gdb)
     main() C++ (gdb)

    Any possible path for a solution would be greatly appreciated.
    Regards,

  • Hi,

    It's hard to say what causes the HardFault.
    Since the configuration was for a smaller display please check that the framebuffer is large enough (LCDConf.c). The required memory is calculated this way:

    XSIZE * YSIZE * BPP / 8 * NUM_BUFFERS

    BPP is the color depth in bit per pixel, NUM_BUFFERS is the amount of buffers used for multi buffering. If there is not enough memory available try to decrement the number of buffers in the first step.

    Further you should check if enough working memory for emWin is available. Take a look into the GUIConf.c. There is an array which is used to allocate memory for emWin. Try to increase the buffer size.

    Regards,
    Sven
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi Sven,

    Your answer is appreciated, it lights me on few things that I wasn’t aware of. So in theory, for my display size, the minimal allocated RAM should be 1024 * 600 = 614 400 bytes to emWin. It means that the STM32F476 with 320K of SRAM will never have sufficient resource available.

    I changed the configuration to give the maximum of memory to the GUI by reducing the NUM_BUFFERS in the LCDConf.c file and increasing the GUI_NUMBYTES at SRAM near 320K in the GUIConf.c file but “HardFault_Handler” was always being called.

    And what about the 64-Mbit of SDRAM available on the development board? Can’t we use a part of this memory for emWin or the entire 8-Mbyte of the SDRAM is reserved to LCD display controller and nothing else?
    I see that on this board the SDRAM memory BUS is 16-bits starting at address 0xD0000000. I also see in the LCDConf.c file that addresses 0xD02000000 and 0xD04000000 are reserved for LCD_LAYER0_FRAME_BUFFER and LCD_LAYER1_FRAME_BUFFER respectively. I tried to map a part of this memory for emWin but again did not have any success…

    Regards,

  • Hi,

    I'm not sure which board you are working with, but on our website we have some eval packages for ST devices using emWin (and our other products).
    Like this one:
    segger.com/st-stm324x9i.html

    Just search for the LCDConf.c and take a look into it regarding the configuration.

    In the project for Embedded Studio we map the FrameBuffer (LCDConf.c) and the GUI memory (GUIConf.c) to the external SDRAM.

    Regards,
    Sven
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Thanks Sven, now I was able to configure the board to use 2 Megs of the SDRAM. I also able to make the touch screen detection worked and tranfer corectly the information to STemWin GUI. The WaveShare touch screen detection hardware is based on a GT811 chip made in China with technical spec in Chineese only...

    But now I'm facing another strange issue by doing a simple two buttons GUI if the Framewin_CreateIndirect first coordinate is 0, 0 goes directly into my HardFault_Handler manager.

    staticconstGUI_WIDGET_CREATE_INFO_aDialogCreate[] = {
    { FRAMEWIN_CreateIndirect, "Framewin", ID_FRAMEWIN_0, 0, 0, 1024, 600, 0, 0x0, 0 },
    { BUTTON_CreateIndirect, "Test 1", ID_BUTTON_0, 818, 390, 150, 67, 0, 0x0, 0 },
    { BUTTON_CreateIndirect, "Test 2", ID_BUTTON_1, 818, 470, 150, 67, 0, 0x0, 0 },
    // USER START (Optionally insert additional widgets)
    // USER END
    };

    But if the Framewin starts at -1, 0 than everything works fine, can somoene tells me why?

    staticconstGUI_WIDGET_CREATE_INFO_aDialogCreate[] = {
    { FRAMEWIN_CreateIndirect, "Framewin", ID_FRAMEWIN_0, -1, 0, 1024, 600, 0, 0x0, 0 },

    Regards.