2017-02-14 07:36 PM
I created a PCB based on the STM32L432KC. It uses an LSE for the RTC. I am using STMCubeMX 4.0 to create the initialization code with version 1.6.0 of the STM32L4 HAL library.
The system starts up fine from a reset, but when exiting the DFU, it ends up calling the error handler in MX_RTC_Init(). I've tried disabling the LSE in the clock configuration (using LSI). The results do not change.
This is the initialization code (from STM32CubeMX -- I only updated the error handler).
/* RTC init function */
static void MX_RTC_Init(void)
{
/**Initialize RTC Only
*/
hrtc.Instance = RTC;
hrtc.Init.HourFormat = RTC_HOURFORMAT_24;
hrtc.Init.AsynchPrediv = 127;
hrtc.Init.SynchPrediv = 255;
hrtc.Init.OutPut = RTC_OUTPUT_DISABLE;
hrtc.Init.OutPutRemap = RTC_OUTPUT_REMAP_NONE;
hrtc.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH;
hrtc.Init.OutPutType = RTC_OUTPUT_TYPE_OPENDRAIN;
if (HAL_RTC_Init(&hrtc) != HAL_OK)
{
My_Error_Handler(2, 0);
}
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?
If I avoid using the RTC, the system starts up just fine after the DFU.
I suspect that something is not being reset properly (maybe in RCC) after DFU, but I'm not sure what that is.
I have read through the errata and through AN26 I do have the buggy bootloader in the chips I have (Version Information ID = 0xFF) but this issue is not mentioned.
Is this a known issue? Did I miss some note about this behavior in an application note somewhere?
Thanks for any light you can shed on this issue.
#rtc #dfu #stm32l42017-02-15 12:34 AM
Hi
Riggs.Rob
,I created a PCB based on the STM32L432KC.
Please refer to
application note to verify your PCB implementation-Nesrine-
You are an STM32 user and want to express your trust for our products and win a 3D printer? Get your chance participating in
https://community.st.com/community/stm32-community/embedded-world-contest
2017-02-15 07:04 PM
Hi Nesrine,
Thanks for these suggestions. They were helpful. I took the time to review the hardware development application note again. I did not see anything that stood out to me.
I took the RTC_Alarm example and built it for one of the STM32L432KC-Nucleo boards I have here.
I connected a MicroUSB port to PA11 & PA12 on the Nucleo board and used the system bootloader to flash the board via USB as I am doing with my board. After the bootloader exits, the example code enters the Error_Handler() function. This is apparent because LED3 flashes at a 2 second interval. Upon reset, the code functions as expected. This is the same behavior that I am seeing.
It seems that this same behavior exists on a reference hardware device using the reference software. It is possible that it is due to my toolchain (Eclipse/GCC/Linux), but that would be a bit surprising. Can you have someone try to replicate this issue?
2017-03-11 04:24 PM
Hi Nesrine,
Can you tell me the status of this issue? Has an STM engineer been able to replicate this behavior?
I am having the same issue with an STM32L433CC, STM32CubeMX 4.20 and STM32L4 library 1.7.0.
Rob
2017-03-25 10:46 AM
Hi Nesrine,
I have confirmed that this issue still exists with system bootloader version 0x10 on the STM32L43xx series. And the problem can be replicated just by entering and leaving the system USB DFU bootloader. I have not tried any of the other interfaces.
Rob
2017-06-26 07:30 AM
Hi
ELMHIRI.Syrine
,Can you provide an update on this issue? Has it been replicated by ST, accepted, fixed and/or worked around?
Thanks,
Rob
2018-02-14 07:52 AM
Hi Rob,
I've had the same issue on STM32F769 MCU when using USART1 interface. After some digging i've found that the system bootloader clears the RTCAPBEN bit in the RCC_APB1ENR register (normally after reset this bit is set by default).
Solution is to manually call __HAL_RCC_RTC_CLK_ENABLE() which sets RTCAPBEN bit in your application.
2018-06-05 10:27 AM
Yes, setting the RTCAPBEN bit is the solution also in my case on STM32L433