STM32 MCUs Products

Hi!I'm building a device using a STM32U31xx, connected to a Network Chip via I²C (PB6/7) and 2 GPIOs for Reset and BOOT0 Pin. The intention is to have new firmware downloaded onto the network chip, and flash new firmware to the STM32U031 via the system bootloader.I power up the system to invoke a power up reset on the ST device, I immediately flash firmware and ask the chip after another reset cycle for the new firmware version to confirm the new firmware was flashed.The behavior I observe is the following:- if the STs Option Byte nBOOTSEL is 0, the process works just fine, very reliably.- if nBOOTSEL is 1, the process fails even if I mass erased the STs flash memory entirelyThis is contrary to my understanding of AN2606 Table 2, pattern 11, that states that the empty check should start the system bootloader no matter the state of nBOOTSEL bit or BOOT0pin.I intended to have the ST chip flashed on production without previous intervention into th

Hello Team,We are using the internal SMPS configuration for the core power supply. However, the power-up sequence does not specify the timing requirements for the different stages.Could you please provide the timing details for the following? What should be the time duration for the PWR_ON signal to transition from low to high while VDD and VDDA18AON are rising (Step 1)?After PWR_ON goes high, what is the required time duration for VDDA18PMU / VDDSMPS to rise (Step 2)?What is the exact meaning and function of the SDEN signal?Are there any additional considerations or recommended guidelines to be followed during the power-up and power-down sequence? 

Hi, As per title I am unable to enter the System Memory bootloader when using the STM32C071FBP6N. Any assistance would be greatly appreciated. Following the notes in AN2606, i have configured pattern 11 (line 2) using the CubeProgrammer but when completing the reset with the Boot0 pin high it does not enter the bootloader mode and can tell this because my user application runs immediately after the reset occurs. I have been able to jump to the bootloader through my own firmware where I initialize the HAL and GPIOs and then check the status of the boot0 or other pins then manually change the PC and SP but wish to avoid this method as this should not be necessary. ------- I have followed the steps below: 1. Using a ST-Link I have successfully changed the option bits nBOOT_SEL=0; nBOOT1=1; nBOOT1=1; BOOT_LOCK=0 using the CubeProgrammer and have also flashed a basic UART output program which outputs to USART2 the whether the PA14

Is it possible to use the awesome MDF and/or ADF on STM32U5 with input data from RAM? I have not found any configuration for BSMX for this. One use case is an high performance external delta-sigma-demodulator (ADC) on SPI with proprietary data format (24 Bit per channel, MSB first, CRC etc.) for providing the sound data. Another use case is an LSM6DSV16XTR, also connected via SPI.

Hi, is anybody able to confirm if the STM32H563ZIT3Q has an ethernet peripheral? Thanks, regards. 

I've been struggling with a strange ADC problem for a while, and have now made some interesting observations.The scenarioI'm using an STM32G474, where HRTIM directly controls a peltier driver for temperature regulation. Temperatures are measured by ADC4 (12 bit resolution), running in DMA circular mode, triggered by TIM7, at 1 kHz. This works. Temperatures are coming in, and are being used for PID regulation.The problemQuite often – perhaps always – some of the temperature readings are being disturbed, but only at certain temperatures. At first, I thought that it was random noise, but in a graph the noise looks strange. Not random at all.After monitoring the raw ADC values that the DMA has thrown into memory, I discovered something that might be a clue – or it might just be a source of confusion. Every time a noisy sequence occurs, the ADC readout jumps to a lower nearby value where the five least significant bits

I'm writing firmware for a development board based on the STM32H743 MCU, and I want to use an external GPIO input as the trigger or synchronization signal of DMAMUX to initiate DMA transactions. However, it seems that very little information is available on using GPIOs to start DMAs. In the reference manual, "Table 127. DMAMUX2: assignment of trigger inputs to resources" and "Table 128. DMAMUX2: assignment of synchronization inputs to resources", it shows two trigger input signals: "Syscfg_exti0_mux" (number 20), and "Syscfg_exti2_mux" (number 21). So it seems to suggest that the EXTI trigger sources can indeed be used to trigger the DMA, but these two signals are not mentioned anywhere in the entire reference manual, there's no block diagram showing exactly what GPIO pins are connected. It says "SYSCFG" and "MUX", so they're probably the outputs controlled by programming SYSCFG_EXTICR1, SYSCFG_EXTICR2, SYSCFG_EXTICR3, SYSCFG_EXTICR4. But there are 4 EXTICRx and only two

