stm32: tests/samples : add support for nucleo_h753zi on some tests and samples

[djiatsaf-st]

This PR adds support for the NUCLEO_H753ZI on several tests and samples for test bench purposes.
It will eventually replace the NUCLEO_H743ZI, which is obsolete, as shown here here

[JarmouniA]

What is the point? it's the same IP as stm32h735g_disco and stm32l496g_disco...

[djiatsaf-st]

Yes, I understand what you mean, but I think it is valid for integration_platforms, not platform_allow. Without specifying this board, Twister will not run this test on the NUCLEO_H753ZI.

[JarmouniA]

Without specifying this board, Twister will not run this test on the NUCLEO_H753ZI.

Exactly my point, we don't need it to, it has no added value.

[erwango]

Context of this change is to use nucleo_h753zi as "H7" champion on the test bench, so we need to it to be present everywhere.
Cleaning up the number of boards present in these files is a good point, but we need to think about it more widely and it's likely a point for testing working group.

[JarmouniA]

use nucleo_h753zi as "H7" champion on the test bench, so we need to it to be present everywhere.

@erwango I don't think it's a great strategy to add a board like this everywhere without looking at the specifics of each sample/test.

Cleaning up the number of boards present in these files is a good point, but we need to think about it more widely

As a starting point #94585

[JarmouniA]

This whole thing needs to be cleaned up, the nodelabel should come from a board/SoC overlay.

[djiatsaf-st]

Yes! I agree with you. For this scope, I propose to do this cleanup in a dedicated PR.

[erwango]

Once again, #81458 would help on this (to avoid multiple overlays).

[djiatsaf-st]

I will propose a PR later incorporating these suggestions.

[JarmouniA]

I will propose a PR later incorporating these suggestions.

okey

[erwango]

I have 2 main points:

• The easy one: Let's provide always the same and complete header file in overlays (Copyright plus license)
• The one to discuss: Should we remove nucleo_h743zi fully from the platform_allow ? From the integration_platform ?

[djiatsaf-st]

• The one to discuss: Should we remove nucleo_h743zi fully from the platform_allow ? From the integration_platform ?

• integration_platform : For sure, I think we should fully remove nucleo_h743zi to avoid wasted resources and add nucleo_h753zi to reflect actively maintained boards.

• platform_allow : I think it is a bit more delicate. In the short term, we can keep nucleo_h743zi to maintain backward compatibility for users who may still have it. Then, we can add a comment in the board documentation (https://docs.zephyrproject.org/latest/boards/st/nucleo_h743zi/doc/index.html) or another appropriate place to suggest users switch to nucleo_h753zi for testing purposes. By the end of this year or later, we can fully remove nucleo_h743zi under platform_allow. I think it is safe to proceed this way and potentially avoid any unexpected situations.

[JarmouniA]

we can keep nucleo_h743zi to maintain backward compatibility

There is no backward compatibility for testing, plus platform_allow/platform_exclude can be overridden globally with Twister arg --force-platform.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud