cancel
Showing results for 
Search instead for 
Did you mean: 

TouchGFX with 16 bit 8080 LCD interface

Mon2
Senior III

Hello. We have a need to work with a 16-bit 8080 style LCD interface. Would like to have the benefits of the latest TouchGFX tool (4.16.0) and STM32CubeMX to build quickly and debug our GUI screens. After some investigation, found the following kit which appears to be close to our hardware need:

STM32L496G-DISCO 

Ran TouchGFX -> created a fresh project using this target kit -> imported the Pool Lights demo -> ran the simulator -> runs fine -> Generated the Code.

Launched the STM32CubeMX .ioc file from the project folder -> toolchain requested to migrate to the current versions of the wizard code -> allowed for this update -> selected IAR compiler -> went back to TouchGFX to re-generate the code for the IAR target compiler -> returned to STM32CubeMX and built the project -> launched the IAR compiler -> compiled -> facing assorted errors.

Same errors with Keil compiler. Screens are attached.

Can anyone share if we are properly building for this target kit and toolchains?

Interested to experiment with this hardware with the 16-bit 8080 LCD display before moving to our custom hardware design which will be very similar.

Welcome all suggestions - including if we need to select a different hardware kit (but must have the 16 bit parallel bus).

Thanks.

7 REPLIES 7
N. SANTINI
ST Employee

Hi,

First you did well, but not enough !

First, in all the application templates that come with a CubeMX project (i.e. version 3.x.x) the default configured IDE is SMT32CubeIDE.

The missing symbols mentioned in your build report correspond to the display's low-level driver, also called "BSP" (Board Specific Package) or "Vendor Code" (see https://support.touchgfx.com/docs/development/board-bring-up/board-introduction) and this is not handled by CubeMX.

In the provided CubeIDE project these files (located in Drivers\BSP\Components\) have been manually added after CubeMX code generation to provide a functional project in the downloaded application template.

So besides changing the IDE in CubeMX you must do the following:

  • open the TouchGFX Designer project and generate the code since this is when the Designer checks the selected IDE (by parsing the CubeMX .ioc file) and thus updates the corresponding project file with the source files corresponding to the GUI.
  • Add to your IAR or Keil project all the BSP files (and corresponding include paths) as CubeMX does not have the information of the display or the memory or any other external component that is actually connected to the MCU, it only knows the configuration of the interfaces needed to interact with it.

The good new is that for this Development Kit all these are provided, you just need to point to them.

To be safe I recommend you to make a copy of the original application template and open the STM32CubeIDE project as a reference when updating your IAR or Keil project.

I hope this will help you progress.

Best regards,

Nicolas

MM..1
Chief III

Use this steps and open and build in CubeIDE gcc , not iar keil...

Ran TouchGFX ... select 496 board ... select blank gui ... generate code

then use in your project folder and double click .project file (mean STM32CubeIDE installed)

c:\TouchGFXProjects\MyApplication_496\STM32CubeIDE\.project 

in folder is also created EWARM and MDK-ARM , but for me not compile portmacro.h missing

This steps use BSP drivers properly. When you need use ioc and MX , then you can open it in CubeIDE.

Mon2
Senior III

Thank you both for your replies.

Found the BSP support file inside the en.stm32cubel4_v1-15-0 download.

Specifically,

Downloads\en.stm32cubel4_v1-15-0\STM32Cube_FW_L4_V1.15.0\Drivers\BSP\STM32L496G-Discovery\stm32l496g_discovery.c

Added the above to my BSP tree structure inside the IAR project. Compiles now without errors.

Created an output .hex file -> used the STM32CubeProgrammer to load this .hex file onto the target kit. The results are not matching the imported analog watch gui.

Using TouchGFX with this same kit -> Fresh project -> import the analog watch GUI example (nothing else) -> run Target -> the kit proceeds to display the watch properly.

Anything special required inside the IAR compiler to support this demo? Do see that the gcc compiler is referencing INTERNAL and EXTERNAL flash memory for this project which end up being flashed onto the target.

  

    Erasing memory corresponding to segment 0:

    Erasing internal memory sectors [0 99]

    Erasing memory corresponding to segment 1:

    Erasing external memory sectors [0 60]

    Download in Progress:

    ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±± 0%

    ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ 57%ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ 100%

     

    File download complete

    Time elapsed during download operation: 00:00:10.410

Is the single .hex file generated on the IAR tool the equivalent of the internal & external flash memory regions? The issue may be that the .hex file is not inclusive of all the memory regions that are required for this project.

0693W000007C5BkQAK.png 

Bad watch after programming of .hex file generated with IAR:

0693W000007C5COQA0.jpg 

