STM32 MCUs Products

I am experiencing an issue when trying to use STOP3 mode on an STM32U575VIT6Q device mounted on a custom PCB. In fact, the MCU never seems to actually enter STOP3, even though I explicitly call:HAL_SuspendTick(); HAL_PWREx_EnterSTOP3Mode(PWR_STOPENTRY_WFI); HAL_ResumeTick();The observed behavior is as follows:With Low-Power debugging enabled, STM32CubeIDE halts execution on the internal low-level _WFI()  instruction.Without the debugger attached (free-running mode after BOR and JTAG detached), the MCU does not appear to enter STOP3 at all and continues normal execution after the call.From code inspection and debugging, it looks like the core is effectively ignoring the WFI instruction or is prevented from transitioning into STOP3 by some system or external condition.At the moment, it is unclear what might be blocking STOP3 entry. Possible areas I am investigating include:Pending or enabled interrupts/events that could immediately wake the core after WFIDebug-related side effects,

I have implemented a sensorless, six-step trapezoidal control with feed-back as zero crossing detection using back emf with the help of ADC on the nucleo-G431 board.The BLDC motor is A2212/13T, 1000 kV.Without a propellor, the motor is spinning, and speed is also changing.But with the propellor, the motor is stuck at starting, and it is not rotating.Give some suggestions on what could be the reason and what modifications need to be done on the firmware and software sides.

In the lower-end STM32L4, covered by RM0394, SRAM is partitioned into two parts, SRAM1 and SRAM2.SRAM2 (besides being "special" in that it has ECC and automatic erase facities), is mapped at both 0x1000'0000 and at the end of SRAM1 in the 0x200x'xxxx area.In Figure 1 System architecture, SRAM2 does not have the connection needed for that second mapping, i.e. to the S-bus of the processor.JW

I am using STM32G071RBT6. I am trying to implement encoder mode + output compare mode using same timer. Right now initially I get OC interrupt even when Tim_CCR3IF flag is 0 and once it get set it remains as it is. - Should I combine encoder and OC mode or- should I use another timer

Hi, I’m trying to better understand how the USB PMA and BTABLE work on the STM32F103. After reading the reference manual, I’m still unsure how the descriptor table size relates to the number of endpoints.I have two possible interpretations of how the USB Descriptor Table and PMA layout work on the STM32F103, and I need clarification from ST to confirm which one is correct.I will provide two diagrams (Figure A and Figure B) to illustrate the scenario, assuming BTABLE offset = 0.Scenario: BTABLE = 0x0000Figure A (Fixed 8×8 bytes BTABLE)In this interpretation:The USB descriptor table is always 8 × 8 bytes = 64 bytes (0x0000–0x003F), assuming the device supports 8 endpoints.The usable PMA buffer area always starts at 0x0040, regardless of how many endpoints are actually used (for example, even if only 3 endpoints are used).Therefore the usable PMA region would always be 0x0040–0x0200.Question A:Is this interpretation correct? Is the descriptor table size always fixed at 64 bytes in the STM

I am using STM32 Nucleo-l476rg. I am trying to use the CAN peripheral and have tried every resource I came across. I am unable to send or receive messages:I have no filter, everything is wired correctly, what could be the issue? I even made it so that it just toggles an LED when the interrupt occurs. In case the interrupt is not set up properly, I have it polling HAL_CAN_GetRxFifoFillLevel, and if it is >0, it toggles the LED, but the LED never toggles. Am I missing something that is not autogenerated after configuring the peripherals in the .ioc file? In all the videos I have watched, it seems quite straightforward. What am I missing?

Owing to a developer (me) firmware blunder, I successfully "bricked" several STM32C011J6 (SO8 package) devices so that I cannot access them using STM32CubeProgrammer and STLINK.My error was this - my firmware reconfigured pins 7 (SWDIO) and 8 (SWCLK) as GPIO immediately after reset and also initialized pin 1 (nRST) as GPIO at the same time (rather than looking for another pin (button press during power up) that would have held off these steps).After my errant firmware was installed via STM32CubeProgrammer and STLINK, the STLINK device was/is no longer able to connect to the device.I am using STM32CubeProgrammer version 2.21.0 and a USB-attached STLINK device.I have transplanted one of the affected (few) devices to a PCB containing only a connector for the STLINK device, power, ground, and Pin 1 (NRST), so there is no other hardware potentially interfering with STLINK connection.As pin 1 (nRst) was repurposed at start-up time, I don't believe hardware reset (set by STM32CubeProgrammer)

