profile
viewpoint
STMicroelectronics STMicroelectronics https://www.st.com STMicroelectronics is a world leader in providing the semiconductor solutions that make a positive contribution to people’s lives, today and into the future.

STMicroelectronics/BlueSTSDK_Android 60

Bluetooth low energy Sensors Technology Software Development Kit (Android version)

STMicroelectronics/BlueSTSDK_Python 35

Bluetooth Low Energy Sensors Technology Software Development Kit (Python version for Linux Gateways)

STMicroelectronics/BlueSTSDK_iOS 25

Bluetooth low energy Sensors Technology Software Development Kit (iOSversion)

STMicroelectronics/arm-trusted-firmware 14

Arm Trusted Firmware

STMicroelectronics/BlueSTSDK_GUI_Android 12

BlueST SDK extension library (Android version).

STMicroelectronics/cmsis_device_f1 9

Provides the STM32Cube MCU Component "cmsis_device_f1" of the STM32F1 series.

STMicroelectronics/cmsis_device_f4 9

Provides the STM32Cube MCU Component "cmsis_device_f4" of the STM32F4 series.

STMicroelectronics/BlueSTSDK_GUI_iOS 6

BlueST SDK extension library (iOS version).

STMicroelectronics/cmsis_core 6

CMSIS Core module, fully aligned with ARM versions.

STMicroelectronics/cmsis_device_f7 4

Provides the STM32Cube MCU Component "cmsis_device_f7" of the STM32F7 series.

fork KDEDirect/STM32CubeH7

STM32Cube MCU Full Package for the STM32H7 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))

fork in an hour

created tagSTMicroelectronics/STM32CubeF0

tagv1.11.2

STM32Cube MCU Full Package for the STM32F0 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))

created time in 5 hours

push eventSTMicroelectronics/STM32CubeF0

rihab kouki

commit sha 4390ff6bfb693104cf97192f98c3dc9e3a7c296a

Release v1.11.2

view details

push time in 5 hours

issue commentSTMicroelectronics/STM32CubeF7

Wrong prescaler value in HAL_InitTick() when Timer clocks less than 1MHz

Hi @stsymbaliuk,

Thank you for your contribution. In order to allow a better analysis of this problem, could you please give us your .ioc file that you are used to reproduce this issue. Thank you again for your contribution.

With regards,

stsymbaliuk

comment created time in 5 hours

created tagSTMicroelectronics/cmsis_device_f0

tagv2.3.5

Provides the STM32Cube MCU Component "cmsis_device_f0" of the STM32F0 series.

created time in 6 hours

push eventSTMicroelectronics/cmsis_device_f0

rihab kouki

commit sha 20e23a96fe294368389655878c44813c989b7a9c

Release v2.3.5

view details

push time in 6 hours

created tagSTMicroelectronics/stm32f0xx_hal_driver

tagv1.7.5

Provides the STM32Cube MCU Component "hal_driver" of the STM32F0 series.

created time in 6 hours

push eventSTMicroelectronics/stm32f0xx_hal_driver

rihab kouki

commit sha 5eeaad10dc3816830abd9b3bfd74c6974453e907

Release v1.7.5

view details

push time in 6 hours

created tagSTMicroelectronics/cmsis_device_l0

tagv1.9.1

Provides the STM32Cube MCU Component "cmsis_device_l0" of the STM32L0 series.

created time in 7 hours

push eventSTMicroelectronics/cmsis_device_l0

rihab kouki

commit sha 08561fa10d714b4e7b1586d8a2bcd6839f4fa6b1

Release v1.9.1

view details

push time in 7 hours

created tagSTMicroelectronics/STM32CubeL0

tagv1.12.0

STM32Cube MCU Full Package for the STM32L0 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))

created time in 7 hours

push eventSTMicroelectronics/STM32CubeL0

rihab kouki

commit sha a7b74aed35ecb7baeadeb16107aa8fddb6823589

