ChibiOS Free Embedded RTOS

What kind of generator do you use for it and what should be done to support STM32WLxx mcuconf.h generator?

vrollei wrote:What kind of generator do you use for it and what should be done to support STM32WLxx mcuconf.h generator?

Hi,

It is very simple, there is a script that updates all mcuconf.h files to their latest "spec", it uses a template engine called FMPP. You just run the script and all files are updated keeping their settings. This is the way we use to keep up-to-date all demos in ChibiOS. A port without its scripts risks to be left behind.

If you want to give it a try (I would do it anyway later so don't feel pressed to do it) look into:

- /tools/ftl/processors/conf
- /tools/updater

In addition, also the board files generator requires a script, those are used in ChibiStudio to generate board files, see in:

- /tools/ftl/processors/boards
- /tools/ftl/schema/boards
- /tools/ftl/xml

This is just for your information, no need to proceed, scripts are usually done when ports are reasonably "finished".

Giovanni

Hi Vitaly,
I am setting up to build a test project to run on WL55.
Just to let you know that enabling RTC does not build due to errors:
1. In EXTiv1 (simple to fix by adding STM32WLXX in check at line #48).
2. RTCv3 has errors due to macros not defined/setup in registry.c for RTC (will take a bit more effort).

Can you take a look at those if you have a chance this week or I'll look at it later (but not this week probably).

Thanks
--
Bob

Hi,

I fixed compilation problem,

but RTCv3 should be modified:
- STM32WLxx has no RTC_ICSR_ALRBWF flag, simple way to solve this problem is:



- STM32WLxx has additional flag TAMP_CR2 BKERASE: Backup registers erase - should Backup registers be erased on RTC initialisation?

- STM32WLxx has additional register TAMP_CR3 - should it be initialised with specific value or default value ok (default - not erase backup on temper events)?

If there are too many differences then a new RTCv4 could be considered.

Are those bits missing or just renamed? this happened already in the past.

Giovanni

Hello,

but RTCv3 should be modified:
- STM32WLxx has no RTC_ICSR_ALRBWF flag, simple way to solve this problem is:

STM32L41x and stm32L42x families, which are using RTCv3 (instead of the RTCv2 for other L4), don't have neither RTC_ICSR_ALRBWF flags, and I confirm that the proposed patch is fine : you don't have to wait to be able to write alarm registers, so there is no equivalent bit with different name in different register.

A.

According this doc: https://www.st.com/resource/en/applicat ... ronics.pdf

STM32G0, G1, WL... have all RTC3

But yes, WL does not have ALRAWF/ALRBWF and according documentation there is no need to check any flag before programming AlramA/B just reset ALRAE;

The rest of RTC seems is the same (at least there is no any compilation warning/error), but need to be tested on HW.

If proposed solution to skip ALRAWF/ALRBWF checking is ok, I will update code and check HW.

vrollei wrote:If proposed solution to skip ALRAWF/ALRBWF checking is ok, I will update code and check HW.

OK thanks.

Giovanni

And what about TAMP?

- STM32WLxx has additional flag TAMP_CR2 BKERASE: Backup registers erase - should Backup registers be erased on RTC initialisation?

- STM32WLxx has additional register TAMP_CR3 - should it be initialised with specific value or default value ok (default - not erase backup on temper events)?

For the time being use acceptable defaults (erase on init I guess), we could add configuration options later.

Giovanni