Jump to content

ChibiOS RT and STMF746-Disco


vikassahota

Recommended Posts

Hi

Im very new to ChibiOS and having a little bit of a hard time setting up a first project using ugfx, struggling along a few days so far filling in the blanks in knowledge but now Im a little stumped.

Im using ChibiStudio, trunk workspace and RT-STM32F746G-DISCOVERY as a base project to integrate uGFX.  I've followed the couple guides on ugfx chibistudio and RT setup but things don't work out accordingly following the steps with either of the workspaces in chibistudio:(

In the last attempt, I start again with the same project (trunk workspace) and hope to just include the uGFX library w/out changing the main.c and see that I can still build and debug OK. So for this I took to the deeper docs and modified the project makefile manually (rather than use the demo makefile structure).

It seems to be almost there since mostly its building OK but I do end up with an error for the stm32f7xx_hal_rcc.h not being present where its expected.  Hoping someone might have an idea with this, compiler output is below.  Can I use one from the CubeF7 software package safely?

Would be great to have a working RT demo for this board, target really was to integrate along with chibios F7's RT-LWIP-FATFS-USB demonstration, but I never made it past the blinky yet sadly.

Any wisdom appreciated with this one since im very new to chibi and uGFX both. As well as that not a professional programmer, so I'll always struggle through complex project setup but after that things usually go my way.  That being said I might well be spending time up a dead end already :)

thanks,

Vik

-------------------------------

00:55:22 **** Build of configuration Default for project TestUGFX ****

make -j4 all

Compiler Options

arm-none-eabi-gcc -c -mcpu=cortex-m4 -O2 -ggdb -fomit-frame-pointer -falign-functions=16 -ffunction-sections -fdata-sections -fno-common -flto -Wall -Wextra -Wundef -Wstrict-prototypes -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -I../../chibios_trunk/os/common/startup/ARMCMx/compilers/GCC -I../../chibios_trunk/os/common/startup/ARMCMx/devices/STM32F7xx -I../../chibios_trunk/os/common/ext/CMSIS/include -I../../chibios_trunk/os/common/ext/CMSIS/ST/STM32F7xx -I../../chibios_trunk/os/rt/include -I../../chibios_trunk/os/common/oslib/include -I../../chibios_trunk/os/common/ports/ARMCMx -I../../chibios_trunk/os/common/ports/ARMCMx/compilers/GCC -I../../chibios_trunk/os/hal/osal/rt -I../../chibios_trunk/os/hal/include -I../../chibios_trunk/os/hal/ports/common/ARMCMx -I../../chibios_trunk/os/hal/ports/STM32/STM32F7xx -I../../chibios_trunk/os/hal/ports/STM32/LLD/ADCv2 -I../../chibios_trunk/os/hal/ports/STM32/LLD/CANv1 -I../../chibios_trunk/os/hal/ports/STM32/LLD/DACv1 -I../../chibios_trunk/os/hal/ports/STM32/LLD/DMAv2 -I../../chibios_trunk/os/hal/ports/STM32/LLD/EXTIv1 -I../../chibios_trunk/os/hal/ports/STM32/LLD/GPIOv2 -I../../chibios_trunk/os/hal/ports/STM32/LLD/I2Cv2 -I../../chibios_trunk/os/hal/ports/STM32/LLD/MACv1 -I../../chibios_trunk/os/hal/ports/STM32/LLD/OTGv1 -I../../chibios_trunk/os/hal/ports/STM32/LLD/RTCv2 -I../../chibios_trunk/os/hal/ports/STM32/LLD/SDMMCv1 -I../../chibios_trunk/os/hal/ports/STM32/LLD/SPIv2 -I../../chibios_trunk/os/hal/ports/STM32/LLD/TIMv1 -I../../chibios_trunk/os/hal/ports/STM32/LLD/USARTv2 -I../../chibios_trunk/os/hal/ports/STM32/LLD/xWDGv1 -I../../chibios_trunk/os/hal/boards/ST_STM32F746G_DISCOVERY -I../../chibios_trunk/test/rt -I../../chibios_trunk/os/various -I../../ugfx -I../../ugfx/3rdparty/tinygl-0.4-ugfx/include -I../../ugfx/boards/base/STM32F746-Discovery -I../../ugfx/drivers/gdisp/STM32LTDC main.c -o main.o

Compiling crt0_v7m.s
Compiling chcoreasm_v7m.s

...

Compiling stm32f746g_discovery_sdram.c
Compiling stm32f7_i2c.c
Compiling gdisp_lld_STM32LTDC.c
../../ugfx/boards/base/STM32F746-Discovery/stm32f746g_discovery_sdram.c:6:31: fatal error: stm32f7xx_hal_rcc.h: No such file or directory
#include "stm32f7xx_hal_rcc.h"
^
compilation terminated.

------------------------------

Link to comment
Share on other sites

Hello and welcome to the community!

We fully understand your frustration. Most of us went through the same process. I remember how it took me three days until I had a blinking LED when I first moved to the STM32 platform :) 

The problem you are facing is that the board files that you are compiling are not compatible with the ChibiOS/HAL. The board files in /boards/base/STM32F746-Discovery are written for systems that use the CubeHAL (the official STM32F7CubeHAL or whatever the actual name is). ChibiOS doesn't use that CubeHAL but comes with its own HAL (called ChibiOS/HAL). Right now we don't have any board files for the STM32F746G-Discovery board that work with ChibiOS/HAL - you'll have to write those yourself (or use the CubeHAL instead).
If you want to tackle writing board files for the ChibiOS/HAL: We are obviously happy to help wherever we can.

