Skip to main content
Rob.Riggs
Senior
February 15, 2017
Question

STM32L432KC RTC Init Fails after DFU

  • February 15, 2017
  • 2 replies
  • 1628 views
Posted on February 15, 2017 at 04:36

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 #stm32l4
This topic has been closed for replies.

2 replies

Nesrine M_O
Associate
February 15, 2017
Posted on February 15, 2017 at 09:34

Hi

Riggs.Rob

,

  • Have you try to start from ready RTC example under the STM32L4 firmawre package; please try it and let us khnow about the result :STM32Cube_FW_L4_V1.6.0\Projects\STM32L432KC-Nucleo\Examples\RTC
  • I created a PCB based on the STM32L432KC.

Please refer to

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/93/81/9b/8d/2f/09/4a/e8/DM00125306/files/DM00125pdf/jcr:content/translations/en.DM00125pdf

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

Rob.Riggs
Rob.RiggsAuthor
Senior
March 12, 2017
Posted on March 12, 2017 at 00:24

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

Rob.Riggs
Rob.RiggsAuthor
Senior
February 16, 2017
Posted on February 16, 2017 at 04:04

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.

  1. When I flash the Nucleo board using the Nucleo's on-board programmer (drag & drop), it works fine.
  2. When I flash the Nucleo using the MCU's system bootloader via USB it fails in the same way that my code fails on my board.

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?

Gasper Korinsek_2
Visitor II
February 14, 2018
Posted on February 14, 2018 at 15:52

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.

Bruno Randolf
Visitor II
June 5, 2018
Posted on June 05, 2018 at 17:27

Yes, setting the RTCAPBEN bit is the solution also in my case on STM32L433