Is CubeMX reliable at generating a "default" config for a discovery board?

[SNort.1]

Firstly come context:

I have seen some differences in my sandbox project between what CubeMX auto-generates for my STM32H745I-DISCO and working examples I can download from github. Different GPIO settings which seem significant, for example. The ST github demo code works, but the generated code doesn't (even when I add device specific config). I can hot swap the working parts out of github demo code into user sections of generated code to get things to function with the other generated stuff. Which seems not the idea!

I have also created a new project for this specific discovery board and let CubeMX go ahead and generate its idea of a default config for a project. When looking through some of the RAM timings and display settings in the resulting .ioc file (and being reasonably familiar with the normal settings now) what I am getting seems to be totally wrong. SDRAM timings all set to 16 cycles, display dimensions that are nothing like the board I have, or simply zero...

So my questions are:

Is my install borked?

Am I expecting too much?

Should I assume that even when CubeMX is aware of the board it is developing against that this just doesn't go all the way and you are still expected to complete the config for devices on the discovery boards?

Or am I missing something obvious?

I actualy want to use the Pinout & Config stuff in CubeMX and keep this code reasonably portable as I evalute different HW options. But tbh at this point I think I've spent more time troubleshooting this when I could just write this all manually using ST's own examples on github...

[TDK]

It's generally pretty good but it's clearly not rigorously tested before being shipped out to the public, as with most things in CubeMX.

Expect to require some work to get up and running. SDRAM timings should be able to be determined from CubeMX board examples.

[Sara BEN HADJ YAHYA]

Hi @SNort.1​ ,

Which CubeMX version are you using? and could you please share the .ioc file and specify which demo you followed?

Thanks,

Sara.

[Sirma Siang]

Hello @SNort.1​ ,

Could you help me to clarify several points, like:

• There are several example, in the STM32H745I-DISCO directory from GitHub. Which one are you referring to ?
• When you create a new STM32H745I project, MX generate the MCU initialization code. When you create a new project, by selecting STM32H745I-DISCO board, MX uses the same config as the default FW that is flashed in the board when you receive it (let's call it the default SW), that might explain the difference you are mentioning. Could you detail a bit more your different steps ?
• When you says :"demo code works, but the generated code doesn't", I understand that the build is ok, but it does not run on the HW. Do I understand right ?
• About the SDRAM and display settings, do you mean that the IOC does not reflect the values you have set in the GUI ?

I will do several try in my side, but I will appreciate your inputs.

Great thanks in advance

Marc

[SNort.1]

Hi Sara,

Thanks for your reply. It's version 1.7.0, which I believe is the latest?

I've attached the .ioc file. This is a default config I let the IDE generate when I selected the STM32H745I-DISCO board as the base for the project.

It actually asserts when setting up in MX_QUADSPI_Init if memory serves.

After a quick inspection I wasn't convinced that all of the GPIO settings were correct, nor the FMC SDRAM timings.

Kind regards,

Stephen

[Sara BEN HADJ YAHYA]

Hi @SNort.1​ ,

1) The SDRAM timing values are correct. In the Reference manual (RM0399) page 917, the reset value of SDRAM Timing registers for SDRAM memory bank x (FMC_SDTRx) is 0x0FFF FFFF, this value sets all the timing parameters to the value 16.

2) About the GPIO settings, could you please be more specific about it.

3) And about the display settings, did you mean that in the LTDC parameter settings the values of Active Width and Active Height should be 480x272 instead of 640x480 ?

Regards,

Sara.

[SNort.1]

Hi Marc,

Thanks for your reply. I'll try to answer your questions..

• There are several example, in the STM32H745I-DISCO directory from GitHub. Which one are you referring to ?

I am referring to the BSP driver code here : https://github.com/STMicroelectronics/STM32CubeH7

• When you create a new STM32H745I project, MX generate the MCU initialization code. When you create a new project, by selecting STM32H745I-DISCO board, MX uses the same config as the default FW that is flashed in the board when you receive it (let's call it the default SW), that might explain the difference you are mentioning. Could you detail a bit more your different steps ?

Hmm... In all cases I made the CubeMX projects with the DISCO board as the base. In my main sandbox I asked it not to auto generate anything and I set it up using the Pinout tools manually and let that generate the MX code. When troubleshooting my SDRAM setup I looked at the BSP code and examples on your github for references on timing etc. and used those values to configure the FMC etc. While doing that I also tried the BSP code that initialises SDRAM and saw it was working. Based on that I started looking for differences. Things I had missed, for example =)

What I found in one case was that if I simpluy relaced the autogenerated MX code for GPIO config with the BSP code things would work for me.

It was then I noticed that the GPIO config did look a little different. Specifically which GPIO sections were being used by the MX code. The actual pin settings seemed to be correct - most are duplicated acrosss all pins for A and D lines etc.

To clarify here for all the GPIO settings I used the UI to generate the pin config when setting up the FMC module and then followed ST documents which walk through specific settings for this baord and chip config. I also sanity checked the settings against circuit diagrams / datasheets of the discovery board.

• When you says :"demo code works, but the generated code doesn't", I understand that the build is ok, but it does not run on the HW. Do I understand right ?

Most of the generated code runs. But I was seeing issues around FMC / SDRAM initialisation.

With the BSP code it all worked fine in all cases. LTDC config, SDRAM config etc. etc.

• About the SDRAM and display settings, do you mean that the IOC does not reflect the values you have set in the GUI ?

It seems to match what I have in the UI. Remember some of this is autogenerated also when you configure componetns like FMC.

However, that autogenerate code doesn't seem to match in all cases the code in BSP code.

For example: Write Recovery Time on SDRAM banks is forced to 3 in the UI, but in the BSP code it is set to 2 like Row to column delay, pre-charge delay and register to active delay.

This, whilst probably not a big issue, seems odd when it is for the same config.

I think this is a lot to try and troubleshoot through the forum. So probably some confirmation from your colleague about my reply above about whether the .ioc file is ok or is broken would be most helpful from my perspective. Then I can start looking at whether my install is at fault or if there is a bigger issue.

Kind regards,

Stephen 

[SNort.1]

Hi Sara,

Thanks for the feedback. I am suprised the SDRAM timing is correct. The values I have been using are significantly different (lower), but that is on the M7 side. So maybe that is why.

Regarding the Active Height and Active Width.. All of those values were 0 in the UI in CubeMX for me. So I wonder if there is a problem there if the values are showing up in the .ino file.

I guess for me the most worrying thing is with a stock Discovery board, and the default setup from CubeMX the code generated stops working once it gets to the QuadSPI setup... Is it possible I have an issue with my board?

I generated this project as a clean one as a sanity check of both CubeMX and the DISCO board. I assume it is fair to assume that should "just work", right?

Kind regards,

Stephen

[Sara BEN HADJ YAHYA · Accepted solution]

Hi @SNort.1​ ,

About the SDRAM timing values, the value 16 is a default value but you can use lower value (please refer to the RM0399 for more details).

Unfortunately, the execution of a generated code using default setup (initialization) from CubeMX is not guaranteed. This issue is already reported.

I don't think that your board have any issue since the demo example works correctly on it. For now, I advise you to clear Pinouts and configure each peripheral from scratch.

Thanks for your contribution and If you have any further question please do not hesitate to ask me.

If your question is answered, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly 🙂.

Regards,

Sara.

[SNort.1]

Thanks for your help Sara. I think I have the baseline info I need now. =)