STM32 MCUs Products

 I'm developing a power bus manager where I monitor current and voltage drop across a shunt resistor. I chose the STM32G484 as the MCU because it has enough OpAmps and ADCs for my project.However, I have a question that might only be related to electronics, but I'd like to be sure it won't affect the MCU.The bus is supplied by a DC-DC switched-mode power supply where the highest voltage is 12V. We know the voltage drop across the shunt resistor is minimal. So, could I connect the "plus" and "minus" inputs directly to the shunt resistor? Is it necessary to define the gain loop? Or can I work without it? In this case, the question is whether the MCU allows parameterizing the input where "plus" and "minus" are connected directly to the GPIO without any internal interference.Thank you for your support.ps: The project is being developed under CC-By 4.0 license and is available at https://kepr.rapport.tec.br

Hello,I would like to get information about the availability of the following devices:STM32H562IGK6 UFBGA 144 package (10 × 10 mm, 0.8 mm pitch)STM32H562IGT6Could you please clarify:Are these devices currently available in stock for production volumes (~1,000 pieces)?If they are out of stock, what is the reason and what is the expected availability / product longevity?Are there any devices available now for prototyping, in quantities of about 50 pieces?Thank you for your support.Best regards,Aymen

I am working bare-metal on an STM32L433RCT6 (no HAL). I am seeing a precise data bus fault whenever I access a GPIO register.Fault details from the debugger:Fault type: Precise data bus faultBFAR: 0x48000000From RM0394, 0x48000000 is the GPIOA base address, so the fault occurs exactly on GPIO access.The faulting instruction is a normal GPIO register read/write (e.g. ODR access). The GPIO struct layout and offsets are correct, and the compiler generates correct code.I understand that on STM32, a precise bus fault on a valid peripheral address usually means the peripheral clock is disabled.However, I explicitly enable the GPIO clock before accessing it:*(volatile uint32_t*)0x4002104C |= (1 << 0); // RCC_AHB2ENR, GPIOAENAdditional context:Custom register definitions for GPIO/RCC (not HAL)Fault occurs before/at first GPIO accessProgram resets and lands back in Reset_HandlerBFAR(via Fault Analyzer) consistently reports 0x48000000I will also attach the stm32l433xx.h, stm32l433xx_gpio_d

I would like to know how I can program 2 MCUs (stm32wb55cgu6) simultaneously.Currently, I am programming the FUS and BLE binaries (firmware developed by the company).We need to double production, but I can't program via DFU because an error always occurs in one of the MCUs. Is it possible to program 2 MCUs simultaneously, or is that not possible?

I have an STM32L011F4P6 with an RTC.  It is running at 3.3V and 16 MHz off the internal HSI RC clock.  The RTC is driven by a +/-20ppm 32.768 KHz crystal.  It is running at room temperature (23-25C).  After calibration, I am losing several seconds per day!  What's wrong?Here's more information:I have a auto-calibration routine where it will output a 1Hz signal on PA2 and capture the rising edges using TIM2 channel 3, running at 16 MHz.  I capture the start time (1st edge), I interrupt on overflow and add 65536 to a 32bit variable, and I capture the final (33rd) edge to get the total number of 16MHz clocks in 32 seconds according to the RTC.  At the same time, I have a GPS module with a 1Hz output fed into PA10.  I set up TIM21 channel 1 identically to the TIM2 setup, to capture the total number of 16MHz clocks in 32 seconds according to the GPS.I take the two numbers and find the difference, not in PPM but in units of calibration (0.954 PPM)

In my project I've set the SPI clock to 125MHz; with a SPI prescaler value=4 all works good, when I set it to 2 the SPI stops working and ther is no clock signal.Any helps ? Thank youCarloV

I call HAL_UART_Init() with LPUART1 at 20Mbaud but when I activate assertion it fail at IS_UART_BAUDRATE().The IS_UART_BAUDRATE() is not correct for LPUART that can have a baudrate up to 53.3 Mbaud.Also for UART, the comparaison in IS_UART_BAUDRATE() should be <= instead of < like in IS_LL_USART_BAUDRATE().