Good watch after Run on Target option was selected inside TouchGFX:

0693W000007C5CdQAK.jpg 

0693W000007C5DbQAK.png

N. SANTINI
ST Employee

Hi,

The generated .hex file contains 2 kind of data, a part that will be put in internal FLASH and another part that will be put in external one (see scatter file .icf file).

The data put in external FLASH is notably the input bitmaps such as the demo background and the clock background in your case.

To put data in external flash you need to provide an external loader in CubeProgrammer, in the "EL" section on the left panel search for the L496-Disco external loader and select it.

Then program you board again.

STM32CubeIDE contains its own internal CubeProgrammer and thus automatically program the external FLASH as well as the TouchGFX Designer that uses makefile-based build/flash toolchain, see "gcc\Makefile". In fact TouchGFX Designer builds 2 binary files intflash.bin and extflash.bin and program the external flash using your installed CubeProgrammer in command-line and uses the external loader for L496-Disco, see following line in the Makefile:

stm32cubeLoader := STMicroelectronics\\STM32Cube\\STM32CubeProgrammer\\bin\\ExternalLoader\\MX25R6435F_STM32L496G-DISCO.stldr

So again, just select the proper external loader (MX25R6435F_STM32L496G-DISCO) in CubeProgrammer and flash again, it will program both internal and external FLASH and you will then see the proper images instead of noise (uninitialized memory).

Best regards,

Nicolas

Mon2
Senior III

0693W000007CDscQAG.pngThank you again Nicolas. Your level of support is priceless. The tools have come a long ways but the packaging of the documentation is still a bit written in a style that only twins will understand. Hence the never ending list of questions. Believe we are now close to having a working procedure to quickly develop GUI menus for our embedded design.

Some feedback:

1) Only a FRESH project initiated with the TouchGFX tool is able to compile and upload working code to the target STM32 kit. For this example, the STM32L496G-DISCO. If a launch is made to use the STM32CubeMX from this initial project -> target the IAR compiler (as an example) -> rebuild once again inside the TouchGFX -> the IAR compiler will properly build the project (once the missing BSP LCD_IO_xx files are attached). However, now the TouchGFX Run Target option will break. Perhaps makes sense since the batch of files is now focused on the IAR compiler (and no longer the gcc compiler?).

2) The STM32CubeProgrammer is acting a bit funky. Always appears to complain about an erase failure 2 times. Pressed Download again and the kit was reflashed ok.

PS: I strongly feel that a short but direct step by step procedure on how to use the TouchGFX (and the other compilers, one at a time) to build; compile; reflash the target kit with perhaps your Analog Clock GUI, etc. will be welcomed. There are a lot of steps. A single missed one can consume the day. Time permitting, we will consider to write up an article. In reading some public posts, many give up before reaching a working solution. Even in our case, Asia is offering to sell us some low cost, pseudo-custom LCD screens for our project but we are not interested in a single sourced partner. Now with these tools, close to being able to drive off-the-shelf ipod nano 6 / 7 and soon iphone xx displays.

Many thanks again.

Mon2
Senior III

Nicolas, designing the GUI on TouchGFX (step # 1) ...launch STM32CubeMX -> selecting IAR (add any missing BSP files) -> re-generate for IAR with Generate Code inside TouchGFX -> now will compile fine under IAR. Reflash the target kit using STM32CubeProgrammer (load the .hex file from the exe folder in IAR) with the EL flag checked to reflash the INTERNAL and EXTERNAL flash memory devices.

The above procedure appears to be a one-way solution. Is it possible to go back to TouchGFX and update the GUI screens, etc. for the same project? So far, have not been able to figure out this mystery. Perhaps, make a backup of the original project and start again if the GUI screens need to be updated?

N. SANTINI
ST Employee

Hi,

I would say that the "Run Target" should still be functional but honestly I did not test it, once you opened the CubeIDE or IAR project it means that you have started implementing and debugging your application. Maybe you could share the Designer log window when the Run Target fails ?

For sure it is planned already to create some dedicated short videos on such topics, it should come !

This can happen, sometimes the board needs a power reset to clean the RAM, but normally IAR also supports the ST devkits, thanks to a partnership, so you should be able to flash directly from IAR, check the following parameters (attached screenshot).

Finally you can of course go back to the designer, update your GUI and then rebuild back on IAR (it will signal that project has been updated), you can do the same from CubeMX side, e.g. add new peripherals and generate the code, both Designer and CubeMX are made to work this way that is why the CubeMX stores the chosen IDE to share the info with the Designer as I explained above, so you can go back and forth from both Designer and CubeMX and then build and debug from IAR.

Best regards,

Nicolas