Issues with STM32H750B-DK Board Bring Up For TouchGFX

[Michael_GetElectronic]

Hello awesome people of the STM community! 

I'm working on a GUI project for the STM32H750B-DK, currently following the board bring up steps. I know that I could just use the generated code by TouchGFX template for the STM32H750B-DK. However, I have a few reasons for avoiding this:

• Being an engineering student I want to learn as much as I can form this project, by doing board bring up I can learn more step by step then just pressing a button and have it magically work (though magically work is getting more and more appealing) .
• The GUI is only one aspect of the project, I want to have accesses to a debugger in my preferred IDE (CLion) and not be reliant on constantly uploading through TouchGFX. I would much rather finish the GUI and upload the assets to external flash then just work in internal flash for the remainder of the project.
• I want to get the skills to do a board bring up for when I need a GUI for a custom board.
• Again being a mere engineering student I don't want to jump in the deep end with all the more sophisticated things that TouchGFX will generate, while I have used FreeRTOS before I would rather get TouchGFX working without an RTOS then move to using one later.

Bellow is my process so far 

Blinky Test - Of note on my board the user LEDs are labeled LD6, LD7 and LD8, however, in the default pin out of the template MX file for the STM32H750B-DK Board, they are instead LD1 and LD2 and the colors are mixed up. If I get board I might go track down the pin for the third user LED since I can't find it listed anywhere in MX but it physically exists, not a biggie though.

Board Bring Up:

1. Create Project, did not set all peripherals to default modes, I want to learn as I go, everything I do I want to understand why I'm doing it. 

2. CPU Running, no worries here.

3. Display with framebuffer in internal RAM, just get a white screen after following instructions, interestingly frame rate is all over the show anywhere between 1 and 20 ms, see problem #1

4. External RAM, Confused by SDRAM timing in MX after looking at TouchGFX generated code, FMC_SDRAM example and IS42S32400J-6BL data sheet, unable to view in Clion Debugger, see problem #2

ToughGFX Generated GUI- Works, I've been copying parameters from the MX file made by GFX to my .ioc with little luck.

Problem #1 

I've not been able to get a solid color to show on the LCD using the bellow config for the LTDC with a LTDC clock of 8.602151 Mhz.

This was copied from the TouchGFX Generated .ioc so i would not expect any problems here, I think the only thing I changed was the layer background color. However,  the datasheet for the display driver OTA5180A has slightly different values for the timings in section 10.1.1, or am I miss reading something? Most notably the horizontal back porch is set to 3 while the minimum specified in the datasheet is 8. So I'm not sure I understand the functions of these values or how they are calculated, all I think I know is they have some effect on the frame rate. Then in the firmware I add all appropriate code as listed in the TouchGFX board bring up documentation.

However, the screen stays white, don't even get the background color, I have used CLions memory viewer to make sure that the frame buffer is getting filled which it is. So my best guess is that the LTDC pointer to the framebuffer it is not getting set correctlly but I'm unsure how to check this or fix it. As I mentioned above I'm also getting some strange framerates.

Problem #2

Having been stuck with problem #1 for a few hours I decided to to try load the frame buffer in external RAM, that also did not work. I have an even smaller understanding of the FMC then the LTDC. I set it up with the values used in the GFX generated .ioc plus set up the block in the memory management tool but my debugger was unable to access the location, nor was code able to interact with the memory location without a hard fault.

 

My guess here is timing issues so I had a look at the datasheet (IS42S32400J-6B) and MX example, the only thing that stood out to me was that the Write Recovery timings were different, but in a way that cubeMX says is incorrect.

CubeMX says that RowCycleDelay - RowToColumnDelay - RowPrechargeDelay <= WriteRecoveryTime, however the example provided by CubeMX does not respect that, unless I've made a mistake somewhere? I've looked at the timings in datasheet for the IS42S32400J-6B. Those timings confused me even more, I'm unsure what some of the timing parameters are because they use slightly different names.

