STM32F746-disco + ChibiOS

[cpu20]

Hello,

I have read multiple threads about the problems with the stm32f7-disco and chibios.

Now I am trying to do some basic debugging to see where I can help. First of all I tried rewriting the board_STM32LTDC.h file to initialize the pins with the PAL functions from chibios.

But when I debug the program now the pins are initialized, and the LCD is turned on (white screen). But after that the gfxInit routine initializes the LTDC controller. From the moment the LTDCEN bit goes high the display goes off (blank screen no backlight) and doesn't want to turn on again.

Any idea what could be the cause of this? I have no idea...

Thanks for all your hard work with this library btw!
 

[cpu20]

Update: The screen does not go blank, it goes black/grey. The backlight is still on, I only did not really see a difference between on and off with the daylight. Back to searching for other issues.
 

[Joel Bodenmann]

Hello @cpu20,

Thank you very much for diving into this - we appreciate it a lot!

Unfortunately nothing comes to mind that might help you right now...
If everything went well gfxInit() will clear the display using GDISP_STARTUP_COLOR. Most likely that is set to black so that could be an indication that everything went well. Have you tried actually drawing onto the display?

[cpu20]

Setting the GDISP_STARTUP_COLOR didn't change anything. Drawing also still doesn't work.

Something I noticed is that when using the raw32 project, before executing the gdisp_lld_init function it enters a mutex. When using chibios this isn't implemented. Could this cause any trouble?

[Paul C]

Hi, Im new to working with Graphic TFT's  I have been trying to get the STM32F476 Disco board running with the latest Chibios but get many compiler errors but

not familiar enough to work out why.

e.g,   arm-none-eabi-gcc: error: unrecognized argument in option '-mcpu=cortex-m7'

I have been working with Chibios for approx 12 months and think it is great, I managed to get the Ugfx STM32F429 Demo working fine and have been playing,

so when I purchased a STM32F746 - Disco I applied the same method for adding the project to Chibistudio.

I have read in the forum that there is an incompatibility with the HAL in the Chibios and Ugfx although this Forum thread suggests it should compile.

Has anyone successfully manged to get the board working with the latest Chibios ? (16.1.7 Stable)

Any advice or pointers would be appreciated.

 

Thank you.

 

 

[Joel Bodenmann]

Hello @Paul C and welcome to the µGFX community!

 

4 hours ago, Paul C said:

arm-none-eabi-gcc: error: unrecognized argument in option '-mcpu=cortex-m7'

That indicates that you're using a GCC version which doesn't include support for the ARM Cortex-M7 architecture (a too old version of GCC). You need at least GCC version 5.3.1 when I remember correctly.

[steved]

On 13/04/2017 at 22:14, Joel Bodenmann said:

That indicates that you're using a GCC version which doesn't include support for the ARM Cortex-M7 architecture (a too old version of GCC). You need at least GCC version 5.3.1 when I remember correctly.

GCC4.9 works fine.

I'm not using the Discovery, but am using Chibios with uGfx on a STM32F767 Nucleo - there was some reason why I had to use the 'trunk' version of Chibi rather than the latest release. Can't remember for sure, but I think it was to do with F7 support. Certainly didn't have to do anything special.

[Joel Bodenmann]

1 hour ago, steved said:

GCC4.9 works fine.

Not all of them. Many GCC versions 4.9 don't come with Cortex-M7 support yet. But now that you mention it I think you're right. I used GCC 4.9 with Cortex-M7 too. Probably something late like 4.9.7 but I'm really unsure. Either use GCC 5 to be sure or look it up.

[Paul C]

Hi thank you all for the advice, I have always built my projects with GCC 4.7 that comes with Chibistudio, but it also comes with GGC 4.9 and I can confirm this has solved the Compiler problem -mcpu=cortex-m7

At least it compiles now, I'm getting lots of errors but will try to work through them when I get time.

Thanks again.

 

[steved]

1 hour ago, Joel Bodenmann said:

Not all of them. Many GCC versions 4.9 don't come with Cortex-M7 support yet. But now that you mention it I think you're right. I used GCC 4.9 with Cortex-M7 too. Probably something late like 4.9.7 but I'm really unsure. Either use GCC 5 to be sure or look it up.