Release v1.12.0

view details

push time in 7 hours

created tagSTMicroelectronics/stm32l0xx_hal_driver

tagv1.10.4

Provides the STM32Cube MCU Component "hal_driver" of the STM32L0 series.

created time in 7 hours

issue openedSTMicroelectronics/STM32CubeG0

Undefined RCC_CFGR_SWS_* symbols in migrated project

Describe the set-up

  • The board (either ST RPN reference or your custom board): Custom board using a STM32G070KB
  • IDE or at least the compiler and its version: STM32Cube IDE v1.3.1

Describe the bug After migrating a project from STM32CubeG0 1.3.1 (STM32Cube IDE was upgraded from 1.2.0) to 1.4.0, I attempted to build the project and received the same error as described here: https://community.st.com/s/question/0D53W00000OUZHcSAP/stm32cubefwg0v140-bug-

How To Reproduce

  1. Create a project using STM32CubeG0 1.3.1
  2. Migrate the project to STM32CubeG0 1.4.0
  3. Run a "Clean"
  4. Build (I built with the Debug profile)

created time in 7 hours

issue commentSTMicroelectronics/STM32CubeG0

Bug exists in FreeRTOS CMSIS RTOS V2 API

Thanks for the update!

bridadan

comment created time in 7 hours

push eventSTMicroelectronics/stm32l0xx_hal_driver

rihab kouki

commit sha 433eef248f43fa27e92ea6abd422c5f5e0f127b4

Release v1.10.4

view details

push time in 7 hours

issue closedSTMicroelectronics/STM32CubeF3

Comment bug stm32f3xx_ll_opamp.h NONINVERT macros

In the low-level opamp driver, PB11 and PA4 for OPAMP4 are swapped in the comments after the last two non-inverting macro definitions.

stm32f3xx_ll_opamp.h:

-#define LL_OPAMP_INPUT_NONINVERT_IO2      (OPAMP_CSR_VPSEL_1)     /*!< OPAMP non inverting input connected to GPIO pin (pin PA3 for OPAMP1, pin PB0  for OPAMP2, pin PA1  for OPAMP3, pin PB11 for OPAMP4) */
-#define LL_OPAMP_INPUT_NONINVERT_IO3      (OPAMP_CSR_VPSEL_0)     /*!< OPAMP non inverting input connected to GPIO pin (pin PA5 for OPAMP1, pin PB14 for OPAMP2, pin PA5  for OPAMP3, pin PA4  for OPAMP4) */
+#define LL_OPAMP_INPUT_NONINVERT_IO2      (OPAMP_CSR_VPSEL_1)     /*!< OPAMP non inverting input connected to GPIO pin (pin PA3 for OPAMP1, pin PB0  for OPAMP2, pin PA1  for OPAMP3, pin PA4 for OPAMP4) */
+#define LL_OPAMP_INPUT_NONINVERT_IO3      (OPAMP_CSR_VPSEL_0)     /*!< OPAMP non inverting input connected to GPIO pin (pin PA5 for OPAMP1, pin PB14 for OPAMP2, pin PA5  for OPAMP3, pin PB11  for OPAMP4) */

closed time in 8 hours

aquaid3

created tagSTMicroelectronics/STM32CubeF3

tagv1.11.2

STM32Cube MCU Full Package for the STM32F3 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))

created time in 9 hours

push eventSTMicroelectronics/STM32CubeF3

Ali Labbene

commit sha 86346f63f25b859f93f9603837dcd5be28e8e7bf

Release v1.11.2

view details

push time in 9 hours

created tagSTMicroelectronics/stm32f3xx_hal_driver

tagv1.5.5

Provides the STM32Cube MCU Component "hal_driver" of the STM32F3 series.

created time in 9 hours

push eventSTMicroelectronics/stm32f3xx_hal_driver

Ali Labbene

commit sha a0007fb36cb5eaf2f875aaa133fd06de818c38ae

