STM32 MCUs Products

Hi i am working on a project with STM32H7A3VGT6 chipset which has LTDC controller. my goal is to make a LVGL based UI with SquareLine Studio and interface a 24 bit parallel RGB display with it . so i have made a UI using SquareLine Studio and imported to my project but the issue is when i try to build it it says flash overflowed. i know that the UI takes so much space but the spec of STM32H7.. says it mas  1 MB RAM . later in the linker script i saw it uses dual bank flash not single , so can i use it like this to make it work ? and any one can explain why is the RAM is also divided? MEMORY { ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K /*FLASH2 (rx) : ORIGIN = 0x08100000, LENGTH = 512K*/ DTCMRAM1 (xrw) : ORIGIN = 0x20000000, LENGTH = 64K DTCMRAM2 (xrw) : ORIGIN = 0x20010000, LENGTH = 64K RAM (xrw) : ORIGIN = 0x24000000, LENGTH = 1024K RAM_CD (xrw) : ORIGIN = 0x30000000, LENGTH = 128K RAM_SRD (xrw) : ORIGIN = 0x3

Post edited by ST moderator to be inline with the community rules for the code sharing. In next time please use </> button to paste your code. Please read this post: How to insert source code.Hi,I am new to STM32 and I have to do a data acquisition board project using the STM32H7 MCU.I have the STM32H753XI-EVAL evaluation kit and I am trying out all the features one by one.I'm currently working on the DAC, which I have configured on CHANNEL2 on PA5. I am trying to start it up, send it a value, and then get its value to check and measure it using a voltmeter on PA5 of CN6 on the evaluation board.DAC1_Init :  static void MX_DAC1_Init(void) { /* USER CODE BEGIN DAC1_Init 0 */ /* USER CODE END DAC1_Init 0 */ DAC_ChannelConfTypeDef sConfig = {0}; /* USER CODE BEGIN DAC1_Init 1 */ /* USER CODE END DAC1_Init 1 */ /** DAC Initialization */ hdac1.Instance = DAC1; if (HAL_DAC_Init(&hdac1) != HAL_OK) { Error_Handler(); } /** DAC channel OUT2 config

Hello all,I’m hitting a USB edge case on an STM32H573 in the 68-pin package (no VBUS sense pin, no VDDUSB domain).My setup (works fine in application):The product is self-powered (3V3 is always on). Because the package has no VBUS_SNS, I detect bus presence with a VBUS → resistor divider → buffer → GPIO (interrupt). My firmware only enables the USB device and D+ pull-up when this GPIO says VBUS is present, so we don’t “attach” or back-power a sleeping PC. That part is solid.The problem (ROM bootloader only):When I enter the System Memory bootloader and select USB DFU, the ROM seems to bring up the USB device and assert the D+ pull-up even if VBUS is absent (e.g., cable plugged into a powered-off PC or an unpowered hub). That effectively signals attach and can source current toward the host through D+/ESD paths—i.e., not USB-compliant for a self-powered device.Easy repro:H573 68-pin board, self-powered 3V3.Ensure no VBUS (PC off / hub unpowered).Boot to System Memory → USB DFU.D+ goes h

Hi,I want to use LPTIMx to output a PWM signal that changes duty cycle on each period with DMA. The HAL driver implementation for LPTIM PWM is completely wrong, so I tried to find out how to do this from TRM etc.LPTIMx has 3 DMA request events:2xCCRx: Can only be used in input mode for input capture, not with output.1xUP: Update event, which is exactly what I need here. However, it is not a regular single/burst transfer but some sort of hw block mode (DMA channel needs to set BREQ=1 to connect to this request line).LPTIM has another special thing: It only requests a new DMA request once the ARR register is written.So I can write a single register (it does not support burst), and it needs to be ARR or I will never get another DMA request again (with dest address set to ARR register):  /* GPDMA2_REQUEST_LPTIM1_UE Init */ NodeConfig.NodeType = DMA_GPDMA_2D_NODE; NodeConfig.Init.Request = GPDMA2_REQUEST_LPTIM1_UE; NodeConfig.Init.BlkHWRequest = DMA_BREQ_BLOCK; NodeConfig.Init.Dire

Hi, For a reason that I cannot explain, the STM32U575ZI (on the nucleo board) is sending a CAN bus message with infinite repeats and 100% bus utilisation, but I have repeated transmission turned off (DAR bit set to 1) and I have confirmed this using the debugger. It continues to send this message at full rate even if I pause the device in the debugger. My code is configured to send a packet with a changing ID from 0 to 4, but the repeated message always has the same ID (0x1, the first message that was queued), indicating that the message is stuck in the TX FIFO. FDCAN_TXBRP is always 0x1. Interrupts for the FDCAN peripheral are not enabled.   I have the following code as my main loop: if (HAL_FDCAN_Start(&hfdcan1) != HAL_OK) { Error_Handler(); } FDCAN_TxHeaderTypeDef header; header.Identifier = 0; while (1) { const uint8_t tx_data[] = {0x01, 0x23, 0x45}; while (HAL_FDCAN_GetTxFifoFreeLevel(&hfdcan1) != 3) { HAL_Delay(1); } header.Identifier = (header.Iden

Hi I'm playing around with the RTC & tamper peripherals of the NUCLEO-H7S3L8. I'm wondering if the TSOVF can be set when multiple tampering are detected in VBat mode ? If I'm not mistaken, the RM doesn't say anything against it. However, using the RTC_Tamper example, I notice that it's not the case. When connecting back the main power, the tampering is detected and the timestamp generated corresponds to the first event but TSOVF is not set.Could anybody confirm that behavior ? Regards. 

Hi everyone,I’m trying to generate a square wave using TIM5 Output Compare (OC) on an STM32H7 board. I configured TIM5_CH1 to output on PA0, both in CubeMX and manually in HAL_TIM_MspPostInit(). Here is a snippet of my GPIO init: GPIO_InitStruct.Pin = GPIO_PIN_0; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate = GPIO_AF2_TIM5; HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);And the TIM5 channel configuration:sConfigOC.OCMode = TIM_OCMODE_TOGGLE; sConfigOC.Pulse = 3749; HAL_TIM_OC_ConfigChannel(&htim5, &sConfigOC, TIM_CHANNEL_1); The problem is that the square wave always appears on PA1, not PA0, even though I haven’t configured TIM5_CH2 anywhere.I checked the datasheet pin mapping:PA0 → TIM5_CH1PA1 → TIM5_CH2PA2 → TIM5_CH3PA3 → TIM5_CH4I suspect this might be related to alternate function routing or some hardware conflict on PA0 (maybe boot/debug pins), but I’m not sure

Hello,I am working with STM32H743, using ADC1 and 2 in dual simultanious mode, using DMA to store data from ADC_CDR (2 16 bit values) to memory, some hundred values in a stream in continuous mode. This works fine in general but I frequently see a missynchronisation between the two ADCs so that at the output of DMA I have in one 32bit word the lower half word from one ADC1 conversion of one point in time and in the upper half word the ADC2 conversion from the preceeding or succeeding point in time (I didn't check which of the two, but it is only one of them).I read RM0433 ADC section up and down and could not find anything about that. It seems to be more related to hardware, that sometimes triggering DMA does not properly wait for both ADCs to be ready and have their data transfered to ACD_CDR. But it is not occuring or not from sample to sample but it is there for one complete data stream or not, so it seems to be set or not with every setting of ADSTART.Here is my ADC init code:#defin

Hello Community, We are using an STM32U595ZJT6Q microcontroller and have connected an MB85R4M2TFN-G-JAE2 FRAM via a parallel interface. The setup works well under normal operation and even after a power cycle — all data is retained and verified correctly. However, we are facing a consistent issue when performing a microcontroller reset (MRST) without power cycling the board: After MRST, the data at address 0x00 in FRAM is found to be corrupted (0xFF). All other memory locations remain intact. This issue does not occur on power reset — only on MRST. We observed that CS & WR pins go low for ~300 ns during MRST, which seems to be the trigger. Below is waveform captured for the mentioned behaviour.   Below things we did so far:-  Added pull-up resistors on CS and WR line. Ensured early GPIO initialization in firmware to set FRAM control lines high. Verified that no write operations are performed in startup code. Checked FMC configuration and ensured no early access to FRA

 Hello ,I am working with comparators on the STM32L496VGT6 microcontroller.In my setup:COMP1 is configured for rising-edge detection.COMP2 is configured for falling-edge detection, forming a window comparator arrangement.One input of COMP1 is connected to an ADC voltage (through a 2:1 voltage divider).The other input is from the DAC internal connection, operating in sample-and-hold mode with the output buffer disabled.The outputs of COMP1 and COMP2 are routed to external GPIO interrupts.Hysteresis is set to medium.Voltage levels:VH = 0.55 V (corresponding to Vin = 1.1 V after 2:1 divider)VL = 0.275 V (corresponding to Vin = 0.55 V after 2:1 divider)Issue description:When the input voltage is close to the threshold (around 1.05–1.07 V and 0.51–0.54 V), I observe continuous false comparator interrupts instead of a single expected trigger.To mitigate this, I increased hysteresis from medium to high and reduced the number of hold cycles from 64 to 32. This helped reduce the issue, but

As the subject line says, I've written a USART driver for a STM32H755 project where I want to detect a special end-of-line character, for implementing a simple command-line interface.Originally this used DMA with the USART FIFOs disabled, but I recently changed the driver to use the 16-deep FIFOs with FIFO-threshold interrupts, because I am bit short on DMA channels.I couldn't figure out why the character-match interrupt wasn't firing, so I paused execution to look at the USART registers after sending a short (12 characters) command from my serial terminal.  I then refreshed the register view while looking at USART->RDR and was able to see the characters stored in the FIFO come out one by one.Finally after the 12 bytes my "match" character appeared in RDR and then the CMF bit was set in ISR.  This was what I was afraid of.  The RM alludes to the fact that the receive FIFO stores some flags along with each received character.  Well, apparently one of those flags i

Hello,  I have an STM32L4R5 MCU on a custom PCB and I have flashed it with my firmware via USB_OTG_FS. Both CubeProgrammer and the CubeIDE have worked in flashing the MCU for me, given I have an ST-LINK connected to it as well. I have USB_DM, VBUS_Sense, and USB_DP pins set up on my MCU. I am wondering how I can see some sort of output from my MCU. From my searching, I learned the DFU mode is only used for flashing and something like USB CDC is used for communication, through a serial port or UART. I am wondering some ways (preferably efficient and quick) I can go about seeing an output from my MCU that is running my firmware. If there needs to be any more clarification as to my wiring/setup, I will gladly add that. Can USB CDC be setup via firmware, or is it solely a hardware configuration? I do not have pins like UART/LPUART TX/RX connected on my MCU, however, they are able to be jumped of course. I have been using a NUCLEO development board to test my code. When connecting

Hello guys,Can anyone help me on how i need to set up a dma chain reaction so i can read from a timer ccr1, ccr2 registers and write their values to hrtim period and compare1 registers? The only thing I have found until now is how to set up the dma for the timers while being on PWM Input mode, burst read the cc1, cc2 registers and store their values to memory. I have read that I need to use then a DMAMUX request to generate an DMA request for the HRTIM to read the memory and then apply the changes to the peripheral, but I still don't understand how I should i configure the board. I'm using an STM32G474RET.Thanks for your time in advance.

(Please ignore the green area, which is Layer 1 of the LTDC.）I am using an STM32N6570 development board with an external PSRAM (connected via XSPI1) to store camera frame buffers. I have implemented a double-buffering scheme where the DCMIPP writes camera frames into the external PSRAM buffers and the LTDC reads from them for display.However, even with double buffering, I still observe screen tearing. I have tried:Switching the LTDC display buffer only during VSync (vertical blanking)Cleaning the CPU D-Cache before updating the LTDC addressDespite these measures, tearing persists. I suspect the cause is related to the limited bandwidth and high latency of the external PSRAM, combined with the LTDC FIFO prefetching. Essentially, the LTDC sometimes reads the external PSRAM while the DMA is still writing the new frame, causing partially updated frames to be displayed.I want to find a reliable solution to eliminate screen tearing while still using the external PSRAM for camera frames.This

Hey!I'm trying to create a driver for the STM32U545 for TinyUSB . Currently, theres a driver existing for device mode, and theres driver for the boards using synopsys and not usb_fsdev. I have followed the reference manual, and gotten so far:hcd_stm32_fsdev.c (the driver itself) stm32_helpers.h (helper function for different accesses)  It detects the device, and starts sending some data, but then it just stops. Here's full stack trace:[13:54:09.609] Welcome to our controller![13:54:13.617] [0:] USBH Device Attach[13:54:13.771] Device unplugged while debouncing[13:54:13.930] [0:] USBH Device Attach[13:54:14.133] Full Speed[13:54:14.146] [0:0] Open EP0 with Size = 8[13:54:14.154] Get 8 byte of Device Descriptor[13:54:14.162] [0:0] Get Descriptor: 80 06 00 01 00 00 08 00[13:54:14.176] [:0] on EP 00 with 1 bytes: OK[13:54:14.185] [:0] on EP 80 with 1 bytes: OK[13:54:14.193] [0:0] Control data:[13:54:14.198] 0000: 00 |.|[13:54:14.215] [:0] on EP 00 with 1 bytes: OK[

I am currently working on a project that uses the STM32U575CGU3 microcontroller. The goal of the project is to display pressure and temperature values over CAN J1939 and CANopen communication protocols in a digital output format. For sensor data acquisition, I am using an external two-channel ADC to measure pressure and temperature values. Regarding the system clock, I have tested the application using both the internal clock source and an external crystal oscillator. The system performs well in both configurations. However, I would like to request your expert guidance on the recommended clock source for this application. Specifically: Is it advisable to use the external crystal for better timing accuracy and long-term stability? Or is the internal clock sufficiently reliable for CAN J1939 and CANopen communication in a production environment?

Affected doc / sectionRM0492 (STM32H503) → General-purpose timers → Master mode selection (MMS) (TIMx_CR2.MMS = 0000 “Reset”)Current wording (verbatim)“MMS = 0000 – Reset: the UG bit from the TIMx_EGR register is used as trigger output (tim_trgo). If the reset is generated by the trigger input (slave mode controller configured in reset mode) then the signal on tim_trgo is delayed compared to the actual reset.”Why this is confusing / misleadingThe sentence suggests TRGO is tied to the EGR.UG bit. In reality, EGR.UG is software-only; hardware reset does not set EGR.UG. TRGO is driven by the update-generation path (UEV/UG-equivalent internal signal), not by the literal EGR bit.It does not state that with URS=1 (CR1.UPDATE REQUEST SOURCE), a reset from TRGI/ETR does not generate a UEV. Therefore, with MMS=Reset, TRGO is not emitted at the moment of reset; it only appears on a later UEV (e.g., overflow) — or never if the counter is reset before reaching ARR.The phrase “delayed compared to t

why need to monitor txe flag and btf flag to transfer data after each byte.txe says data register is empty,btf  and txe says need monitor after last byte. according to reference manual.but my question is how should i know i get ack after sending 1 byte .in this case which should i check txe,btf.if i check txe if txe==1 i send 2nd byte then how should i know i get ack for byte1.if txe indicate about ack flag received/not ,then why should compulsory use btf flag at end of last byte to check wait untill btf==1 before stop condition.     

I’m implementing an audio clock source switching mechanism where the system runs on the internal audio clock if no external clock is detected. As soon as an external clock becomes available, it switches to use that external clock source.This works initially, but when the external clock is lost for any reason and the system switches back to the internal clock — then later detects the external clock again and switches back — I notice that data is still being received through the SAIs, but the clock is no longer synchronized with the external clock source. It seems to continue running from the internal clock instead.Is what I’m trying to do here actually possible? void SwitchAudioMode(eAudioClockSelection::Enum ClockSelection) { if (gAudioMode == ClockSelection) { return; } else { gAudioMode = ClockSelection; } HAL_SAI_Abort(&hsai_BlockA1); HAL_SAI_Abort(&hsai_BlockA3); HAL_SAI_Abort(&hsai_BlockB3); HAL_SAI_DMAStop(&hsai_BlockA1); HAL_SAI_DMAStop(&hsai_

I would like to set a 1Hz signal on the PC14 (RTC_OUT_CALIB). I have found a manual in document AN3371 (see picture in appendix). The code is also in the appendix. Unfortunately, nothing happens on the PC14 but the RTC works. If anyone has any idea what else to add here, thank you, greetings, SF

HelloCan the STM32H743 modify data at two non-consecutive peripheral addresses in a single DMA event，A DMA event changes two peripheral addresses，

Hello,I'm trying to port the ST IMX335 camera driver middleware to work with the RPi 2 IMX219. Everything works well with the IMX335, however after adjusting to reflect the IMX219 registers I get no image data and a Lane 0& 1 control error flag as soon as I enable streaming.I've switched to using Dump Pipe 0 and reduced the CSI speed but it made no difference.I'm using binning and a reduced ROI to reduce the amount of data coming off the camera. Has anyone has a similar issue?Thanks  

Hi everyone,I would like to know if it’s possible to debug an STM32 microcontroller without using an ST-Link, but instead with an FTDI FT4232HQ chip via its JTAG or SWD interface.If this is possible:How can I configure the debugger connection?Can it be done directly from STM32CubeIDE, or do I need to use another tool (like OpenOCD or GDB)?Thank you in advance for your help!

Hi!I'm struggling to wrap my head around timers - I am trying to schedule some ADC reads of a current sense amplifier in a motor control setup.I have three center-aligned PWM waveforms being generated by Timer1, which successfully commutate a BLDC motor. That's great. I would now like to schedule an ADC read once per PWM period. A simple first try at this would involve a single read right in the center of the PWM waveform. A slightly swankier version would be to calculate the largest duty cycle of my three PWM phases, and schedule my ADC read just after this point (but, again, just once per PWM period). I have experimented with configuring Timer1's TRGO to "Update Event", and scheduling my injected ADC read to be "Timer 1 Trigger Out Event". This, however, schedules the read at the beginning of the PWM period, rather than in the center of it. I'm also experimenting with setting up a slave timer - the idea being to trigger this secondary timer based on the above Timer1 TR

Hello, dear community!I have a problem with adding more than one button to my STM32 Button Box / joystick with buttons. I am using USB HID.I made it as simple as possible - only two buttons, simplest descriptor. The problem may be trivial, but after 4 days and ~8 hours per day - I can't find solution. I watched most of the STM32 USB training course (on yt), I was digging deep in st forum and google/bing/yahoo, but nothing helped. I think there is not a ready answer to my problem in the whole internet.About the problem: One button (the first one) is working flawlessly, but when i try to USBD_HID_SendReport for another button - nothing happens. My descriptor:  // HID Report Descriptor 0x05, 0x01, // Usage Page (Generic Desktop) 0x09, 0x04, // Usage (Joystick) 0xA1, 0x01, // Collection (Application) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1 bit) 0x95, 0x02, // Report Count (2 buttons) 0x05, 0x09, // Usage Page (