Errors with uGFX and ChibiOS on STM32F7 Discovery

[stucknewbie]

Hello

I am new to uGFX and ChibiOS and have been trying to get a uGFX demo working on my board ( the STM32F746 Discovery).

I am using latest ChibiOS(3.0) and working inside of ChibiStudio Eclipse IDE.

Before making the changes for including uGFX inside of uGFX via Makefile edits, the program compiled and ran perfectly fine(it was the simple LED blinking demo for ChibiOS). After making the changes, I removed the ChibiOS's original main.c file inside directory(as required).

Then, the makefile and gfxconf.h were edited as given on the Getting Started and ChibiOS/RT wiki pages. The modified files are attached below for reference.  

 

Now, when I try to build the project using Eclipse(on Windows), the following errors show up:

1. make: *** No rule to make target 'ugfx/demos/modules/gwin/basics/demo.mk'. Stop.

2. target 'build/obj/gdisp_lld_STM32LTDC.o' given more than once in the same rule.

 

I have been trying to debug this for the past two days, but to no avail. Please help if possible.

Thanks!

gfxconf.h

Makefile

[stucknewbie]

For reference, a picture of the errors and warnings in Eclipse. 

[Joel Bodenmann]

Hello and welcome to the community!

Please read the following threads for more information:

• https://community.ugfx.org/topic/316-ugfx-amp-chibios-stm32f746g-discovery
• https://community.ugfx.org/topic/311-newbie-trying-discof746-demo
• https://community.ugfx.org/topic/289-ugfx-ltdc-and-chibios

The short version is that last time we checked (which is about half a year ago) there was compatibility issue with the ST headers used by ChibiOS/RT and our demo. Either of the two used the incorrect / outdated headers.
The linked threads explain what steps are required to resolve this issue.

[Joel Bodenmann]

Just as a follow-up: If you're not obligated to use ChibiOS/RT you can either use µGFX baremetal (without any operating system) or another operating system such as FreeRTOS, Keil RTX or many others. The issue here is really just that ChibiOS comes with its own HAL.
You can find a demo project using the STM32F7 discovery with Keil RTX in the download section.

[inmarket]

Yes there are definitely problems with chibios v3/16 and ugfx on the f7 platform.

Looking at your error message however seems to be pointing to a problem in your makefile.

It can't find the demo makefile and it seems to have double included the ltdc driver.

Check your makefile carefully.

[stucknewbie]

Hi,

Thanks a lot for your support. Appreciate your dedication and commitment towards the project!

I got the program to compile successfully using Cygwin, but when it is uploaded to the board, nothing happens on the LCD. It just stays blank white, whereas it should be running the demo. I have tried changing demos, changing paths, changing locations and verifying the makefile. The upload process is successful, I have tested it using the demos available in the downloads section(pretty awesome). There is some problem with the files or some other options. I am wondering what might be the issue. If you have any idea or have encountered this problem before, please help if possible. Once again, thanks!

I began afresh after installing Cygwin and followed these steps:

1. Edited the respective makefiles located at ugfx/boards/base/STM32F746-Discovery/example_chibios3 and for the example_raw32 for paths 

2. Compiled the programs using cygwin, after including all required STM32 files, as indicated missing during compilation.

The chibios3 example compiles absolutely fine, but when I upload the hex file to board, there is no response. Nothing happens. The upload finishes and that's it. Life goes on, and the board does not come on.

When I compile the raw32 examples using cygwin, these errors show up:

 

Please have a look if possible.

I am attaching a zipped version of my ugfx working directory. The compilation examples are located in root of directory. Please try and help if possible!

Thanks a lot! 

ugfx.zip

[inmarket]

The chibios3 and f7 result you are seeing (white screen with no action) is exactly the strange incompatibility problem we were talking about with chibios3 and the f7. We have not got to the bottom of that yet despite spending considerable time on it.

The raw32 compile error is not a problem we see. I suspect that the definition of the symbol LSE_STARTUP_TIMEOUT is missing for some reason. See if you can find where that definition is. I suspect it should be in the stm32 hal header files.

[stucknewbie]

Hi

I managed to solve the previous error regarding missing definition of LSE_STARTUP_TIMEOUT. Turns out a minor edit in HAL configuration files did the job.

Now when I compile using cygwin, I am running into these strange errors. Searching your forum for previous instances led me to 

However, that thread did not mention any solutions for the STM32F746 Discovery. One more question, what is meant when they said

Quote

 I changed the name of the color without the underscore and that seemed to work.

Did they mean changing HTML_COLOR_R to HTML_COLORR or did they mean something else?

I really need to make it work, and any solution will work. Please help if possible.

I am attaching screenshots for the compilation process. Have a look:

Using Cygwin on Windows 7.

I am attaching my project's zip file which was placed in the root of ugfx directory. STM32 includes are also there in the zip itself.

In case you have run into this error before or have a known workaround, please do help. Thanks a lot!

example_raw32.zip

[inmarket]

This is caused by an update to the STM32 HAL header files since we wrote the f7 support.

In the STM32 HAL file stm32f7xx_hal_dma2d.h it is now defining structure field members as "Blue", "Green" and "Red" which are macro predefined uGFX colors.

The solution is that the uGFX colors Red, Green and Blue must be #undef'd before the STM32 header file is included but after the uGFX header file is included in file boards/base/STM32F746-Discovery/stm32f746g_raw32_ugfx.c

In uGFX V3 we will be renaming the colors so that these conflicts are less common but we can't do that yet as that would break many user programs.