Release v1.5.5

view details

push time in 9 hours

startedSTMicroelectronics/STM32CubeL0

started time in 10 hours

issue commentSTMicroelectronics/STM32CubeH7

No validity chekcing on the variable dev_desc->bMaxPacketSize

Hi @TheSilentDawn,

Thank you for your contribution. All the reports you sent will be forwarded to our development teams. I will get back to you as soon as they provide me with their feedback.

Thank you again for your contribution and thank you in advance for your patience.

With regards,

TheSilentDawn

comment created time in 11 hours

issue commentSTMicroelectronics/STM32CubeH7

Lack hardware wake-up support checking

Hi @TheSilentDawn,

Please allow me this couple of questions:

  • Is there any way for the host to check whether the device supports the wake-up feature other than the bmAttributes read from the device descriptor?
  • You mentioned "the wake-up feature checking codes". Are you referring to some piece of code already present in our source files that should be moved before the reading of the bmAttributes?

Thank you,

TheSilentDawn

comment created time in 11 hours

issue commentSTMicroelectronics/STM32CubeH7

No checking on both IN and OUT pipe constructed

Hi @TheSilentDawn,

Thank you for the clarification. Hence, the case you are describing is an interface exposing 2x IN endpoints or 2x OUT enpoints instead of 1x IN endpoint and 1x OUT endpoint (which is the normal case for a MSC).

I will forward your report to our development teams. I will get back to you as soon as they provide me with their feedback.

With regards,

TheSilentDawn

comment created time in 11 hours

issue closedSTMicroelectronics/STM32CubeG0

STM32G0 HAL_GPIO_EXTI_Callback() incompatibility

Describe the set-up

  • Nucleo F746
  • CubeIDE 1.3.0
  • HAL FW G0 v1.3.0

Describe the bug The following call back should be called when EXTI is accepted, according to the HAL reference UM2319 - Rev 1, section 3.11 :

 void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
}

This is common manner among the STM32 series.

But only STM32G0 uses HAL_GPIO_EXTI_Rising_Callback() and HAL_GPIO_EXTI_Falling_Callback().

This is a bad idea to make a Hardware "Abstraction" Layer. The API should be aligned among the different hardware, as far as possible. ANd this is a possible case.

How To Reproduce

  1. The demo program turn on the LED on the HAL_GPIO_EXTI_Callback.
  2. Clone the stm32-defects repository.
  3. Import d003-nucleo-g070-gpio-exti into CubeIDE
  4. Build and run the project on the Nucleo-G070.
  5. Import d003-nucleo-g431rb-control into CubeIDE
  6. BUild and run the project on the Nucleo-G431RB.

Please push the blue button (B1) of the Nucleo. On the Nucleo G070, the green LED is off, while the Nucleo G431RB the green LED in turned on. Both projects try to catch the EXTI by HAL_GPIO_EXTI_Callback() and turn on LED. The G431RB is expected behavior.

Additional context This is duplicated with the bug-report on the community.

Screenshots

closed time in 12 hours

suikan4github

issue commentSTMicroelectronics/STM32CubeG0

STM32G0 HAL_GPIO_EXTI_Callback() incompatibility

Hi @suikan4github,

I hope you are fine. The issue you reported has been fixed in the frame of version v1.4.0 of the STM32CubeG0 published a few minutes ago on GitHub.

Thank you again for having reported.

With regards,

suikan4github

comment created time in 12 hours

issue closedSTMicroelectronics/STM32CubeF1

Multiple warning about unused parameters.

Is it possible to put "attribute ((unused))" before those params because it's annoying and fills the screen with useless info and I really want to be able to use the -Wall parameter.