The STM32G031G8U6 in a UFQFPN28 package does not have PF0 / PF1 pins for HSE OSC_IN / OSC_OUT.  It does however have OSC_IN on PC14.  This is intended for an external CMOS oscillator in bypass mode.I’m currently in the schematic design stage. My board clock is a clipped-sine TCXO used for other purposes.  In some modes, I’d like to use it to clock the STM32. I’m very constrained on cost, power, and board space.  The clipped-sine doesn't meet the voltage level requirements for a bypass-mode clock.Is it possible to configure HSE as if it were a crystal, but instead supply a clipped-sine 0.8 Vpp clock from the TCXO to PC14 OSC_IN? Does the die used in UFQFPN28 even have the HSE oscillator circuit that exists in the 48 pin package?I would set RCC_CR[HSEBYP] = 0 and R

Hi, I need to measure a 4.2V battery while my MCU's supply varies between 2.0V and 3.3V. Since VDDA is the ADC reference, raw ADC counts will drift as the supply changes. Is this the correct method? My plan: Feed the battery voltage through a 10K/7K5 divider into one ADC channel (scaled to stay below VDDA_min = 2.0V). Read VREFINT on a second ADC channel. Use VREFINT (whose true value is known from the factory calibration in system memory) to back-calculate the actual VDDA, then convert the battery channel's raw count into volts. The formula being:V_battery = 3.0 V × (VREFINT_CAL / VREFINT_DATA) × (ADC_battery / 4095) × ((R1 + R2) / R2)   Is this the correct approach for getting a supply-independent battery reading on this part? Anything I'm missing... sampling time for VREFINT, divider impedance vs. ADC sample-and-hold, or calibration register quirks specific to the C0 seri

Hi! I'm trying to design a project that will use an stm32u5, and I would like to add PSRAM to it. Most higher-capacity PSRAMs seem to want to run at 1.8V rather than 3.3V, from what I can tell.  The particular U5 I've tentatively selected (the U595), has a VDDIO2 power pin, which I understand that I can run at 1.8V while running the rest of the MCU at 3.3V. This feature seems specifically designed to address this use case (and Claude and Gemini insist that it's possible with the right u5 variant, though I'm well aware how confidently wrong AI tools can be). The datasheet says that VDDIO2 affects Pin Bank G. However, I can't quite seem to figure out how I might actually connect to a PSRAM chip exclusively with this bank.  I haven't been in these waters before, so it's possible I'm overlooking something straightforward - a lot of the configuration options for PSRAM are new to me. It seems I could use FMC or SPI to connect to the PSRAM chip, but playing a

Hello,I realized, that there are different informations about the features of LPUART1 in the datasheet and refmanual.The datasheets (at least DS15125 and DS15136) probably falsely specify in Table 8, that the LPUART1 features receiver timeout interrupt, modbus com and auto baudrate detection.In the refmanual (RM0522, Table 439) these features are specified as not supported. This seams to be the right information, when looking into CubeMX2, where the RTO for LPUART1 can not be activated. 

We are trying to do a firmware upgrade via UART to the N6 from another MCU, and having trouble getting it working. We do not have a USB host stack on that MCU so we're unable to use USB DFU.I've successfully been able to transfer and start the FSBL to the N6, but am unable to transfer the app image. Another detail is that our app image is ~540KB, so a bit too big to fit in the RAM buffer. Even a smaller sample image isn't able to work.Before I try a different bootloader or custom option, I just wanted to see if anyone else has had success doing this or if there is something I'm missing. Thanks.

