FLASH_SIZE incorrectly reports flash size for cat.2 devices with DEV_ID 0x429

smt32lxx_hal_flash.h
#define FLASH_SIZE                (uint32_t)((*((uint32_t *)FLASHSIZE_BASE)&0xFFFFU) * 1024U)

From Reference Manual
Note: For DEV_ID = 0x429, only LSB part of F_SIZE: F_SIZE[7:0] is valid. The MSB part 
F_SIZE[15:8] is reserved and must be ignored.

Hi,

did you intentionally not put the linkerfiles in to this repo for gcc`?

https://github.com/STMicroelectronics/STM32CubeL1/tree/master/Drivers/CMSIS/Device/ST/STM32L1xx/Source/Templates/gcc

Regards Stefan

Describe the set-up

• STM32CubeL1 v1.10.3

Describe the bug

• stm32l151xc.h lacks definitions for channel 27, 28 and 29 in the ADC sample time register 1 (ADC_SMPR1)

How To Reproduce

1. Get STM32CubeL1 v1.10.3.

2. Inspect section Bit definition for ADC_SMPR1 register in stm32l151xc.h starting at line 986.
   There are definitions for channel 20 to channel 26 only, channel 27, 28 an 29 are missing.

3. Check RM0038 Reference Manual chapter 12.15.4 ADC sample time register 1 (ADC_SMPR1)
   The sample time can be configured for channel 20 to channel 29.

Describe the set-up

• arm-none-eabi-gcc
• #include <stm32f3xx.h>

Describe the bug

HRTIM_TIM_TypeDef is undefined. After cross referencing this with the RM you probably meant to use HRTIM_Timerx_TypeDef.

How To Reproduce

Trying to access HRTIM1_TIMA in any code will fail, since HRTIM_TIM_TypeDef is undefined:

#include <stm32f3xx.h>
HRTIM1_TIMA->TIMxCR = 0;

Additional context

-#define HRTIM1_TIMA         ((HRTIM_TIM_TypeDef *) HRTIM1_TIMA_BASE)
-#define HRTIM1_TIMB         ((HRTIM_TIM_TypeDef *) HRTIM1_TIMB_BASE)
-#define HRTIM1_TIMC         ((HRTIM_TIM_TypeDef *) HRTIM1_TIMC_BASE)
-#define HRTIM1_TIMD         ((HRTIM_TIM_TypeDef *) HRTIM1_TIMD_BASE)
-#define HRTIM1_TIME         ((HRTIM_TIM_TypeDef *) HRTIM1_TIME_BASE)
+#define HRTIM1_TIMA         ((HRTIM_Timerx_TypeDef *) HRTIM1_TIMA_BASE)
+#define HRTIM1_TIMB         ((HRTIM_Timerx_TypeDef *) HRTIM1_TIMB_BASE)
+#define HRTIM1_TIMC         ((HRTIM_Timerx_TypeDef *) HRTIM1_TIMC_BASE)
+#define HRTIM1_TIMD         ((HRTIM_Timerx_TypeDef *) HRTIM1_TIMD_BASE)
+#define HRTIM1_TIME         ((HRTIM_Timerx_TypeDef *) HRTIM1_TIME_BASE)

Full patch
Related to STMicroelectronics/STM32CubeH7#2.

The code does not compile in Motorola mode.
Or is it a bug in CMSIS?
Because file stm32l100xb.h has no information about Bit4 FRF from SPI_CR2.
(Missing lines
#define SPI_CR2_FRF_Pos (4U)
#define SPI_CR2_FRF_Msk (0x1UL << SPI_CR2_FRF_Pos) /*!< 0x00000010 /
#define SPI_CR2_FRF SPI_CR2_FRF_Msk /!< Frame format */
)
Description: https://community.st.com/s/question/0D53W00001FopFbSAJ/errors-in-the-configurator-of-the-stm32cubeide-for-microcontroller-stm32l100rb-not-observed-for-stm32f103-etc-low-layer-only

Caution
In v1.10.3, SCB->VTOR is not set by default and remains at 0x00000000.
Nevertheless, g_pfnVectors will be placed at 0x08000000.
So if you run the default project in STM32CubeIDE, you will get a HardFault from SysTick Exception.

Describe the set-up

• Custom board with STM32L151CB
• STM32CubeIDE and FW_L1 V1.10.3

Describe the bug
In the project's default configuration, USER_VECT_TAB_ADDRESS is not defined and VTOR remains at 0x00000000, resulting in a HardFault.
Is this intended?

How To Reproduce

1. Open STM32CubeIDE 1.6.1(or 1.7.0)

2. Create New STM32 Project

3. Select STM32L151CB-A

4. Select V1.10.3 Firmware

5. Build and Program and Run

Additional context

Screenshots

Bug observed during use of the STM32Cube HAL, imported/used in Zephyr OS.

During my own testing I've observed that for the following SoCs it has been defined that BRR registers are available, even though this isn't the case (according to the reference manual).

• stm32l100xc
• stm32l152xc
• stm32l151xc
• stm32l151xca
• stm32l162xc
• stm32l162xca

In the SoC headers (e.g. in Zephyr: modules/hal/stm32/stm32cube/stm32l1xx/soc/stm32l100xc.h) #define GPIO_BRR_BR_0 (0x00000001U) has been defined, which has an influence on LL_GPIO_ResetOutputPin() in stm32l1xx/drivers/include/stm32l1xx_ll_gpio.h, which has the following condition:

#if defined(GPIO_BRR_BR_0)
  WRITE_REG(GPIOx->BRR, PinMask);
#else
  WRITE_REG(GPIOx->BSRR, (PinMask << 16));
#endif /* GPIO_BRR_BR_0 */

This causes the behaviour that if one would like to put a GPIO pin to 0, the SoC can't write to the proper registers (BSRR), because GPIO_BRR_BR_0 has been defined, even though the SoCs don't have the BRR register.

In the reference manual [click] pg 188 it says that the BRR registers are only available on Cat 4-6 devices. On pg 41 it shows that the SoCs listed above (L1xxxC) are Cat 3.

Please fix asap, since it can have a large impact on the GPIO functionalities of these SoCs

Like F1, it appears that L1's HID classes are not standards compliant despite being claimed to be:

for more info, see: STMicroelectronics/STM32CubeF1#41

https://github.com/STMicroelectronics/STM32CubeL1/blob/master/Middlewares/ST/STM32_USB_Device_Library/Class/HID/Src/usbd_hid.c#L446

Describe the set-up

• The board: NUCLEO-L152RE

Describe the bug
SystemCoreClockUpdate() does not work correctly when SYSCLK source is HSI.

If SYSCLK source is HSI and HSI_VALUE is not defined, SystemCoreClockUpdate() cannot update SystemCoreClock correctly.

According to the STM32L1 microcontorollers specification, the HSI value is 16MHz.
Also, the comment of SystemCoreClockUpdate() describes that the default HSI_VALUE is 16MHz.

HSI_VALUE can be adapted by the user appliication, but I think default HSI_VALUE should be 16MHz.

How To Reproduce
HSI_VALUE is not defined.
To get 32MHz HCLK, I set

• Use HSI
• PLLMul x6
• PLLDiv /3

After setting these parameters, call SystemCoreClockUpdate().
Global variable 'SystemCoreClock' expected 32MHz, but I got 16MHz.

Additional context
I changed default HSI_VALUE as follows.

--- a/CMSIS/STM32L1xx/Source/Templates/system_stm32l1xx.c
+++ b/CMSIS/STM32L1xx/Source/Templates/system_stm32l1xx.c
@@ -67,7 +67,7 @@
 #endif /* HSE_VALUE */
 
 #if !defined  (HSI_VALUE)
-  #define HSI_VALUE    ((uint32_t)8000000U) /*!< Default value of the Internal oscillator in Hz.
+  #define HSI_VALUE    ((uint32_t)16000000U) /*!< Default value of the Internal oscillator in Hz.
                                                 This value can be provided and adapted by the user application. */
 #endif /* HSI_VALUE */

I programmed a stepper motor controller with step interval 1ms using HAL_Delay(1). After updating my CubeMX library few days back, I realized every motion is taking almost twice as long. Upon inspecting, I found this in STM32CubeL1/Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_hal.c

__weak void HAL_Delay(uint32_t Delay)
{
  uint32_t tickstart = HAL_GetTick();
  uint32_t wait = Delay;

  /* Add a period to guaranty minimum wait */
  if (wait < HAL_MAX_DELAY)
  {
    wait += (uint32_t)(uwTickFreq);
  }

  while((HAL_GetTick() - tickstart) < wait)
  {
  }
}

Any uint32_t value will be < HAL_MAX_DELAY (=2^32-1) so the if condition will always be true. So essentially, we are unconditionally adding uwTickFreq (=1 for default clock settings) to any Delay value. This baffles me!
My idea of "guaranty minimum wait" would be to check explicitly for Delay==0 and add 1 if true, something like:

   /* Add a period to guaranty minimum wait */
  if (Delay == 0)
      Delay =1;
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }

The present implementation unfortunately, is unfaithful to what the API is intuitively meant to do. Please clarify if I've missed something. Thanks.

Caution
The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

• Heltec Node151: https://heltec.org/project/lora-node-151/

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Describe the bug

When using the USB CDC code w/ FreeBSD, FreeBSD issues a ClearFeature(HALT) in order to initialize the data toggle bit. When this happens, the USB HAL library stops responding and no more usb communications happens.

On other platforms which do not do this step, like MacOSX, things work fine. If I add a delay before the first IN command (write data to the host), it works fine on FreeBSD. I'd expect that when a halt happens like this, that any pending transactions be restarted, and the data be successfully sent. In my case, data never gets sent from the micro to the host.

How To Reproduce

1. Aquire and compile the code: https://www.funkthat.com/gitea/jmg/lora-irrigation

2. There are a number of strings that are printed out when first attached. This data does not appear on FreeBSD.

3. This appears to be missing code handling the ClearFeature(HALT) which is required per the USB specification.

4. Just connect it to a FreeBSD host.

5. Run a generic CDC endpoint, on a device, and connect it to a FreeBSD host.

Additional context

Screenshots

This screenshot shows the results of running a USB analyzer. Without a delay, and connecting to a FreeBSD host, you can see that there are a couple clear endpoint features to HALT (to initialize the data toggle to a known state) the IN and OUT direction of the EP. The micro does not recover and stops sending all data. It also fails to receive data, but this could be because it hasn't processed the incoming data yet.

Describe the set-up

• Custom board with STM32L152RCT6A
• FW_L1 V1.10.3

Describe the bug

FLASH_SIZE incorrectly reports flash size for cat.3 devices with DEV_ID 0x436.

STM32L1 Reference Manual RM0038:

31.1.1 Flash size register
F_SIZE: Flash memory size
For DEV_ID = 0x416 or 0x427 or 0x429 or 0x437, this field value indicates the Flash memory size of the device in Kbytes.
Example: 0x0080 = 128 Kbytes.
For DEV_ID = 0x436, the field value can be ‘0’ or ‘1’, with ‘0’ for 384 Kbytes and ‘1’ for 256 Kbytes.

Additional context

My solution:

// stm32l1xx_hal_flash.h:
#if defined (FLASH_CUT1) || defined (FLASH_CUT2)
#define FLASH_SIZE_RAW    (uint32_t)(*((uint32_t *)FLASHSIZE_BASE)&0xFFU)
#else /*FLASH_CUT3 || FLASH_CUT4 || FLASH_CUT5 || FLASH_CUT6*/
#define FLASH_SIZE_RAW    (uint32_t)(*((uint32_t *)FLASHSIZE_BASE)&0xFFFFU)
#endif
#define FLASH_SIZE        (((FLASH_SIZE_RAW) == 0 ? 384 : ((FLASH_SIZE_RAW) == 1 ? 256 : (FLASH_SIZE_RAW))) * 1024)

Describe the set-up

• arm-none-eabi-gcc
• Using core_cm3.h header from CMSIS_5 repository

Describe the bug

The device headers add some missing Cortex-M peripheral defines for SCB_CFSR_*, which were missing in the CMSIS 4 headers.

In CMSIS 5, however, these defines have been added, thus resulting in a warning:

warning: "SCB_CFSR_*_Pos" redefined
warning: "SCB_CFSR_*_Msk" redefined

We use the same CMSIS 5 files for all STM32 families, so we can guarantee feature consistency and receive updates (CMSIS 4 is EoL). So this isn't a bug for you (yet), just for me. See below

How To Reproduce

Upgrade the CMSIS 4 files to CMSIS 5 and compile. There should be a warning about redefining these macros in any example.

Additional context

There is a backwards compatible fix, by checking the major CMSIS version (__CM3_CMSIS_VERSION_MAIN). This fixes my issue and should work for you too.
See full patch. See below.