I have pushed an update to the repository that contains that change (although I haven't tested it).

Let me know how it goes.

 

[Joel Bodenmann]

Our community member @Fleck tried this fix yesterday on his brand new STM32F7-Discovery and he can confirm that the fix that @inmarket pushed to the repository works well.

[stucknewbie]

Hi

Sorry for the delay in update. That commit fixed the previous problem. Great! 

But now I am getting another error. 

Have a look:

Seems like there are some more problems with compatibility. To attempt a workaround for this error, when I changed __IO to extern at line 25 in the file 

ugfx\boards\base\STM32F746-Discovery\stm32746g_raw32_system.c

I got the following error:

Sorry to bother you yet again. Really appreciate the excellent support that you guys are providing for the library. This was compiled using Cygwin on Windows 7.

Please have a look and do tell if you find anything.

Thanks!

[inmarket]

Don't replace __IO with extern, just remove the __IO.

That should make the definitions compatible and it should then compile.

Annoying the way ST keep changing their definitions.

[stucknewbie]

Thanks for the prompt reply, @inmarket!

Jumping from one bug to next, we got a new one now.

Got this error now. Really starting to get annoyed at ST.

Attaching my compilation example directory with the build files as well as the STM include files I am using. Please have a look if possible!

 

Thanks a lot!

STM32.zip

[Joel Bodenmann]

These are not bugs. It's simply a matter of incompatibility between different HAL versions.
But yes, I agree. It's a bit pain in the butt that they change their HAL stuff after releasing a product.

Please note that the errors you are getting are not µGFX related.
Looking at the latest STM32F7CubeHAL and judging from your screenshot I assume that you forgot to include system_stm32f7xx.c somewhere because that is where they define their APBPrescTable in all of the examples that come with the STM32F7CubeHAL package.

[stucknewbie]

I understand that these are not uGFX related errors. Thanks a lot for helping me out. I am new to embedded development on STM microcontrollers. I am grateful to you for all the help and support.

Where to include tha file system_stm32f7xx.c? I tried including it inside of stm32f7xx_hal_rcc.c but that resulted in a multiple declarations error! Inclusion trials in other files yielded similar errors.
Please help me out if possible.

Thanks

[inmarket]

That stm hal file will need to be added to your makefile instead of trying to include it from another source file.

[Joel Bodenmann]

@inmarket is correct. The code in the HAL "includes" the APBPrescTable by using the extern keyword. Hence it just must be somewhere in a file that is available at link time. In all of ST's examples the table is declared in the system_stm32f7xx.c file which is supposed to be part of your project.

As a general rule: Do never every modify something like the HAL files that are provided by ST. Those libraries have been designed to integrate with your own code in a certain way. It's your responsibility to make sure that you make sure that your code honors these integration interfaces. Documentation and examples will tell you what's required to use the library.
As soon as you start modifying other people's library code you open Pandora's box. You'll run into many issues (short-, mid- and long-term) that might not even be obvious at the beginning. Modifying library code is a big no-no unless you know what you're doing and the code finds it's way into the upstream.

Just take one of the simple examples from ST, verify that it works and then add µGFX to that. It seems that the HAL change too much to just hot-fix the required modifications.

[stucknewbie]

Hey

Sorry to say, but it still won't compile. I am unable to solve the previous error. Which makefile did you modify and how?

[Joel Bodenmann]

We updated the HAL files that the STM32F746G-Discovery board files are using. Everything is now compatible to the latest version of the STM32F7CubeHAL and CMSIS that is available from the ST website itself.
If you are still not able to use the new board files with ChibiOS/RT then it's very likely that ChibiOS/RT is using an older version of the ST files. Check the file headers for versioning information.

We uploaded a complete, running out-of-the-box minimal project using RAW32 and makefile.
I'm afraid we won't have time to create a similar example for ChibiOS/RT in the following weeks.
In case of you're going to try that example, please don't forget to rate it if it's working the way it should

 

[stucknewbie]

Thank you so much for the help. It worked beautifully!
If you don't mind, may I ask where did you include the file system_stm32f7xx.c?(Only asked because I would love to learn from my mistakes).

Also, this example does not compile a demo, rather uses the main.c and gfxconf.h. How to overcome this? (I understand the flexibility provided by having a main instead of a separate demo, would just like to learn more.)

Once again, thank you very much!

Next step for me would be to get a livefeed from a camera module running on the board LCD. Any ideas which ugfx submodule would be best suited for this task?

 

[Joel Bodenmann]

5 minutes ago, stucknewbie said:

If you don't mind, may I ask where did you include the file system_stm32f7xx.c?(Only asked because I would love to learn from my mistakes).

The file(s) is/are located at /ugfx/boards\base/STM32F746-Discovery/ and are included in the board.mk file that can be found in the same directory. In the main Makefile which is part of the project directory that you downloaded, that board.mk file is included by this line: GFXBOARD = STM32F746-Discovery
That GFXBOARD variable is extended in the background to the path stated above. All that makefile magic happens in the /tools/gmake_scripts/compiler_gcc.mk Makefile.

 

5 minutes ago, stucknewbie said:

Also, this example does not compile a demo, rather uses the main.c and gfxconf.h. How to overcome this? (I understand the flexibility provided by having a main instead of a separate demo, would just like to learn more.)

Simply remove the main.c file from the SRC variable in the main Makefile (the one in the project directory) and use the GFXDEMO variable (eg. GFXDEMO = modules/gwin/frame).
It might be possible that you have to remove/rename the gfxconf.h file in the project directory to avoid file inclusion collision.

 

5 minutes ago, stucknewbie said:

Next step for me would be to get a livefeed from a camera module running on the board LCD. Any ideas which ugfx submodule would be best suited for this task?

Please feel free to create a new forum topic for this

 

I hope that helps.

[inmarket]

The gdispStreaming api is probably the bit you will need to get video displaying on the lcd