Greetings!I have the following system:STM32U073CCVBAT pin is connected to a super-cap, and it's voltage was measured to be above the required minimum.During system reset (NRST) it behaves according to my expectations, the RCC_BDCR remains unchanged, but if it is disconnected from Vcc, then upon connecting it back, the LSESYSEN bit is set to 0. This seems reasonable, and is generally not a issue to me, but the reference manual claims that this shouldn't happen? (Everything else works perfectly.)Am I missing something obvious here?Couldn't find any other mention of the bits behaviour.

Hello,    We have developed an image capturing application successfully based on STM32H7xxxx and OV7725 camera. We are now targeting to port the application to target STM32U5xxxx with the same camera. But it looks the DMA doesn't works as expected. The DCMI DMA complete callback is firing with no image data in the target buffer.     Please guide us how to port the application from H7 to U5.Best regards-Shubhendu Bikash BanerjeeAttaching here snaps of the configurations we made so far.DCMI GPIODCMI NVICDCMI parametersGPDMA1 channelsGPDMA1 CH0GPDMA1 securityCode snippet:#define IMAGE_FRAME_WIDTH 320 #define IMAGE_FRAME_HEIGHT 240 #define IMAGE_BYTES_PER_PIXEL 2 #define IMAGE_BYTES_COUNT (IMAGE_FRAME_HEIGHT * IMAGE_FRAME_WIDTH * IMAGE_BYTES_PER_PIXEL) static uint32_t gDCMIBuff[IMAGE_BYTES_COUNT / sizeof(uint32_t)] = { 0 }; static volatile bool gWaitForFrame = false; CaptureFrame{ gWaitForFrame = true; halReturn = HAL_DCMI_Start_DMA(&hdcmi, (uint32_t) DCMI_M

Hello @Imen.D , A side question: RM0440 for G4 says oversampling mode does not support offset. Any change to this position as like the H7 change?  Solved: 'H7 ADC offset correction in oversampling mode - STMicroelectronics Community Thank you. SK

Hi everyone,I’m using an STM32L562 MCU and outputting LSE (32.768 kHz) to MCO for measurement.In LSE crystal mode, I see a large frequency deviation on the oscilloscope (much larger than expected ppm-level error).To rule out the crystal itself, I checked the 32.768 kHz crystal and it seems OK.Then I tried LSE bypass mode (feeding an external 32.768 kHz clock into the LSE pins). In this case, the MCO output frequency error becomes very small, and the waveform/frequency looks correct.So I suspect there might be an issue with the LSE oscillator circuit (load caps, PCB layout, drive strength, leakage, etc.) when running in crystal mode.Questions:Has anyone experienced large LSE frequency error in crystal mode on STM32L562 / STM32L5 series?Any common root causes (wrong load capacitors, stray capacitance, drive level, board leakage, etc.)?Any recommended debugging steps or configuration tips (e.g., LSE drive settings, oscillator startup behavior, measurement method, etc.)?Thanks in advance!&

Hey,  I am using the STM32G0B0VET (16MHz HSE) with a virtual com port over USB. The virtual com port is working fine but as a backup I would love to be able to let the user reflash the device. I was thinking of using the DFU for this since then the user would only need a standard USB cable (consumer electronics hopefully high volume). I exposed a button that can pull BOOT O high (small reprogram button you have to push). (Normally in the field updates are not needed but I would like to have this as a backup). Now I have the following problem when I boot the device (that is flashed) when pressing the button (keeping BOOT 0 high) my PC sees the virtual COM port and not the DFU device. It is thus running the usual code and not entering the bootloader. If I erase the STM32 with the ST link I can access the DFU just fine with the boot button. Does anybody have a fix for this?  Best regard and thanks already for the help.  

