boards/common/stm32: Fix LED configuration

[maribu]

Contribution description

The inverted and non-inverted LED<num>_ON and LED<num>_OFF macros are swapped. This didn't reveal in testing as the LED<num>_IS_INVERTED macros where not properly evaluated, due to a typo in the check. This fixes both.

Testing procedure

I noticed the issues when flashing examples/saul on a Nucleo-F767ZI and all LEDs went up like on a xmas tree

Issues/PRs references

Regression introduced by #18415

[maribu]

@krzysztof-cabaj: Could you give this another test?

It is important to check with the macros, rather than via saul, as the saul shell command takes it information from the gpio_params.h that is separate from the LED<num>_... macros.

[maribu]

Luckily, #18415 didn't make it into the release :)

[krzysztof-cabaj]

@maribu - what exactly should I test? Simple program with LED<...> macros?

[maribu]

Yes. I do believe that e.g. with this

diff --git a/examples/hello-world/main.c b/examples/hello-world/main.c
index f51bf8c0a0..84b88c8fb2 100644
--- a/examples/hello-world/main.c
+++ b/examples/hello-world/main.c
@@ -21,10 +21,14 @@
 
 #include <stdio.h>
 
+#include "board.h"
+
 int main(void)
 {
     puts("Hello World!");
 
+    LED0_ON;
+
     printf("You are running RIOT on a(n) %s board.\n", RIOT_BOARD);
     printf("This board features a(n) %s MCU.\n", RIOT_MCU);

The STM32 disco board with inverted LED will have the LED0 off, instead of of with master. And this PR should then fix the issue again, hopefully.

[krzysztof-cabaj]

@maribu Thanks for clarification. I conduct tests during weekend and describe results ASAP.

[krzysztof-cabaj]

@maribu I use simple program as in you response, only with LED0_ON macro. Results:

RIOT / master (commit 7fce013)

stm32f469i-disco OK (1 on, 3 off)
nucleo-l552ze-q FAILED (1 off, 2 on)

maribu / boards/common/stm32 (commit 73ad5f6)

stm32f469i-disco FAILED (1 off, 3 on)
nucleo-l552ze-q OK (1 on, 2 off)

maribu / master (commit 1066195)
stm32f4691-disco OK (1 on, 3 off)
nucleo-l552ze-q FAILED (1 off, 2 on)

I looked at Nucleo-L552ZE-Q board documentation and in my opinion this particular board do not invert LEDs - see section 6.5, page 22.

[maribu]

If I understand correctly, this breaks behavior for the stm32f4691-disco (it worked correctly when LEDs was configured as not inverted). But it does fix the issue for the Nucleo-L552Z by inverting all LEDs for the Nulceo-144 boards. However, the documentation of that Nucleo indicates it should actually be not inverted.

Does the setting the LED via the saul shell command work correctly for the disco board? If I recall correctly, they are configured for inverted behavior.

[maribu]

The LEDs on the stm32f469i-disco are declared as non-inverted in SAUL as well. I seem to have confused the .flags = SAUL_GPIO_INIT_SET, with .flags = SAUL_GPIO_INVERTED.

Now all should be correct in this PR.

[krzysztof-cabaj]

@maribu

I checked current version of this PR on stm32f469i-disco and now my simple program which use LED0_ON macro works OK.
For nucleo-l552ze-q, too.

However, I have some doubts concerning "naming conversion". For me - inverted LED means that it is ON when we have signal 0/LOW and OFF when we have 1/HIGH signal. But looking at STM docs and current board.h files we have opposite situation. For example, this PR removes LEDX_IS_INVERTED macros for stm32f469i-disco but documentation shows that LED in this board is ON when we set state to 0/LOW (section 4.15/page 21).

[maribu]

Ah, that was the issue :)

[krzysztof-cabaj]

Hi @maribu !

I checked once again the last commit: 77270e2 .
Both my boards stm32f469i-disco and nucleo-l552ze-q set LEDs perfectly!
And I'm completely happy with current "naming conversion" - INVERTED means signal 0/LOW - ON the LED.

[maribu]

Thx for testing and confirming :)

[maribu]

Thx everyone!