I am encountering an issue with ADC readings on a custom board based on the STM32H533CET6.Hardware Setup: I have a simple analog filter connected to the ADC input. I have verified the input signal with a multimeter, and it correctly varies from 0V to 3V.The Problem: Despite the varying input voltage, the value in the ADC_DR register appears to be stuck at 1024. It does not change regardless of the voltage level applied to the pin.Configuration details:Resolution: 12-bitVREF+: 3.3VHas anyone experienced a similar issue with the H5 series or sees what I might be missing?

Hello, I have a problem that I am having a hard time figuring out.My project is using an STM32H743 as a USB host on a custom PCB. Both OTG_HS and OTG_FS ports are connected to different devices. OTG_HS is using the internal PHY and operating at full-speed. An LTE modem located on the same PCB is connected to the OTG_HS port, and a CP2105 located on a separate PCB is connected to the OTG_FS port via a 10ft cable (D+ and D- wires are twisted and shielded). The CP2105 and host exchange ~1KB of data via bulk transfer every 1 second, while communication with the LTE modem is currently only during manual testing aside from enumeration. I used the USB host drivers generated by STM IDE and modified them to work with each device.The problem I'm running into occurs with the OTG_FS port. Occasionally, the communication will come to a complete halt. The URB state returns as URB_IDLE after the host tries to transmit data. Looking at the data signals, there is no data being transmitted from the host

Hi,I'm facing some issues with some STM32G474RET6s, and want to rule out counterfeit chips, even if that seems unlikely.After googling for some solutions, I confirmed the AP IDR register and the DBGMCU_IDCODE both hold a revision ID of 3, which I expected from the X code on the label. However, I noticed that the markings on the chip match the LQFP80 footprint, rather than the LQFP64 we purchased.I have read the qualifications about how device markings can differ, but it doesn't hurt to ask: is this outdated documentation, or is there a possible issue?Thanks.

Dear all, i have a problem with my custom board based on STM32H745.I need to use core M4 with USB_HS host with mass storage class (a pen drive) at 12Mbit full speed (internal Phy transceiver).I have configured the processor as per attached file (core M4, FatFS, USB host, 48MHz RC clock for USB).The problem is that the FATFS Applistate variable is always in "application start" and never became "application ready". So that USB pen drive can not be mounted.Previously, I succeded in use the FATFS pack with the same functions configured with core M7, but I want to use core M4 because I need it in my project architecture.Consider that with the same FATFS pack I'm able to use SD card on the M4 core.I can't figure why I'm not able to migrate the USB HS host from M7 to M4.See also attached the function where the USB Host should be recognized and configured to receive data (in my project microSD card store datas and I want to download it to pen drive)

Hi everyone,I am using a STM32H563RG and I need the RTC to work even if the VDD is powered off. To do that, I am plugging a battery on the VBAT pin to power the RTC and the Backup domain. But I tested it and it seems the RTC is stopped and the backup domain is cleared when VDD is powered off.Here is my initialisation code :/* Configure the system clock */ SystemClock_Config(); /* USER CODE BEGIN SysInit */ /* USER CODE END SysInit */ /* Initialize all configured peripherals */ MX_GPIO_Init(); MX_GPDMA1_Init(); MX_ICACHE_Init(); MX_CRC_Init(); MX_SPI1_Init(); MX_TIM3_Init(); //MX_RTC_Init(); MX_ADC1_Init(); MX_ADC2_Init(); MX_TIM2_Init(); MX_FileX_Init(); MX_IWDG_Init(); MX_TouchGFX_Init(); /* USER CODE BEGIN 2 */ LL_PWR_EnableBkUpRegulator(); LL_PWR_EnableBkUpAccess(); if(LL_RTC_BKP_GetRegister(RTC,LL_RTC_BKP_DR0) == 0x32F2){ //Read Backup register to see if it was previously written RTC_Datas.RTC_initialized = 1; //Set flag GPIO_Set(Led_orang); //Turn Orange LED On }

I am using STM32WB55 and entering STOP2 mode for low-power operation.RTC Wakeup timer is configured, and the interrupt works correctly in RUN mode,but the MCU does not wake up from STOP2 mode when the RTC wakeup interrupt is expected.Configuration:- RTC enabled using LSE- Wakeup timer configured with WUT- MX generated code + custom low power entry- NVIC enabled for RTC WakeupTried:- Ensured RTC interrupt flag is cleared before entering STOP2- Enabled DBG and checked if STOP2 entry works- Checked PWR->WUPEN / PWR_SCR flagsStill, the MCU does not wake when RTC WUT expires.Any suggestions or known STM32WB55 issues related to STOP2 + RTC Wakeup?__PRESENT__PRESENT