Link to comment
Share on other sites

Thanks Joel,

Blinky usually goes OK for me, its going from there to a fully setup project with all the drivers and libraries all ready to go, debug ready is the painful bit!

Ok- that explains the state thank you for clarifying.  Makes further sense since Id seen note of the ST / Chibi HAL difference in other threads.

Im not sure what the generating of board files involves, maybe ill gem up on the docs a little and see if its an approachable task for me :)

 

Link to comment
Share on other sites

A board file is nothing but a file containing functions that the driver will use to communicate with the piece of hardware. To write a board file, you simply copy the board file template that you find in the drivers directory and implement the empty functions. In your particular case that would mean that you copy the file /drivers/gdisp/STM32LTDC/board_STM32LTDC_template.h to your project and rename it to board_STM32LTDC.h (the driver will automatically include that file). All you have to do is implementing the functions in there using ChibiOS/HAL instead of CubeHAL.
With other drivers this is less cumbersome because you usually just need to write to an SPI interface or similar. However, when using LTDC you have to initialize the memory interface, setup the SDRAM timings and so on. Hence writing a board file for the STM32LTDC driver is a bit more cumbersome. However, all the stuff that is "difficult to figure out" (the proper pin configurations, timings, ...) can be copied from the existing board file. You just need to use the ChibiOS/HAL API.

Link to comment
Share on other sites

  • 6 months later...

I have already put quite a time into getting ugfx (2.7) and stm32f746 to work with chibios (stable_16.1.x branch).

This bare metal version works fine:

Chibios ugfx for stm32f746 is broken because it does not include needed stm32cube headers. So copy STM32f7xx_HAL_Driver from BareMetal project to your project dir and for quick hack modify ugfx/boards/base/STM32F746-Discovery/board.mk to include stuff from Cube HAL:

GFXINC    += $(STMHAL)/Inc

Also modify your own Makefile that should be copied from ugfx/boards/base/STM32F746-Discovery/example_chibios3

#Special - Required for the drivers for this discovery board.
STMHAL		= STM32F7xx_HAL_Driver

After that dependencies are resolved and project can be built, BUT it still does not work and is just showing blank screen with backlight on. So there is still something fishy.

Link to comment
Share on other sites

There is some incompatibility issue between the specific combination of chibios, ugfx and the stm32f746. The symptoms are exactly as you describe - a blank screen. The combination works perfectly with the stm32f4 boards but not the stm32f7.

We have spent a lot of time trying to figure out what the difference is between that and the raw32 equivalent which does work. We have even tried doing a full raw32 init under chibios but even that doesn't work.

Consequently we think that chibios is somehow disabling something in its init that is preventing the lcd from working even after the full raw32 init (but only for the f7 platform).

We would love someone to get to the bottom of the problem. Unfortunately we have just run out of time to spend on it for now.

PS. The reason the f7 didn't include all the necessary headers is because at the time chibios was using different incompatible versions of the stm32 hal header files. Chibios have since updated but we haven't had time to go back and fix the example makefiles. Thanks for providing that. I will get that into the repo as soon as possible. 

Link to comment
Share on other sites

Not with the f7. Everything works fine with f4 boards. Note chibios v2 doesn't support the f7 chip at all so chibios v3/16 is the only possible option anyway for this hardware.

We really need someone to debug this setup for us. Unfortunately we are currently just too busy and it is considered lower priority for us as other operating systems (eg freertos, keilcms and raw32) have been tested and work with this board.

As mentioned before, the symptoms sèem to indicate that chibios is somehow preventing proper initialisation of the hardware but only for f7 boards.

Link to comment
Share on other sites

Hi 

Dear you say just we are too busy ! ! you are supporter of ugfx,aren't you?!

I had problems like this in bare metal with keil and discoveryf7 just show white screen , and I request you (operating systems topic)to put demo 003 with keil in bare metal with st header file , but you didn't and just said we are too busy ! 

Dear you are support team!

You know ugfx demo  (003) header for discoveryf7 is incompatible with st library  (stmcube) and are different too.

Edited by 91321146
Link to comment
Share on other sites

Please don't push on our good graces.

uGFX is a product that we produce commercially and paid support is one of our main revenue for uGFX. Everyone needs to eat including us.

We have made the source code available for free to the non-commercial world as part of our belief in contributing to others. We also provide free support on this community forum however our time is limited as we need to work to make a living and that always has to take priority.

We are also working on lots of different parts of uGFX. One specific board on one specific operating system is not currently a priority. There are other combinations that work with that board and the problem with this combination appears to not be in our code. We have also already spent more time than we should on this problem.

Rather than complaining that we are not spending our free time on it, how about being part of the solution. For example, debug it, solve it and contribute it back to the community; or, pay for paid support so we can afford to spend the time on it that you believe this problem deserves.

Regardless, we will eventually get around to solving the problem. It is on our list of known problems. It will just not be anytime soon as it is marked as low priority.

Link to comment
Share on other sites

I'm really sorry because of my words, I should not use these words , it's not fair to say ugfx support don't solve problems , of course they are hard working and I  appreciate them because of free ugfx library , 

Please please and again please forgive me,because of my wordstuff

I apologize inmarket and my brother Joel bodenmann

I love you my friends ، forgive me by you're Magnanimity. 

Edited by 91321146
Link to comment
Share on other sites

  • 3 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...