GCC: (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-br

(It's the one included with Chibistudio 17)

[Joel Bodenmann]

@Paul C: Glad to hear that you are making progress. Don't hesitate to ask if you have any questions. We're happy to help wherever we can!

Great, thanks for the info @Steve!

[cpu20]

@Joel Bodenmann: To continue on the incompatibility topic of these two components, I have been trying to compile the latest ugfx and chibios taken from the respective git page together. I made a new makefile for it based on the chibios_3 one. As many things have changed in the repo's it doesn't work out of the box. Now I get this compiler error:

../../ChibiOS/os/common/ports/ARMCMx/compilers/GCC/chcoreasm_v7m.S:37:23: fatal error: chlicense.h: File or folder does not exist

The only problem is the file is included in my INCPATH and when including it in my .c files it works. But for some reason it does not work for the assembler file.
Do I need to separately include it for the assembler files?

Edit: In case someone is interested in the makefile it's included here

os_chibios_git.mk

Edited April 15, 2017 by cpu20
Including makefile

[inmarket]

My guess is that while the incpath is being sent to the c compiler, it is not being included on the assembler command line.

[cpu20]

Alright, to continue on this topic, I have been looking at te RCC registers and there are some things I don't understand.
In the file stm32f746g_raw32_ugfx.c in the comment is stated that the HSE clock is divided by 25 to get a 1MHz clock to send to the other PLL clocks. But in reality it is divided by 12. Also in board_STM32LTDC.c the value of 1MHz is used to calculate a 9.6MHz clock for the LCD. But due to the division of 12 a LCD clock of 20MHz is achieved. I have no idea why this even works because in the LCD datasheet it states that 12MHz is the maximum. Any idea why this was done?

I have tried in chibios to set the LCD clock to different values including 9.6MHz and 20MHz but nothing works.
Any input on the clock is welcome!

I'll keep searching!

[inmarket]

The initialisation code was based on code originally provided by STM for the stm32f4-discovery board. There was however an issue that caused extreme flickering of the display. From memory the clock rate was increased and this solved that problem. This change might be what you are seeing and it might have been incorrectly rippled into the f7 code although the f7 code is also based on code provided by STM. Unfortunately it has been too long ago.

As this code works on the f7 when running raw32 it has always been my suspicion that ChibiOS has changed the clock settings or the gpio arrangements thus preventing the lcd from working.  I have followed the gpio aspect of that to no avail leaving clocks as the likely culprit.

Note that even in the original STM code the code comments were not always correct.

 

[Joel Bodenmann]

9 hours ago, inmarket said:

Note that even in the original STM code the code comments were not always correct.

This is a common problem. Personally, I just never put the value into the comment but instead just write something like "configure clock rate". It happens just too easily (and therefore too often) that one changes the actual value but not the comment. Often just "for testing" and then it stays like that for a day, then it gets forgotten about, then it gets released as reference code by a huge company such as ST...

[cpu20]

Yeah I think ST is not a great example of good practices.

In the meantime I've forked the uGFX repository and made some changes regarding the incompatibility: https://github.com/cpu20/uGFX-Chibios-STM32F7
I changed the STM32LTDC code to initialize the pins with the Chibios PAL. After some extended testing I'm quite certain the pins are now configured correctly looking at the GPIO registers. Also setting the DISP pin makes the screen go black (when LTDC is initialized) and got white when the DISP pin is cleared.
Playing with alot of different clock configurations did not change anything, which makes me think that the problem is not clock related?
The only thing I can think of that could be a problem is the FLASH/ART-accelerator... I can not find any Chibios code that initializes the I/D-cache on the STM32F7 while when using raw32 they are enabled. Could this form a problem?

As of now I don't really know what to look for. If any ideas let me know and I'll check it out!

[inmarket]

Sounds like you have reached the point we did - nothing obvious seems to fix the problem. 

With regard to the id cache, any difference you find is worth testing

[steved]

I've got uGfx and Chibios running on the 32F767 - but with an SSD1963 on the FMC interface, rather than using the inbuilt controller.

I'd got existing code running on the 32F407, and IIRC the main thing I had to do was resolve some memory caching issues.

You should be able to prove whether caching is the problem by inserting the following line in main(), just after completion of halinit():
 

  SCB_DisableDCache();                  // Disable data cache for testing

This disables the caching completely, and Chibios doesn't usually modify this at present.

I also had to use the version of Chibios from trunk (rather than a specific release) to get processor support, and maybe one or two relevant bug fixes.

[cpu20]

@steved Thanks for the suggestion!
I tried it out but for the moment it still gives me the same result. (black screen)

What I have noticed, is that when initiliazing the LTDC peripheral when using Chibios the frame buffer address (register CFBAR) is set to 0.
When using the raw32 project this address is set to 33792(for the background layer). Is there anyone who can tell me where and how the uGFX library determines the framebuffer address?

[inmarket]

The framebuffer address is set to correspond to the start of the external SDRAM.

[cpu20]

Big morning today because it's fixed!!!

In the end there were two problems related to the GPIO why the whole thing did not work. The pins PG8: FMC_SDCLK and PI12: LCD_DISP_PIN were configured incorrectly thus making the whole thing not work. First the DISP pin was the reason the display stayed white. After fixing that it turned black and the LTDC initialized correctly.

Second thing was that the framebuffer did not work. This was due to the fact that the FMC_SDCLK pin was not initialized at all. Maybe this should be reported back to the Chibios people as this initialization sequence is done somewhere in there code?

After all it was worth the search and the effort

You can find the fixed code on my GitHub page if you want to pull it.

[inmarket]

Great news! I will try to follow that up this weekend.

Thank you for all your hard work on this.

[Joel Bodenmann]

This is awesome, great work! We appreciate this a lot.
For completeness, could you add a link to your repository so we can find the changes? We'll definitely take a look at this and merge it ASAP.

Changes required in the ChibiOS sources should definitely be reported back to the ChibiOS people. Would you take care of that or should we?

[cpu20]

The repo is: https://github.com/cpu20/uGFX-Chibios-STM32F7

It's no problem for me to report back to the ChibiOS people. Should I contact them via mail, forum or report a bug on their GitHub page?