I have a situation where a USB endpoint stops working due to a control packet being NAKed in the handshake phase. I've traced the problem down to the STM USB stack setting DCTL.SGONAK = 1 in response to an INCOMPISOOUT event, yet in the case when it fails, no global OUT NAK status notification appears in the RxFIFO and the GINTSTS.GONAKEFF interrupt status never occurs. However, the DCTL.GONSTS bit does change from 0 to 1 after SGONAK is set.Yet, according to the reference manual for the STM32H757 (RM0399 Rev 4, page 2908):Setting the global OUT NAK Internal data flow:When the application sets the Global OUT NAK (SGONAK bit in OTG_DCTL), the corestops writing data, except SETUP packets, to the receive FIFO. Irrespective of thespace availability in the receive FIFO, non-isochronous OUT tokens receive a NAKhandshake response, and the core ignores isochronous OUT data packets.The core writes the Global OUT NAK pattern to the receive FIFO. The application mustreserve enough receive FIFO sp

Hello,  I try to get data from a X-NUCLEO-53L8-A1 board connected to a Nucleo board and visualize it in my computer. If I use the VL53L8CX Gui and connect my COM port and click on the start button, it is working well. However, I would like to get data outside of the app (ex: Tera Term or python script) but I do not have data available. I suppose that the sensor/board is waiting for "start" but I can not find any documentation on the subject.  Can someone help me on the subject ?   Best regards

CNC material affects EMI, thermal dissipation, and grounding.I found this CNC material selection guide helpful:https://www.justway.com/blog/CNC_Machining/How_to_Choose_the_Perfect_Material_for_CNC_Machining_A_Comprehensive_Guide_fb9e953e.htmlHow do you select materials for STM32 enclosures?Do you consider heat spreading for high-load MCUs?Which materials reduce noise in mixed-signal designs?Any lessons from industrial STM32 products?”

Content:Hi,I am using UART on STM32G4 in interrupt mode (RXNEIE + NVIC enabled). I observed the following situation:  1. A byte is received → RXNE = 1 2. At that moment, UART interrupt is disabled (critical section) 3. Later I re-enable the UART interrupt 4. But the RXNE interrupt does NOT fire, even though RXNE is still = 1 This causes my Modbus task to freeze because no further RXNE interrupts are generated. ------------------------------------------------------------------------------------------------------------------- My question:Is this the expected behavior?i.e.,Does STM32G4 USART generate the RXNE interrupt only when RXNE transitions from 0 to 1,and not when RXNE is already 1 at the moment the interrupt is enabled? I could not find a clear statement about this behavior in the Reference Manual. If this is the intended design, please confirm, and if possible, point to the exact section in the documentation. Thank you.

I am attempting to reconfigure Pin 8 (datasheet default assignments are PB6/PA14-BOOT0/PC15-OSCX_OUT) from PA14-BOOT0 to PB6 GPIO Output Open Drain (GPIO_MODE_OUTPUT_OD) a short time after start-up.My current attempt (code below) does not accomplish this (instead, once the port pin reconfiguration code below has run, an attached STLINK device can still connect to the MCU, or if already connected to MCU, continues to function.)IMPORTANT: I have not yet and do not plan to change MCU option bytes (using STM32Programmer).Intention: In the application (under development, written in C using STM32CubeIDE, using HAL), at power-up, a connected STLINK device should function normally. A short time later (under condition set in firmware), the application firmware is expected to reconfigure Pin 8 from power-on default (as Port A, GPIO bit 14, Alternate Function 0, which is STLINK SWCLK) to a different configuration (as Port B, GPIO bit 6, Open Drain output).This change should (ideally) be able to o

Hi everyone,I’m working with an STM32L5 USART and trying to clarify a point about parity vs. MSB-first transmission.From the reference manual (USART parity control / frame formats), when parity is enabled the frame formats are shown as:M=00, PCE=1: SB | 7-bit data | PB | STBM=01, PCE=1: SB | 8-bit data PB | STBand there is a note that “in the data register, the PB is always taking the MSB position (8th or 7th depending on M)”.This wording caused confusion in our class:one interpretation is that because parity occupies the MSB position in the data register/word length, it might be transmitted before the data bits when MSBFIRST=1.My understanding is:MSBFIRST only reverses the order of the data bits inside the data field.The parity bit remains the parity field in the frame, i.e. logically after the data field and before stop bits.The “MSB position” note refers to the bit slot within the word length/data register, not to the time order on the line.Could someone confirm:Question:When MSBFIR

