AnsweredAssumed Answered

emwin_gui_demo in EVK-MIMXRT1050 SDK fails to compile

Question asked by craigsmith on Jan 10, 2018
Latest reply on Mar 21, 2018 by Luis Pereira

Like • Show 0 Likes0
Comment • 8

After modifying the EVK-MIMXRT1050 SDK manifest file to get the emwin_gui_demo project to become available

(see post EVK-MIMXRT1050 SDK middleware projects not available for details) I'm getting lots of compile errors when I try to build in MCUXpresso.

Memory region Used Size Region Size %age Used
SRAM_DTC: 436480 B 128 KB 333.01%
SRAM_ITC: 0 GB 128 KB 0.00%
SDRAM: 0 GB 32 MB 0.00%
c:/integrity/mcuxpressoide_10.1.0_589/ide/tools/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/hard\libcr_c.a(alloc.o): In function `malloc':
alloc.c:(.text.malloc+0x0): multiple definition of `malloc'
c:/integrity/mcuxpressoide_10.1.0_589/ide/tools/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/hard\libc.a(lib_a-malloc.o):malloc.c:(.text.malloc+0x0): first defined here
c:/integrity/mcuxpressoide_10.1.0_589/ide/tools/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/hard\libcr_c.a(alloc.o): In function `free':
SRAM_OC: 0 GB 256 KB 0.00%
alloc.c:(.text.free+0x0): multiple definition of `free'
c:/integrity/mcuxpressoide_10.1.0_589/ide/tools/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5-sp/hard\libc.a(lib_a-malloc.o):malloc.c:(.text.free+0x0): first defined here
c:/integrity/mcuxpressoide_10.1.0_589/ide/tools/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld.exe: evkmimxrt1050_emwin_examples_emwin_gui_demo_emwin_gui_demo.axf section `.text' will not fit in region `SRAM_DTC'
c:/integrity/mcuxpressoide_10.1.0_589/ide/tools/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld.exe: region `SRAM_DTC' overflowed by 305408 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [evkmimxrt1050_emwin_examples_emwin_gui_demo_emwin_gui_demo.axf] Error 1

After some digging I found the multiple definitions of malloc/free can be fixed by a project setting of

C/C++ Build - Settings - MCU Linker - General

Tick the box next to: "No startup of default libs (-nostdlib)"

- this is the same setting as in many of the other demo projects in the SDK.

Unfortunately the memory overflows remained... I ended up moving the emwin libraries into another project (using the external flash and SDRAM) but would be good to get this project fixed in the SDK so have a stable base to test emwin with.

Memory region    Used Size       Region Size    %age Used
SRAM_DTC:       431168 B          128 KB           328.96%
SRAM_ITC:          0 GB                128 KB          0.00%
SDRAM:               0 GB                32 MB           0.00%
SRAM_OC: 0 GB            256 KB     0.00%

Any way to fix the project in the SDK?

Twinkle Sijo GJ Jan 18, 2018 8:04 AM

Correct Answer

The IMX RT code needs to run from an external flash. By default, whenever a new or some of the sample projects are loaded, they are configured to run from the ram (the reason for your SRAM_DTC overflow). To convert them you will need to do some changes to the mcu config settings. This is given in the "SDK Examples: Convertng a RAM project to XIP from Flash" section in the pdf given in the thread below....

https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2017/12/07/overview-of-using-the-mimxrt1050-evk-with-mcuxpresso-ide

See the reply in context

1 person had this question

Outcomes

Jack King Jan 16, 2018 11:53 PM

I tried to build the pxp and emwin demos on MCUXpresso 10.1.1 and got the same memory size issue.

In MCUXpresso 10.1.0, they build fine (after changing the stdlib setting you recommended!).

It looks like the difference is the memory details for the example project.

Under 10.1.0 only FLASH and SDRAM are defined.

Under 10.1.1, SRAM sections are also defined.

When I removed all of the definitions for SRAM sections in the 10.1.1 project, it compiles and runs successfully.

I uploaded a screenshot of the memory settings that work in 10.1.1.

Hope that helps!

Attachments

emwin_mem_settings.png186.0 KB

1 person found this helpful

Actions

Twinkle Sijo GJ Jan 18, 2018 8:04 AM

https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2017/12/07/overview-of-using-the-mimxrt1050-evk-with-mcuxpresso-ide

1 person found this helpful

Actions

Josh McAtee Jan 18, 2018 7:01 PM

I've successfully compiled and run the emWin demo.

Now that it's running, I think maybe its performance is not ideal - there is some screen tearing going on.

The easiest way to see this is to go to the "Sliders & spinbox" tab and move the vertical slider on the left. You will see some tearing appear horizontally (looks like white lines fluttering through the center grey bar).

There seems to be double buffering, but I think there is something else that isn't being done in the code to optimize performance. I don't know enough (don't really know anything at this point) about the rt1050 to say what exactly is/isn't being done that could be.

As a counterpoint, the emWin demo on something like a ST32F7 board works without flickering for me. They use double buffering and DMA for transferring the buffer from SDRAM directly the LCD interface.

1 person found this helpful

Actions

craigsmith Jan 18, 2018 8:42 PM

Hi everyone,

thanks for your advice, I've managed to get the emWin demo up and running now. I had to add the xip folder to the project so it initialised the SDRAM (the SDRAM mcuxpresso init script could have alternatively been used). It's a bit slow using SDRAM for the system variables etc.

I've also got another project with it running successfully under freeRTOS and have implemented double buffering and got some other emwin demos working (including realtime MJPEG video at 30 fps). I'm just using the SDRAM for the framebuffers and emwin memory in that case.

To enable multi/double buffering you just need to add the following code somewhere in emwin init (I put it in LCD_X_Config()).

GUI_MEMDEV_MULTIBUF_Enable(1);
WM_MULTIBUF_Enable(1);

Also, there is no need to have the end of frame interrupts on all the time as the example has. You only need to turn them on when you want to switch buffers. To do this:

1. In void APP_ELCDIF_Init(void)

remove the line: ELCDIF_EnableInterrupts(APP_ELCDIF, kELCDIF_CurFrameDoneInterruptEnable);

2. In int LCD_X_DisplayDriver(unsigned LayerIndex, unsigned Cmd, void *p)

replace the line: while (s_LCDpendingBuffer >= 0) ;

      with:                   uint32_t intStatus = ELCDIF_GetInterruptStatus(APP_ELCDIF);
                                ELCDIF_ClearInterruptStatus(APP_ELCDIF, intStatus);
                                ELCDIF_EnableInterrupts(APP_ELCDIF, kELCDIF_CurFrameDoneInterruptEnable);

3. In void APP_LCDIF_IRQHandler(void)

after: s_LCDpendingBuffer = -1;

add the line: ELCDIF_DisableInterrupts(APP_ELCDIF, kELCDIF_CurFrameDoneInterruptEnable);

1 person found this helpful

Actions

Josh McAtee Jan 19, 2018 11:10 AM

Craig,

Any chance you could share just the base FreeRTOS + emWin project?

I'm not getting double buffering to work correctly, there is still a lot of flicker.

Would be nice if the NXP example had a little bit more effort put into it.

Actions

craigsmith @ Josh McAtee on Jan 21, 2018 2:57 PM

Hi Josh,

If you use the code I posted above double buffering should work just fine. The gui code needs to be written for double buffering too, have you tried some of the emwin examples from Segger?

From your other comment above, the RT1050 does automatically transfer the LCD data from memory to the LCD just like the ST32F7 board without the help of the CPU. Would be good if NXP had a more polished example... not sure why they aren't showing off the real capabilities of the micro for the LCD demo.

Actions

Josh McAtee @ craigsmith on Jan 23, 2018 11:33 AM

Craig,

I have set up the project much like you have posted, but there is definitely tearing that is obvious when using the vertical slider. I've used emWin in the past, when testing it with STM32 dev boards.

I guess the difference between this NXP example and others (STM32) is that it doesn't make any use of the LCD_SetDevFunc() stuff in EmWin to register DMA copy/fill/etc. The LCD may be getting data over DMA, but M2M DMA doesn't appear to be set up at all for emWin double buffering to work correctly.

Actions

Luis Pereira Mar 21, 2018 4:33 AM

Hello,

I'm trying to work with this example and making some other test drive to the board with emWin, but I'm getting a problem that I could not solve even with you proposed changes.

Starting debugging the application and the image on the screen appear "melted". When I stop the debug, the image draws properly, but if I reset the board, the image draws the same "melted" way, or not draws at all. I'll attach some pictures of what I meant.

For the one button example i have edited the emWin_demo and on the main only run the following code (which works on a ST32F7, where I end it with a GUI_Delay()):

    GUI_HWIN hWnd;
   BUTTON_Handle hButton;

   /* Create foreground window */
   hWnd = WM_CreateWindow(10, 10, 780, 460 , WM_CF_SHOW, cbForegroundWin, 0);
   /* Show foreground window */
   //GUI_Delay(1000);

   hButton = BUTTON_CreateEx(10,10,200,40,hWnd, WM_CF_SHOW, 0, GUI_ID_OK);
   BUTTON_SetFont(hButton,&GUI_Font20_1);
   BUTTON_SetText(hButton, "Click me...");
   //GUI_Delay(1);
   WM_Exec();

Can you give me some advice in this?

Sincerely,

Luis Perera

Attachments

Actions

8 Replies

Jack King Jan 16, 2018 11:53 PM
Mark Correct
Correct Answer
I tried to build the pxp and emwin demos on MCUXpresso 10.1.1 and got the same memory size issue.
In MCUXpresso 10.1.0, they build fine (after changing the stdlib setting you recommended!).

It looks like the difference is the memory details for the example project.
Under 10.1.0 only FLASH and SDRAM are defined.
Under 10.1.1, SRAM sections are also defined.
When I removed all of the definitions for SRAM sections in the 10.1.1 project, it compiles and runs successfully.

I uploaded a screenshot of the memory settings that work in 10.1.1.

Hope that helps!
Attachments
- emwin_mem_settings.png186.0 KB
1 person found this helpful
Like • Show 0 Likes0
Actions
Twinkle Sijo GJ Jan 18, 2018 8:04 AM
Unmark Correct
Correct Answer
The IMX RT code needs to run from an external flash. By default, whenever a new or some of the sample projects are loaded, they are configured to run from the ram (the reason for your SRAM_DTC overflow). To convert them you will need to do some changes to the mcu config settings. This is given in the "SDK Examples: Convertng a RAM project to XIP from Flash" section in the pdf given in the thread below....

https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2017/12/07/overview-of-using-the-mimxrt1050-evk-with-mcuxpresso-ide
1 person found this helpful
Like • Show 0 Likes0
Actions
Josh McAtee Jan 18, 2018 7:01 PM
Mark Correct
Correct Answer
I've successfully compiled and run the emWin demo.
Now that it's running, I think maybe its performance is not ideal - there is some screen tearing going on.
The easiest way to see this is to go to the "Sliders & spinbox" tab and move the vertical slider on the left. You will see some tearing appear horizontally (looks like white lines fluttering through the center grey bar).
There seems to be double buffering, but I think there is something else that isn't being done in the code to optimize performance. I don't know enough (don't really know anything at this point) about the rt1050 to say what exactly is/isn't being done that could be.
As a counterpoint, the emWin demo on something like a ST32F7 board works without flickering for me. They use double buffering and DMA for transferring the buffer from SDRAM directly the LCD interface.
1 person found this helpful
Like • Show 0 Likes0
Actions
craigsmith Jan 18, 2018 8:42 PM
Mark Correct
Correct Answer
Hi everyone,
thanks for your advice, I've managed to get the emWin demo up and running now. I had to add the xip folder to the project so it initialised the SDRAM (the SDRAM mcuxpresso init script could have alternatively been used). It's a bit slow using SDRAM for the system variables etc.

I've also got another project with it running successfully under freeRTOS and have implemented double buffering and got some other emwin demos working (including realtime MJPEG video at 30 fps). I'm just using the SDRAM for the framebuffers and emwin memory in that case.

To enable multi/double buffering you just need to add the following code somewhere in emwin init (I put it in LCD_X_Config()).
GUI_MEMDEV_MULTIBUF_Enable(1);
WM_MULTIBUF_Enable(1);

Also, there is no need to have the end of frame interrupts on all the time as the example has. You only need to turn them on when you want to switch buffers. To do this:
1. In void APP_ELCDIF_Init(void)
      remove the line: ELCDIF_EnableInterrupts(APP_ELCDIF, kELCDIF_CurFrameDoneInterruptEnable);

2. In int LCD_X_DisplayDriver(unsigned LayerIndex, unsigned Cmd, void *p)
      replace the line: while (s_LCDpendingBuffer >= 0) ;
      with:                   uint32_t intStatus = ELCDIF_GetInterruptStatus(APP_ELCDIF);
                                ELCDIF_ClearInterruptStatus(APP_ELCDIF, intStatus);
                                ELCDIF_EnableInterrupts(APP_ELCDIF, kELCDIF_CurFrameDoneInterruptEnable);

3. In void APP_LCDIF_IRQHandler(void)
      after:             s_LCDpendingBuffer = -1;
      add the line: ELCDIF_DisableInterrupts(APP_ELCDIF, kELCDIF_CurFrameDoneInterruptEnable);
1 person found this helpful
Like • Show 0 Likes0
Actions
Josh McAtee Jan 19, 2018 11:10 AM
Mark Correct
Correct Answer
Craig,

Any chance you could share just the base FreeRTOS + emWin project?
I'm not getting double buffering to work correctly, there is still a lot of flicker.
Would be nice if the NXP example had a little bit more effort put into it.
Like • Show 0 Likes0
Actions
- craigsmith @ Josh McAtee on Jan 21, 2018 2:57 PM
  Mark Correct
  Correct Answer
  Hi Josh,
  If you use the code I posted above double buffering should work just fine. The gui code needs to be written for double buffering too, have you tried some of the emwin examples from Segger?
  
  From your other comment above, the RT1050 does automatically transfer the LCD data from memory to the LCD just like the ST32F7 board without the help of the CPU. Would be good if NXP had a more polished example... not sure why they aren't showing off the real capabilities of the micro for the LCD demo.
  Like • Show 0 Likes0
  Actions
  - Josh McAtee @ craigsmith on Jan 23, 2018 11:33 AM
    Mark Correct
    Correct Answer
    Craig,
    
    I have set up the project much like you have posted, but there is definitely tearing that is obvious when using the vertical slider. I've used emWin in the past, when testing it with STM32 dev boards.
    I guess the difference between this NXP example and others (STM32) is that it doesn't make any use of the LCD_SetDevFunc() stuff in EmWin to register DMA copy/fill/etc. The LCD may be getting data over DMA, but M2M DMA doesn't appear to be set up at all for emWin double buffering to work correctly.
    Like • Show 0 Likes0
    Actions
Luis Pereira Mar 21, 2018 4:33 AM
Mark Correct
Correct Answer
Hello,

I'm trying to work with this example and making some other test drive to the board with emWin, but I'm getting a problem that I could not solve even with you proposed changes.

Starting debugging the application and the image on the screen appear "melted". When I stop the debug, the image draws properly, but if I reset the board, the image draws the same "melted" way, or not draws at all. I'll attach some pictures of what I meant.

For the one button example i have edited the emWin_demo and on the main only run the following code (which works on a ST32F7, where I end it with a GUI_Delay()):

    GUI_HWIN hWnd;
   BUTTON_Handle hButton;

   /* Create foreground window */
   hWnd = WM_CreateWindow(10, 10, 780, 460 , WM_CF_SHOW, cbForegroundWin, 0);
   /* Show foreground window */
   //GUI_Delay(1000);

   hButton = BUTTON_CreateEx(10,10,200,40,hWnd, WM_CF_SHOW, 0, GUI_ID_OK);
   BUTTON_SetFont(hButton,&GUI_Font20_1);
   BUTTON_SetText(hButton, "Click me...");
   //GUI_Delay(1);
   WM_Exec();

Can you give me some advice in this?

Sincerely,
Luis Perera
Attachments
- after_reset.jpg2.1 MB
- simple_example_stopped.jpg1.5 MB
- simple_example_init.jpg1.3 MB
- demo_emwin_stopped.jpg1.1 MB
- demo_emwin_init.jpg1.0 MB
Like • Show 0 Likes0
Actions

emwin_gui_demo in EVK-MIMXRT1050 SDK fails to compile

Outcomes

Attachments

Attachments

Related Content

Recommended Content

NEWS