Hi everyone, We are encountering a XSPI Deadlock on our STM32H7S7-Discovery board (STM32H7S78-DK).To provide some context, our system is configured as follows: External FLASH: Connected to XSPI1. Swapped through XSPIM to port 2 and operates in memory mapped mode. MCE1 is activated across the entire address range using the AES-STREAM Cipher. External PSRAM: Connected to XSPI2. Swapped through XSPIM to port 1 and operates in memory mapped mode. MCE2 is activated across the entire address range using the NOEKEON-BLOCK Cipher. The issue occurs when running an LZO decompression algorithm. The algorithm reads compressed data from the PSRAM and writes the decompressed output back to the PSRAM, while the code is being executed on External FLASH. At some point during decompression, the core completely freezes, no HardFault or BusFault is triggered, and the debugger

Hi there, I have firmware that uses UART1 and UART2 of the STM32G4 series. Both are intended to run on interrupts, but as soon as any signal is received by the MCU, an error occurs, causing HAL_UART_AbortCpltCallback to be called. Therafter, the interrupt no longer works. Are there any known issues with the interrupt on these STMs? Based on previous forums, people were limited by stack size and prefetch. However, different to those cases, my code doesnt enter a hard fault, rather it just hits the function: HAL_UART_AbortCpltCallback.The error that comes up during debug starts here in the hal code:/* Enable the UART Error Interrupt: (Frame error, noise error, overrun error) */ATOMIC_SET_BIT(huart->Instance->CR3, USART_CR3_EIE); /* Configure Rx interrupt processing */

Section 36.6.1, Bit 18 (ITAMP3E) indicates that LSE frequency monitoring can be enabled. It appears that the hardware automatically detects when the LSE frequency goes above or below the defined thresholds and sets the ITAMP3F flag in the TAMP_SR register when an LSE failure occurs. When the LSE fails, ITAMP3 is triggered, which asserts the tamp_erase signal, and the backup registers are then automatically erased?

I am using the STM32U575CGU3 MCU in my project, where I transmit data using two CAN frames on the bus. I have configured a CAN transmission cycle time of 250 ms in my software. However, on a few PCB assemblies, I am observing inconsistencies in the transmission cycle time. On few boards, the cycle time appears to fluctuate (e.g., around 0.5–0.6 ms deviation), while on other boards, it works well. Could you please help me understand what might be causing this variation across different PCBAs? Any guidance on potential root causes or debugging approaches would be highly appreciated.

I am having an issue while trying to setup an I2C driver on my STM32F767ZI Nucleo board interfacing with an SHT31 and SGP40 I2C sensors. The code I am running first initializes the SHT31 with a write and read and then initializes the SGP40 with a write and read. The issue I am running into is whenever I send the next message (read on whichever sensor I decide to try to configure first), the I2C peripheral sends a start bit and address as expected but adds a null byte immediately after the address. See attached example where I would expect the address of 0xB2, and the two byte message of 0x36 and 0x82 to be sent instead I see the address of 0xB2, then data of 0x00 and 0x36.  It runs through the first write cycle without an issue.  Edited to elaborate on the logic analyzer captures. I2C_LA._Expected captures the moment after stepping through setting the start bit in the CR2 register. It shows the address being transmitted and then SDA returns h

Hello ST,We are using STM32H563RGT6 and want to run at 125℃ environment.We see in the datasheet as below.it seems that for STM32H563RGT6 with suffix 6, if we are using LDO bypass mode (using external 1.2V power supply for MCU Vcore), MCU works at VOS1 mode, it also can run at 125℃ environment.Is it right?Thanks.  

Hi,I have a problem with a custom board, where i can not enter bootloader, on some boards...I had a production where around 10% has this issue. (I did not see it on earlier production of 5pcs).The problem is the cube programmer will not enter bootloader mode.I use a autodirection rs485 tranciever (5V on FT pins) and it is working on many of the boards with no problem, also the in-application code works fine for modbus (also on the bootloader broken devices, after programming with ST-Link)I am using a FTDI USB to RS485 converter.The boot pin is held up by a hall sensor and inverter transistor, i have noticed these sensors has different startup time 50-100ms - therefore the MCU reset pin is controlled by a rather slow RC circuit, to ensure boot is high before reset is released. (this is a litle risky).However, i can see on the current consumption when it goes into application mode or assumed bootloader mode, as in bootloader mode the cu