Hi,i have  new design that i am migrating to the STM32G071 and having issues with the SPI1 port PB3,PB4,PB5. Changing CPOL and or CPHA during init code do not seem to have any impact, when powered down and restarted.I am seeing 9 clock pulses when set to 8 bit data. Suspect this might be issues with the overall SPI setup.the init code is simple changed to the absolute simplest format.ignoring setting the PB3,4,5 GPIO pins as they are good i can see the signals on the cro// bidirectional mode full 2 lineSPI1->CR1&=~SPI_CR1_BIDIMODE;// set as masterSPI1->CR1|=SPI_CR1_MSTR;// CPOL clock idle lowSPI1->CR1&=~SPI_CR1_CPOL;// CPHA rising clock edgeSPI1->CR1&=~SPI_CR1_CPHA;// set LSBFIRST low we send MSB firstSPI1->CR1&=~SPI_CR1_LSBFIRST;// set up SSM pinSPI1->CR1&=~SPI_CR1_SSM;SPI1->CR1&=~SPI_CR1_SSI;// configure data size 8 bitsSPI1->CR2|=(SPI_CR2_DS_2|SPI_CR2_DS_1|SPI_CR2_DS_0);// set the reception thresholdSPI1->CR2|=SPI_CR2_FRXT

Jakarta Pusat 1, RT.1/RW.5, Menteng, Kec. Menteng, Kota Jakarta Pusat, Daerah Khusus Ibukota Jakarta 10310

Jakarta Pusat 1, RT.1/RW.5, Menteng, Kec. Menteng, Kota Jakarta Pusat, Daerah Khusus Ibukota Jakarta 10310

Jl. Gajah Mada No.19-26 110, RT.2/RW.1, Petojo Utara, Kecamatan Gambir, Kota Jakarta Barat, Daerah Khusus Ibukota Jakarta 10130

If I am correct, the descriptions of - HRTIM_ADC2R   -  Bit 22 - HRTIM_ADC3R   - Bit 19   - Bit 13 - HRTIM_ADC3R   - Bit 22   - Bit 13   - Bit 10   - Bit 5   - Bit 4   - Bit 0are not correct in the RM.They all describe trigger event generation but the trigger output in all these seem wrong:E.g.: HRTIM_ADC2R, Bit 22,Original Text: "This bit enables the generation of an ADC trigger upon timer C reset and roll-over event, on ADC trigger 1 output."It should be: "This bit enables the generation of an ADC trigger upon timer C reset and roll-over event, on ADC trigger 2 output."Also, I want to ask, if this forum is the right place to give feedback on documentation issues?Best Simon

Dear ST Team,I am using an STM32H5 series microcontroller in my design and I am trying to understand the overall power consumption contributed by different MCU interfaces.So far, I have identified the following:The typical maximum current on VDD, in VOS0 condition with all peripherals enabled, at 85 °C, is approximately 118 mA (based on STM32H5 datasheet values).My Question:I tried to find similar information for the VDDIO supply pins.However, the datasheet only provides peripheral-wise consumption in µA/MHz, which appears to apply to low‑power (sleep) modes, not active RUN‑mode.I want to calculate the VDDIO current consumption for my specific design configuration.My active interfaces are:16‑bit SDRAM on FMC, operating at 166 MHzQSPI Flash memorySPI interfacesUART interfaces4 ADC channelsApproximately 50 GPIO pinsThe MCU is operating at 250 MHz (VOS0) in RUN mode.Thank you.Regards,Rajesh Matere 

Hi everyone,I am currently trying to measure the CPU temperature using the internal temperature sensor of an STM32F733.I am testing the device inside a climate chamber (oven) to verify the readings. I am fully aware that the datasheet states the sensor is more suitable for detecting temperature variations rather than absolute measurements. However, the values I am getting seem to have a significantly larger offset/gain error than expected.The Setup:MCU: STM32F733Method: To rule out self-heating of the die, the device is kept powered OFF inside the oven until the target ambient temperature is reached and stabilized. I then power it on and immediately take the ADC measurement.Vref+: Connected to external reference voltage (2.048V).The Observations:Oven at 60°C -> MCU calculates 68°COven at 80°C -> MCU calculates >90°CMy Question:Is an error of this magnitude (>10°C at higher temperatures) considered "normal" for the internal sensor of the F7 series, even when using the factor

