add stm32h755II chip

[jfbblue0922]

Adds compatibility with PX4 NuttX for use with JAE flight controllers.
Here are the changes:
・Added setting ARCH_CHIP_STM32H755II
・Add stm32h7x5xx_rcc.c
・Corrected so that STM32_PWR_CR3_SCUEN is not enabled when SMPS SUPPLY is not used.

[acassis]

Hi @jfbblue0922 thank you for your first contribution! I hope you attend our NuttX International Workshop in Japan next month (more info: https://events.nuttx.apache.org).

Please fix the relative file path name at line 2 of stm32h7x5xx_rcc.c it is failing:

7153852e8f add stm32h755II chip
../nuttx/tools/checkpatch.sh -u -m -g d1992497692e4265684b8211d665fd42936c3b62..HEAD
Error: /home/runner/work/nuttx/nuttx/nuttx/arch/arm/src/stm32h7/stm32h7x5xx_rcc.c:2:1: error: Relative file path does not match actual file
Error: Process completed with exit code 1.

[davids5]

@jfbblue0922 What is the diff from the the exiting rcc look like?

[jfbblue0922]

@acassis

Thank you for your advice.
I've corrected the file.

@davids5

I created a new stm32h7x5xx_rcc.c based on the file stm32h7x3xx_rcc.c.
The current stm32h7x3xx_rcc.c did not work correctly if CONFIG_STM32H7_PWR_DIRECT_SMPS_SUPPLY was disabled.

[davids5]

See inline.

[acassis]

@jfbblue0922 please squash the commits:

https://nuttx.apache.org/docs/latest/contributing/making-changes.html#how-to-include-the-suggestions-on-your-pull-request

[jfbblue0922]

@acassis

I did squash the commits.

[davids5]

@acassis Why did you merge this with a request to change it open?

[acassis]

oops, sorry @davids5 I just saw the approaved and thought is was fixed already.
Also the message "See inline." was followed by a "Outdated" commit

[davids5]

This PR add a file with a #ifdef of an undefined value and and is total code duplication. @acassis How do you want to clean up your oops?

[acassis]

@jfbblue0922 Please consider creating a macro that has different values for that STM32_PWR_CR3 depending on which model of microcontroller is defined.

[jfbblue0922]

@davids5

Thank you for your suggestions.

I would like to revise it again according to your suggestions.

I would like to modify it within stm32h7x3xx_rcc.c instead of creating stm32h7x5xx_rcc.c.

@acassis

Thank you for your advice.

This PR has been merged and closed, but what should we do?

How do I create a macro?

[acassis]

@jfbblue0922 something like:

#if defined(CONFIG_ARCH_CHIP_STM32H755II)
#define STM32_PWR_CR3_VALUE (STM32_PWR_CR3_LDOEN)
#else
#define STM32_PWR_CR3_VALUE (STM32_PWR_CR3_LDOEN | STM32_PWR_CR3_SCUEN)
#endif

Then use the macro STM32_PWR_CR3_VALUE to enable the right bits in both cases.

[jfbblue0922]

@acassis

It turns out that this problem is not specific to stm32h755II.
There are 6 power supply methods for stm32h7.

We use '1.LDO supply' instead of '2.Direct SMPS supply' method.
Therefore, I would like to define CONFIG_STM32H7_PWR_LDO_SUPPLY macro, what do you think?

Now that this PR has been merged, should I create another PR and fix it?

[davids5]

@jfbblue0922 - the Kconfig will need to contain a section, that the chip will enable modes for that package. The user can select mode for that, It is critical that the default for this change defaults to the Exact behavior before this change is applied.

So there should be only one RCC file (remove the added one) and the #ifdef logic to pick the correct values and set up. If the users does not select a value, the default used should be the same as before this change comes in.

The mechanics do correct this: 1) Could be a NEW second PR with only the fixes. OR 2) @acassis should revert the one he merged on accident and you do a new complete PR.