Hello!I am using a 32.768 kHz TCXO (TG-3541CE) as the LSE to count the RTC.The MCU is an STM32L452RE.At room temperature, the RTC operates correctly, but at high temperatures (around 50 °C), the RTC stops.Strangely, once it has stopped, touching the MCU by finger causes the RTC to start running again.Suspecting an issue with the TCXO, I tried a different TCXO, but the same behavior occurred. When I added a 200 Ω damping resistor between the TCXO and the MCU, the RTC no longer stopped even when the temperature was raised to 60 °C.This seems to have solved the problem for now, but I am concerned about whether 200 Ω is an appropriate value and whether this is truly a fundamental solution.If you have any ideas about possible root causes or considerations, I would really appreciate your advice.

Hi,I am working with a custom board using an STM32N657X0H3Q and cannot for the life of me bring about a reset via the NRST pin.I have tried applying the workarounds from errata sheet ES0620 - Rev 3, sections 2.2.19 and 2.2.23, but my device still just hangs when any reset is attempted and needs a power cycle to recover.  In our setup:MCUboot and the application are both built as secure firmwarethe application runs from AXISRAM1 after RAM-loadSince it runs from AXISRAM1 which is where the errata recommends to place the First power-on reset flag, I instead decided to set the CORE_RESET_TYPE bit in the SYSCFG_CM55RSTCR register before each reset (in addition to resetting the clock switch control bitfields to their defaults). Does this type of setup have any implications regarding using the SYSRESETREQ bit to generate a software reset?  

Dear ST Support Team,Thank you for your suggestion to refer to the NX_UDP_Echo_Server example and compare configurations.I have tried to follow your recommendation, but I am still facing issues with Ethernet bring-up. Please find my observations and current status below.1. Current Status (My Application Logs)ETH HAL initialization is successfulPHY link is coming UPHowever, it is negotiating only at 10 Mbps (Full Duplex) instead of 100 MbpsMAC is configured accordingly (10M Full)Transmission is working (ARP packets are being sent successfully)Reception is not working at allKey observations from logs:ARP requests are transmitted:"ETH Tx OK len=42"But:

Hello everyone. I read that V8 will become available for OEM in Q1, but is there any estimations when V8 will become available for independent engineers or maybe even NUCLEO V8 will be released?

Hello to whom this might concern,I was recently experimenting with STM32C011J4M for a small hobby project (I am trying to fit into a about coin size) and want to comunnicate with other chip over I2C. Due the size of the package I cannot use debugging to find core of the issue, so I used multimeter and legs 4 to 7 as signal outputs. I let CubeMx to generate signal configuration and try to use PA8 as output signal (overlaping with PA11[PA9]). The resulting behavior is that the physical leg 4 is stuck on 1.2V and output is not detectable. If I leave PA11 set as analog-nopull, but remove PA11 from 'HAL_SYSCFG_SetPinBinding' the output becomes readable. From rading on the other pins, I can see, that the communication doesn't work. The I2C is also on overlaping pins (default generation put the pins on PC14[leg 1] and PB6[leg8], which also overlaps with programming connections). I try to communicate with lp581

Hello, we have designed different boards with STM32G0B1.With our latest board we find that bootloader is not activated at power on, even when Boot0 is high roughly 1ms before MCU power rises (I can provide oscillogram), instead of bootloader, application is started.Of course nBOOT_SEL option is zero. After giving a reset, bootloader is correctly starting.The only difference to other boards might be MCU revision. We have that problem with MCUs marked 'Z'. With 'A' marking every board is working.Are there differences between MCU revisions regarding this?Is there a minimum time Boot0 has to be high before power on?Is reset required to activate bootloader (i.e. is it not guaranteed to start after power on? if yes, what are the differences between reset and power on, respectively where are they documented)?I did not find answers to the above in your documentation.Thank you in advance