Hello, i am using a stm32f103 mcu to provide rtc functionality. I am using a external crystal  of 32768 hz for the rtc block.The crystal is rated at 6pf load. +/- 20ppm  PN:   QT1C-32.768KDZB-T Apart from this i have also implemented a external gps module   to provide a  "reference time" via uart.Upon power on, the mcu configure the rtc counter with values for  hours,minutes,seconds  taken from the  the gps,   then i just display them on a lcd.My problem is the time drift  on the rtc when comparing the time from the gpsFor example, after 10 hours of functionality,  my  rtc clock drifts with 7-8 seconds when compared with the gps time. I have tried to measure the rtc clock on the tamper pin, and here things start to show upThe measured frequency on the tamper pin ( PC13)    is 512.295hz.this is giving a huge ppm diference   of about 576 ppm. I have tried with several i

Good Morning,   I'm struggling with FDCAN Bus Recovery. The system we have to use consists of an STM32H753-based board and a 3rd party ECU, which is internally terminated via software. Our custom board is also terminated, resulting in the correct 60 Ohm between CAN Hi & CAN Lo. In the event I add an additional termination resistor to the Bus, the power-up sequence doesn't matter, however the bus is the over-terminated, which is obviously not correct. I can, however, see the custom board initially blurting out a CAN frame as fast as it can before the other ECU has finished powering up, and then normal CAN comms is seen on PCAN (the PCAN has been configured to not send any Acks). However, if I leave the bus as it is, it looks like the bus from the perspective of the custom board just turns off. I can see the 3rd party ECU splurging out one of its' messages as fast as it can, however our board should be seeing this message and transmitting Acks etc. I have implemented the Bus-Off

Hi there,I have been struggling with the PSRAM. I bought the STM32H7S78 board to pick up the know-how to understand how I should configure the PSRAM at XSPI1 via the EXT MEM manager at my own board. My clock speed is 200MHZ XSPI. PSRAM MPN: APS6408L-OBMX-BAMCU type is slightly different (STM32H7R7L8H6)For sure, I connected the programmer to configure the sbs since the VIO is 1.8V. What I missed from the HW was that I forgot to add the pull-up resistor at the CE pin. Note: I desoldered from the original ST board to check the behaviour and did not influence its behaviour. The reset is connected to the NRST by a diode. Note: Checked the connections, footprints. GND is on the mid1 layer and all of the connections are on the top layer. The length is less than 14mm and the distance between the track are usually 0.2~0.25mm.So all in all, I excluded the HW errors. Note: I bought the same PSRAM as on the ST board and I can use those configs after all. However, before I desolder t

I have a new board design that interfaces an STM32L4A6 with a uSD card using 1.8V I/O. The SD Card is powered by 3.3V and supports the LVS mode of SD. The STM32L4 does not seem take account the SD specification 6.0. There is no auto detection mecanism of the signalling voltage level in this MCU. This MCU can not start in UHS-I 1.8V mode.Do you know a MCU which can start the LVS identification sequence ?

Is there a comprehensive single documentation source of the Flash layout for say, an STM32H563?The documentation I find is very opaque.  Questions I have at present (From a non secure perspective):1. Where is OBK located? (0x0BF0000 to 0x0BF9FFFF ???)2. Where is system located?3. Is RSSLIB actually using OBK memory? Or is this located somewhere else?4. Is there a way to self program the debug password for PRODUCT_STATE > OPEN?5. If #5 true, are there some real docs on this?  All I find so far is tutorials and code for the 573 in a secure perspective. 

Hello,I want to add a software update feature to my device, but I am unsure about the correct way to verify a newly installed firmware image. My goal is to make sure that the entire firmware has been written correctly and is not corrupted before the bootloader starts using it.One idea I have is to calculate a CRC of the whole application at build time and store this CRC at the end of the application image in flash. Then, during boot, the bootloader would calculate the CRC of the application in flash and compare it with the stored value to decide whether the firmware is valid. However, I am not sure if modifying or reserving a part of the application flash for this purpose is a good or recommended approach.Are there more common or reliable methods to verify a newly installed firmware before activating it? How is this typically handled in bootloader-based firmware update systems?