In file included from C:\Users\tbyte\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.7.0\cores\arduino\stm32\HAL\stm32yyxx_hal_tim_ex.c:5: C:\Users\tbyte\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.7.0\system/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_tim_ex.c: In function 'HAL_TIMEx_RemapConfig': C:\Users\tbyte\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.7.0\system/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_tim_ex.c:1734:60: warning: unused parameter 'htim' [-Wunused-parameter] HAL_StatusTypeDef HAL_TIMEx_RemapConfig(TIM_HandleTypeDef *htim, uint32_t Remap) ~~~~~~~~~~~~~~~~~^~ C:\Users\tbyte\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.7.0\system/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_tim_ex.c:1734:75: warning: unused parameter 'Remap' [-Wunused-parameter] HAL_StatusTypeDef HAL_TIMEx_RemapConfig(TIM_HandleTypeDef *htim, uint32_t Remap) ~~~~~^ In file included from C:\Users\tbyte\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.7.0\cores\arduino\stm32\usb\usb_device_ctlreq.c:3: C:\Users\tbyte\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.7.0\system/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_ctlreq.c: In function 'USBD_CtlError': C:\Users\tbyte\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.7.0\system/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_ctlreq.c:853:42: warning: unused parameter 'req' [-Wunused-parameter] USBD_SetupReqTypedef *req) ~~~~~~~~~~~~~~~~~~~~^

closed time in 12 hours

TByte007

issue commentSTMicroelectronics/STM32CubeF1

Multiple warning about unused parameters.

Hi @TByte007,

I hope you are fine. You request has been addressed at the level of the TIM driver.

For the USB device library, the change has been implemented in the frame of version v2.6.0. Unfortunately, for the STM32CubeF1 there is no plan to upgrade from v2.5.3 to v2.6.0.

Please allow me to close this issue now and thank you for your comprehension.

With regards,

TByte007

comment created time in 12 hours

issue closedSTMicroelectronics/STM32CubeG0

VBUS race condition where USB TypeC 'attach' event is never seen by the application

Overview Possible issue in the Middleware USB-PD G0 Device section

Describe the set-up

  • Custom board where BSP_PWR_VBUSGetVoltage() senses TypeC voltage.
  • arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

Describe the bug Possible issue in USB PD Middleware Device for G0. At attach sensing time, the library should check for VBUS to stabilize to Vsafe5V before moving forward. However, I believe there's an incorrect conditional for this check.

How To Reproduce

  1. Have a system with relatively fast VBUS ramp (less than CAD_TPDDEBOUCE_THRESHOLD)
  2. Attached a USB PD compliant device
  3. No attach event occurs.

Additional context This patch gets me past this issue.

iff --git a/Middlewares/ST/STM32_USBPD_Library/Devices/STM32G0XX/src/usbpd_cad_hw_if.c b/Middlewares/ST/STM32_USBPD_Library/Devices/STM32G0XX/src/usbpd_cad_hw_if.c
index 0209bb8..3068df8 100644
--- a/Middlewares/ST/STM32_USBPD_Library/Devices/STM32G0XX/src/usbpd_cad_hw_if.c
+++ b/Middlewares/ST/STM32_USBPD_Library/Devices/STM32G0XX/src/usbpd_cad_hw_if.c
@@ -766,7 +766,7 @@ static uint32_t ManageStateAttachedWait_SRC(uint8_t PortNum, USBPD_CAD_EVENT *pE
   
   if ((_handle->CurrentHWcondition != HW_Detachment) && (_handle->CurrentHWcondition != HW_PwrCable_NoSink_Attachment))
   {
-    if ((BSP_PWR_VBUSGetVoltage(PortNum) > BSP_PWR_LOW_VBUS_THRESHOLD)
+    if ((BSP_PWR_VBUSGetVoltage(PortNum) < BSP_PWR_LOW_VBUS_THRESHOLD)^M
         && (USBPD_PORTPOWERROLE_SRC == Ports[PortNum].params->PE_PowerRole))
     {
       /* reset the timing because VBUS threshold not yet reach */

closed time in 12 hours

intercreate
more