STM23WL Compile Errors and proposed sleep change

[spike314]

I am trying to get my WIO-E5 modules (STM32WLE5JC) working with the latest MySensors development branch. I have run into 5 compile errors. These are due to different functionality between processor families and also inconsistent handling in the Arduino STM32 HAL code:

• AES is defined in both the Arduino STM32WL codebase and in MySensors
• error: '__HAL_RCC_PWR_CLK_ENABLE' was not declared in this scope
• error: 'struct RTC_TypeDef' has no member named 'ISR'; did you mean 'SSR'?
• error: 'RTC_ISR_INITS' was not declared in this scope; did you mean 'RTC_ICSR_INITS'?
• error: too few arguments to function 'HAL_StatusTypeDef HAL_RTCEx_SetWakeUpTimer_IT(RTC_HandleTypeDef*, uint32_t, uint32_t, uint32_t)'

The AES error is easily resolved using an #undef at the beginning and a new #define at the end of MyCryptoGeneric.cpp

The remaining compile errors are related to low-level sleep functions. Rather than track these down for the STM32WL processors, I propose a change to STM32 sleep handling in general. The Arduino STM32 code includes a LowPower library which provides a higher level interface to the sleep functions. Advantages to using the library functions:

• MySensors code is greatly simplified. 5 low level functions can be removed.
• Should minimize MySensors code changes as people try different STM32 processors in the future.
• The LowPower library is required for installing the Arduino STM32 library, so it will always be available
• Arduino STM32 core developers adapt to their own HAL and incorporate new STM32 processors when they are released.
  The main disadvantage I see is that MySensors code becomes dependent on an external library.

I have a working copy on my github: https://github.com/spike314/MySensors/tree/STM32CoreTest3
You can look at that branch to see the necessary changes. This is not really new code. It was from the early KooLru pull request for STM32.
I have successfully slept and woke from timer and 2 different pin interrupts on the STM32WL, STM32411CE black pill, and STM32F1 blue bill. I do not get any compile errors for the STM32U0, but I did not have a board to test the functionality. @nschurando If you could test using the code in my STM32CoreTest3 branch, it would be much appreciated.

Pls take a look. If the changes in that branch are acceptable, I could start a pull request.
I am @nagelc on the MySensors Forum if you want to start a discussion over there.

[dirkju]

FWIW I can confirm that the sleep implementation works for STM32401CE black pill.

How would you go about the library dependencies for STM32LowPower and STM32RTC? Any Mysensors STM32 would require those extra libraries. STM32 is the only architecture with this issue. Every other HAL only uses includes that are bundled with their respective platform.

[spike314]

@dirkju Thanks for doing the test.

With regards to the dependencies, . . . Argh! Every time I have installed the STM32 core boards to Arduino, it has listed these libraries as dependencies and asked to install them at the same time. I tried again yesterday to check and (of course) no. It no longer asked for them to be installed. Not sure when this changed, but I missed it.
I'm now less keen on this approach for MySensors, given the intended audience.
I'll sleep on it.

[nschurando]

Hi @spike314. Unfortunately I won't have time to look into this in details for maybe a month, but on paper, if the functions already exist in the low power library that is part of the Arduino framework for STM32, it feels logical to use them. Unless we need more control over sleep? Maybe someone with more insight like @tekka007 could shine a light here.

[nschurando]

I'll sleep on it.

Pun intended?

[dirkju]

arduino-cli already supports dependencies via sketch.yaml. But the IDE is not there yet. See arduino/arduino-ide#2573 (comment)

[spike314]

So, I put in some elbow grease and got a HAL based sleep working for the STM32WL. I need to clean it up and do some testing. I'll close this issue and go for the version that doesn't have the additional dependencies.