LPTIM1 label causes SysTick/clock configuration to be removed

[Simon151]

I am experiencing two separate issues with the generated LPTIM1 configuration in STM32CubeMX2.

1. Clock configuration is removed when assigning a label to LPTIM1

The first issue occurs when assigning a user label to LPTIM1.

As soon as a label is assigned to LPTIM1 and the code is regenerated, the RCC initialization and peripheral clock configuration are removed from mx_system_init().

The deleted code looks like this:

system_status_t mx_system_init(void)
{
.........
    LL_ICACHE_Enable(ICACHE);

-   /*
-     Clock system section
-   */
-
-   /* Initialize RCC peripheral */
-   if (mx_rcc_init() != SYSTEM_OK)
-   {
-     return SYSTEM_CLOCK_ERROR;
-   }
-
-   /* peripherals clock configuration and activation
-     is centralized: no clock activation/deactivation in pppi_init */
-
-   if (mx_rcc_peripherals_clock_config() != SYSTEM_OK)
-   {
-     return SYSTEM_CLOCK_ERROR;
-   }

.........

Therefore, the calls to

mx_rcc_init();
mx_rcc_peripherals_clock_config();

are no longer present after assigning the LPTIM1 label.

As a consequence, the system clock is no longer initialized correctly and the application gets stuck later during ADC calibration.

Removing the user label from LPTIM1 and regenerating the code restores the clock configuration.

2. Unrelated I2C2 interrupt definitions are generated for LPTIM1

The second issue is independent of whether a user label is assigned to LPTIM1.

Inside the generated mx_lptim1.h, I2C2 interrupt definitions are generated for LPTIM1, for example:

#define BUZZER_TIMER_IRQn       I2C2_ERR_IRQn
#define BUZZER_TIMER_IRQHandler I2C2_ERR_IRQHandler

#define _IRQn       BUZZER_TIMER_IRQn
#define _IRQHandler BUZZER_TIMER_IRQHandler

The same issue is present even when no user label is assigned.

I2C2 is not related to LPTIM1 in this configuration, so I would not expect I2C2_ERR_IRQn or I2C2_ERR_IRQHandler to appear in the generated LPTIM1 header at all.

Has anyone seen similar behavior with STM32CubeMX2, or could this be a code generation issue?

[Saket_Om]

Hello ​@Simon151 

We are not able to reproduce your issue. Could you please share your .ioc2 file? 

[DLech.2]

Hi

As it seems I hit the same problem with my small example.

I created a CubeMX2 config based on an example and up on first execution -  still only the generated code allone - my program aborted in the LPTIM1 init function.

As it turned out because of a timeout in “HAL_LPTIM_SetConfig” while waiting for the LPTIM REPOK flag to be properly set.

After a while of digging I noticed that my LSI was not activated and this lead me to this post.

After removing the LPTIM lable - which I just entered because the example also did it - the newly generated code initialized just fine.

 

I attached my “.ioc2” file as a zip, because it seems the attachment currently doesn’t allow that file type.  

The generated “mx_system.c” file changed as follows:

diff --git a/demos/NUCLEO-C542RC_FreeRTOS_lowpower_demo/generated/hal/mx_system.c b/demos/NUCLEO-C542RC_FreeRTOS_lowpower_demo/generated/hal/mx_system.c
index 7b931c5..ea9f0c2 100644
--- a/demos/NUCLEO-C542RC_FreeRTOS_lowpower_demo/generated/hal/mx_system.c
+++ b/demos/NUCLEO-C542RC_FreeRTOS_lowpower_demo/generated/hal/mx_system.c
@@ -75,6 +75,32 @@ system_status_t mx_system_init(void)
   }

   /*
+    Clock system section
+  */
+
+  /* Initialize RCC peripheral */
+  if (mx_rcc_init() != SYSTEM_OK)
+  {
+    return SYSTEM_CLOCK_ERROR;
+  }
+
+  /* peripherals clock configuration and activation
+    is centralized: no clock activation/deactivation in pppi_init */
+
+  if (mx_rcc_peripherals_clock_config() != SYSTEM_OK)
+  {
+    return SYSTEM_CLOCK_ERROR;
+  }
+
+  /*
+    Power section
+  */
+  if (mx_pwr_init() != SYSTEM_OK)
+  {
+    return SYSTEM_POWER_ERROR;
+  }
+
+  /*
     Peripheral init section
   */

I hope this helps in reproducing the issue.

[Saket_Om]

Hello ​@DLech.2 and ​@Simon151 

Thank you for bringing this issue to our attention.

I reported this internally.

Internal ticket number: CDM0066172 (This is an internal tracking number and is not accessible or usable by customers).