Hello,I am using STM32H750VBT6 to perform microSD card write operations. After a number of writes, the CPU sometimes resets during a write operation. At the same time, the Vcore (1.13V) rail shows a voltage drop. The issue is random, but the higher the write frequency, the faster it occurs. Below are details of my hardware, software, and test results. 1. Hardware designThe power supply module:The power supply is designed with 12V input, generating 3.8V, 3.3V, 1.8V, and 1.13V.3.3V powers the STM32 VDD pins, and 1.13V powers the VCAP pins.Each VCAP pin is decoupled with a 0.1 µF capacitor in parallel with a 4.7 µF capacitor (located close, but not on the same plane due to vias).The SD card interface: 2. Software designInitialization code generated by STM32CubeMX + HAL library: void MX_SDMMC1_SD_Init(void) { hsd1.Instance = SDMMC1; hsd1.Init.ClockEdge = SDMMC_CLOCK_EDGE_RISING; hsd1.Init.ClockPowerSave = SDMMC_CLOCK_POWER_SAVE_DISABLE; hsd1.Init.BusWide = SDMMC_BUS_WIDE

Dear STM32 users and developers, This new thread is back and is dedicated for our technical developers community to share last STM32 updates, the first part will be products documentation news such as datasheets, Erratas, Applications notes  followed by specific subject's presentation(s) during the last period in a monthly basis . The format and the content will evolve in next editions...    You can leave us your comments on this initiative on this thread    Many thanks to @Tesla DeLorean  @TDK  @waclawek.jan   !  Any proposal is welcome for subjects you want to be addressed , Stay tuned . Cheers, STOne-32 

Hello everyone,I’m working on a control unit board based on the STM32F407VETx (LQFP100) microcontroller. During development I noticed that some pins configured as external interrupts (rising edge) were being triggered more often than expected.To better analyze the issue and exclude possible mistakes in my code, I prepared a minimal test project with the following configured pins in IOC:Pin 9 – PC15: GPIO_EXTI15 - INPUT_1Pin 97 – PE0: GPIO_EXTI0 - INPUT_2External crystal/ceramic resonator (HSE)Serial Wire Debug with SysTick as timebase sourceThe only user code added is in gpio.c:/* USER CODE BEGIN 0 */ volatile uint8_t counter_1 = 0; volatile uint8_t counter_2 = 0; /* USER CODE END 0 */ . . . /* USER CODE BEGIN 2 */ void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if(GPIO_Pin == INPUT_1_Pin) { counter_1 = (counter_1 + 1) % 255; } if (GPIO_Pin == INPUT_2_Pin) { counter_2 = (counter_2 + 1) % 255; } } /* USER CODE END 2 */ On my board both PIN9 and PIN97 have the following

A new question moved from this thread. In many examples they use the Vref int for the calculation of the temperature. Do I need it for the C0 also or can it be done without?

Hi STM32 community.I'm working on an embedded system which uses a RK3399 CPU (running Linux, functions as a USB host) and a STM32F302CC (Runing FreeRTOS, functions as a USB device). This runs on a custom motherboard. They communicate with each other through virtual COM ports over USB (using this library https://github.com/IntergatedCircuits/USBDevice).This embedded system has been around and in use for several years and thousands of units are operational. 99,99% of the time (or something like that) everything just works just perfectly. But every now and then, during some special  circumstances which have not yet been fully understood (MCU brownout maybe?), some devices will end up in a  weird state where the MCU seems to be running, but the USB device (i.e. the STM32F302CC) does not enumerate in Linux on the CPU side. This can be seen in kernel log as something like this (or similar):[81228.001719] usb 7-1.4: new full-speed USB device number 40 using xhci-hcd[81228.06569

Hello everyone,I am currently working on a project using the STM32H755 microcontroller, and I am facing an issue with the program getting stuck in the `Reset_Handler` during debugging. Specifically, the code halts at the instruction `ldr sp, =_estack`, which sets the stack pointer, and does not proceed further.### Project Setup:- **Microcontroller**: STM32H755- **Core**: Only using the Cortex-M7 (CM7) core, with Cortex-M4 (CM4) code generation disabled.- **Debugger**: ST-LINK V3- **IDE**: STM32CubeIDE- **Firmware**: No custom firmware for CM4, only CM7 is active.### Steps Taken:1. I created the project with STM32CubeMX, configured it to use only the CM7 core (CM4 is disabled).2. During debugging, the code reaches `Reset_Handler` but gets stuck at `ldr sp, =_estack`.3. I have tried stepping through the code and confirmed the program halts at the stack pointer initialization.### Possible Causes Considered:- **Dual-Core Synchronization**: Since this is a dual-core MCU, I suspect there mig