I would greatly appreciate any guidance that anyone has, and I appreciate your patience reading this.

Cheers,

Michael

[STM_Thirty2 · Accepted solution]

Hey Michael, 

As a relatively new engineer myself (3 years) I spent countless hours learning how to do it on my own from scratch and I have a YouTube channel on doing everything at the register level.  I will tell you that if I could go back in time and instead learn how to use the tools available to me, not  reinventing the wheel, not favoring any toolchain, and learning how to write good firmware and application code,  I would do it in a heart beat. 

When I got my first job it wasn't up to me to decide what IDE we use for the project, its the boss's call. I had to play catch up really fast because all I knew was how to make things from scratch. I did not know how to work with other engineers code and projects, because you will hardly be in a situation where the company has zero code base and zero of the project done, its always building off of their own previous work and existing code base. Learning how to read others code and gracefully implement your changes in to theirs is a much more useful skill. 

Some companies use IAR because it comes with many certifications, for them that means they do not have to jump through hoops to get their code certified.

Some use STM32CubeIDE because it is what we officially support and I had to do the same to be inline with my colleagues and commit to the common code base.

Companies want to make money and time to market is critical, doing things from scratch does not help that cause. 

Out of the many customers I support everyone one of them starts their project from a working example and builds on it. 

And yes there are circumstances when you will have to do a TouchGFX board bring up from scratch, but staying inline as close as possible with what the chip vendor supports (STM32CubeIDE/IAR) will always get you faster support, and for companies support is also critical. 

As for the settings in CubeMX I would obviously suggest sticking to what we know works and was tested, save yourself the time of trying to test why the datasheet numbers might not be the best option or maybe are wrong, or maybe there is an errata, or the calculations are not as straightforward as plugging in datasheet values. 

I suggest looking at simpler examples in the Repository folder of your installation for guidance.

and I highly encourage the use of FreeRTOS with TouchGFX. 

I have planned an upcoming video series here for ST on board bring up but its on the backburner for now, low bandwidth on my day to day.

Remember we are ALL standing on the shoulders of giants before us and there is no shame in that. 

Regards,

Eddie

[Michael_GetElectronic]

Hi Eddie,

Thank you very much for your reply, I will take that on board and make the switch over to the GFX generated code, is there anyway to connect to the GDB server for debugging while flashing the code from touchGFX Designer?

Unfortunately, for me (and fortunately in some ways), I am actually the first engineer at my company, it's a hardware repair company so all my colleague are repair technicians, but they wanted to bring on a part time intern to develop tools to improve efficiency, so I've got run of the crop when it comes to how things are done, which is very unusual for an engineer as you say, let alone an intern! 

I will also investigate making the switch over to IAR.

Cheers,

Michael  

[STM_Thirty2]

You should still be able to open up a terminal and start stlink-server or openocd and attach arm gdb to it, you just need to find where TouchGFX has the elf file it generated so that you can load it in gdb and have debug symbols. but at that point you're just better off opening the project and STM32CubeIDE and flashing/debugging from there. 

And I was not necessarily pitching a switch to IAR, its not free ands not cheap, only when the end application requires some certifications that STM32CubeIDE cannot meet is when I would recommend it. 

[Michael_GetElectronic]

Awesome, thank you! Yes I did have a quick look into IAR and it is a little overkill for this project, I will just switch back to CubeIDE. Thanks for all your help! Hopefully final follow up question, when flashing form CubeIDE, I assume it uses a bootloader generated by TouchGFX to load the assets into external Flash? Or do I need to use CubeProgramer to load the external elf file?

[STM_Thirty2]

So we have the concept of External loaders. If you selected the proper board as the base for the Designer project, the STM32CubeIDE project it generates should have it preconfigured to use the external loader as seen below in the debug configurations:

If it is not there then click add and find that external loader.

Optionally you could load a preexisting demo or example based on the same board and check out its settings.