Strange situation with RTC init, RTC->ICSR INITF flag is constantly 0 after RTCD1.rtc->ICSR |= RTC_ICSR_INIT;
PWR->CR1 DBP is 1
Write protection is disabled.
Any idea what could be wrong?
STM32WLxx port
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32WLxx port
As I understand everything is ok:
Code: Select all
RCC->CSR
LSION [0:0] 0b1
LSIRDY [1:1] 0b1
LSIPRE [4:4] 0b0
RCC->BDSR
RTCSEL [9:8] 0b10 - LSI
RTCEN [15:15] 0b1
mcuconf.h
#define STM32_LSI_ENABLED TRUE
#define STM32_LSIPRE STM32_LSIPRE_NODIV
#define STM32_RTCSEL STM32_RTCSEL_LSI
Vitaly
Re: STM32WLxx port
The same problem with LSE as clock source for RTC.
RTC does not enter initialization mode.
RTC does not enter initialization mode.
Vitaly
Re: STM32WLxx port
RTC initialisation problem solved. RCC_APB1ENR1 RTCAPBEN was not enabled.
Not sure where is the best place to enable it. Is it ok to do it in hal_lld_backup_domain_init HAL_USE_RTC part?
Not sure where is the best place to enable it. Is it ok to do it in hal_lld_backup_domain_init HAL_USE_RTC part?
Vitaly
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32WLxx port
I think in the backup domain initialization for the specific device. The RTC driver does not have a "start" function where this is usually done.
Giovanni
Giovanni
Re: STM32WLxx port
Hi,
new update is attached.
RTC problem fixed and tested: RTC works, Alarms work.
Change log:
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/Makefile -> demos/STM32/RT-STM32WL55JC-NUCLEO64/Makefile
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/cfg/chconf.h -> demos/STM32/RT-STM32WL55JC-NUCLEO64/cfg/chconf.h
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/cfg/halconf.h -> demos/STM32/RT-STM32WL55JC-NUCLEO64/cfg/halconf.h
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/cfg/mcuconf.h -> demos/STM32/RT-STM32WL55JC-NUCLEO64/cfg/mcuconf.h
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/main.c -> demos/STM32/RT-STM32WL55JC-NUCLEO64/main.c
deleted: os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLxxC.ld
renamed: os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLExx8.ld -> os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLxxx8.ld
renamed: os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLExxB.ld -> os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLxxxB.ld
renamed: os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLExxC.ld -> os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLxxxC.ld
renamed: os/hal/boards/ST_NUCLEO_WL55JC/board.c -> os/hal/boards/ST_NUCLEO64_WL55JC/board.c
renamed: os/hal/boards/ST_NUCLEO_WL55JC/board.h -> os/hal/boards/ST_NUCLEO64_WL55JC/board.h
renamed: os/hal/boards/ST_NUCLEO_WL55JC/board.mk -> os/hal/boards/ST_NUCLEO64_WL55JC/board.mk
renamed: os/hal/boards/ST_NUCLEO_WL55JC/cfg/board.chcfg -> os/hal/boards/ST_NUCLEO64_WL55JC/cfg/board.chcfg
renamed: os/hal/boards/ST_NUCLEO_WL55JC/cfg/board.fmpp -> os/hal/boards/ST_NUCLEO64_WL55JC/cfg/board.fmpp
modified: os/hal/ports/STM32/LLD/EXTIv1/stm32_exti.h
modified: os/hal/ports/STM32/LLD/RTCv3/hal_rtc_lld.c
modified: os/hal/ports/STM32/STM32WLxx/hal_lld.c
modified: os/hal/ports/STM32/STM32WLxx/stm32_isr.c
modified: os/hal/ports/STM32/STM32WLxx/stm32_rcc.h
modified: os/hal/ports/STM32/STM32WLxx/stm32_registry.h
new file: tools/ftl/processors/boards/stm32wlxx/templates/board.c.ftl
new file: tools/ftl/processors/boards/stm32wlxx/templates/board.h.ftl
new file: tools/ftl/processors/boards/stm32wlxx/templates/board.mk.ftl
new update is attached.
RTC problem fixed and tested: RTC works, Alarms work.
Change log:
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/Makefile -> demos/STM32/RT-STM32WL55JC-NUCLEO64/Makefile
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/cfg/chconf.h -> demos/STM32/RT-STM32WL55JC-NUCLEO64/cfg/chconf.h
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/cfg/halconf.h -> demos/STM32/RT-STM32WL55JC-NUCLEO64/cfg/halconf.h
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/cfg/mcuconf.h -> demos/STM32/RT-STM32WL55JC-NUCLEO64/cfg/mcuconf.h
renamed: demos/STM32/RT-STM32WL55JC-NUCLEO/main.c -> demos/STM32/RT-STM32WL55JC-NUCLEO64/main.c
deleted: os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLxxC.ld
renamed: os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLExx8.ld -> os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLxxx8.ld
renamed: os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLExxB.ld -> os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLxxxB.ld
renamed: os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLExxC.ld -> os/common/startup/ARMCMx/compilers/GCC/ld/STM32WLxxxC.ld
renamed: os/hal/boards/ST_NUCLEO_WL55JC/board.c -> os/hal/boards/ST_NUCLEO64_WL55JC/board.c
renamed: os/hal/boards/ST_NUCLEO_WL55JC/board.h -> os/hal/boards/ST_NUCLEO64_WL55JC/board.h
renamed: os/hal/boards/ST_NUCLEO_WL55JC/board.mk -> os/hal/boards/ST_NUCLEO64_WL55JC/board.mk
renamed: os/hal/boards/ST_NUCLEO_WL55JC/cfg/board.chcfg -> os/hal/boards/ST_NUCLEO64_WL55JC/cfg/board.chcfg
renamed: os/hal/boards/ST_NUCLEO_WL55JC/cfg/board.fmpp -> os/hal/boards/ST_NUCLEO64_WL55JC/cfg/board.fmpp
modified: os/hal/ports/STM32/LLD/EXTIv1/stm32_exti.h
modified: os/hal/ports/STM32/LLD/RTCv3/hal_rtc_lld.c
modified: os/hal/ports/STM32/STM32WLxx/hal_lld.c
modified: os/hal/ports/STM32/STM32WLxx/stm32_isr.c
modified: os/hal/ports/STM32/STM32WLxx/stm32_rcc.h
modified: os/hal/ports/STM32/STM32WLxx/stm32_registry.h
new file: tools/ftl/processors/boards/stm32wlxx/templates/board.c.ftl
new file: tools/ftl/processors/boards/stm32wlxx/templates/board.h.ftl
new file: tools/ftl/processors/boards/stm32wlxx/templates/board.mk.ftl
- Attachments
-
- stm32wl-port-update-21-04-21.tar.gz
- (36.7 KiB) Downloaded 131 times
Vitaly
Re: STM32WLxx port
Hi,
all changes committed to svn repository.
note:
initially hal_lld.c for stm32wl was based on hal_lld.c for stm32l4, and I've just noted that MSIPLL activation made twice in hal_lld.c: in stm32_clock_init and in hal_lld_backup_domain_init. Is it made intentionally?
all changes committed to svn repository.
note:
initially hal_lld.c for stm32wl was based on hal_lld.c for stm32l4, and I've just noted that MSIPLL activation made twice in hal_lld.c: in stm32_clock_init and in hal_lld_backup_domain_init. Is it made intentionally?
Vitaly
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32WLxx port
I think there is a problem there because that note about LSE... I need to study it again. We need to verify also L4+ and L4 probably.
One possible solution is to do backup domain initialization in clock init and remove the following re-initialization.
Giovanni
One possible solution is to do backup domain initialization in clock init and remove the following re-initialization.
Giovanni
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: STM32WLxx port
OK, I think there are several problems in the current initialization code for some families, this is basically why on the G4 the code is entirely different.
The right thing to do is start converging all families to the G4 standard (much much cleaner), you may start considering it for the WL. I will try to rework L4 and L4+, you could rebase WL on that once it is done.
Giovanni
The right thing to do is start converging all families to the G4 standard (much much cleaner), you may start considering it for the WL. I will try to rework L4 and L4+, you could rebase WL on that once it is done.
Giovanni
Who is online
Users browsing this forum: No registered users and 6 guests