STM32 MCUs Embedded software

I am using the STM32N6570-DK and I want to use the external PSRAM to declare a large variable buffer. Here is what I have done: 1. Initialized XSPI1 and the External Memory Manager. The PSRAM parameters I got from How to execute code from the external PSRAM using the STM32N6 . 2. Set the XSPI1 clock to 200MHz. Here is my system clock configuration:    Here is my main code from the FSBL. I also added a `gpio_toggle` to turn the user LED on before `MX_EXTMEM_MANAGER_Init()` as a debug indicator.After adding the header and programming, the FSBL boots correctly — the user LED turns on — but then it gets stuck at `MX_EXTMEM_MANAGER_Init()` and never jumps into the `while` loop.int main(void) { /* USER CODE BEGIN 1 */ /* USER CODE END 1 */ /* MPU Configuration--------------------------------------------------------*/ MPU_Config(); /* Enable the CPU Cache */ /* Enable I-Cache---------------------------------------------------------*/ SCB_EnableIC

Hi,I am trying to get any communication with the source through VDM messages on my STM32G071RB + SNK1M1 setup and I am not able to. The source sends a request "VENDOR_DEFINED VDM:SVDM_DISCOVER_IDENTITY INIT" but PE on the sink responds with PE_SEND_NOTSUPPORTED. Power delivery works fine and manages to negotiate different power options.The code is generated with CubeMX following this step-by-step guide: https://wiki.st.com/stm32mcu/wiki/STM32StepByStep:Getting_started_with_USB-Power_Delivery_Sink I followed the manual (https://www.st.com/resource/en/user_manual/dm00598101-managing-usb-power-delivery-systems-with-stm32-microcontrollers-stmicroelectronics.pdf) chapter 4.5 and enabled these VDM features.To implement the VDM callbacks and some DPM callbacks I used this repo: https://github.com/STMicroelectronics/STM32CubeG0/blob/master/Projects/STM32G0C1E-EV/Demonstrations/Modules/ucpd/I am aware that there isn't sufficient hardware support for alternate modes on my current hardware but sh

Hi all,I’m using STM32H755 on a Nucleo board with FreeRTOS, the socket-API and CubeMX-generated LWIP. Sending a UDP packet immediately after network init works fine, but if I wait ~10 seconds before calling sendto(), it returns successfully, DMA descriptors OWN=0, ETH IRQs are triggered, yet no packet reaches the wire. Calling sys_check_timeouts() before sendto() does not help. The tcpip_thread has high priority, while the sender task runs at IDLE priority. In my tests, I disabled the Cache.It seems the issue is not PHY or DMA. It seems that sendto() copies data to the LWIP buffer, but the tcpip_thread does not process it after a long idle. How can UDP packets be reliably sent after idle without changing the network stack or manually triggering anything?Thanks for any insights!

Hi, I'm following the "Programming guidelines for IEEE 1588 timestamping" from page 2792 of the RM0481. I've been working on this specifically for quite a while and I cannot even get the timestamp nanosecond or second registers to move. It feels to me like a clock issue, but unless I'm mistaken, the PTP clock (clk_ptp_ref_i from the manual(p.456)) is the same as the ETH clock (PLL1Q), which I've verified is running because I'm successfully using NetXDuo to negotiate DHCP and send/receive UDP packets successfully. I've also tried initializing the PTP Timestamp without NetXDuo just in case there was some conflict there, but that was also unsuccessful.  Here is my initialization code: /*1. Mask the Timestamp Trigger interrupt by clearing bit 12 of Interrupt enable register(ETH_MACIER).*/ ETH->MACIER &= ~(ETH_MACIER_TSIE); PRINT_U32_BINARY(ETH->MACIER); // 2. Set bit 0 of Timestamp control Register (ETH_MACTSCR) to enable // timestamping. ETH->MACTSCR |= ETH_MACT

I created an issue on github here,  but wanted to post here as well for visibility.Copied below are the details of this linked content: Describe the set-upCustom hardware for our internal product.STM32L496.HAL version 1.13.5.2 devices on I2C bus, HTU21D and PCA9535.Describe the bugSome processors through our production have been coming across errata 2.19.4:   The HAL does not seem to address this errata and the timing for I2C transactions begin failing after the bus error occurs.Sometimes it has led to the I2C bus locking up because the components on the bus (besides the processor) are stuck waiting for a transaction to finish (the device responds properly with ACK/NACK or correct data when the bus error occurs). We have created some messy workarounds that do not fully solve this issue.Additional contextThe following is a diff of the changes I made to address the problem:diff --git a/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_i2c.c b/STM32L4xx_HAL_Driver/Src/stm32l

I want to implement a USBPD sink application with a 9V PDO and I am struggeling to set up a PD-contract with a source. I am using following components:STM32G0B1 MCUTCPP03-M20 PD controllerMy project is based on this example: https://github.com/STMicroelectronics/x-cube-tcpp/tree/main/Projects/NUCLEO-G071RB/Applications/USB_PD/DRP1M1_DRPX-Cube-TCPP v4.1.0 When I attach a PD-source, the DPM_Params[_port].PE_IsConnected variable is successfully set.After that I get in USBPD_DPM_Notification a USBPD_NOTIFY_POWER_STATE_CHANGE event and afterwards a USBPD_NOTIFY_HARDRESET_TX event.I also notice that I do not receive a message within PORTx_IRQHandler, as I do not jump intoif (UCPD_SR_RXMSGEND == (_interrupt & UCPD_SR_RXMSGEND))…Do you have any tips for me where I can start looking for my missing piece? Did i initialize something wrong?

Bonjour,J'utilise la suite CUBEMX et CUBEIDE  pour créer mon projet à partir d'une carte de développement NUCLEO-U575ZI-Q.J'ai réalisé mon projet sur CUBEMX en gardant et validant le BSP de la NUCLEO pour utiliser les leds et surtout le debug via ST-LINK embarqué.J'ai ajouté des IO pour effectuer une maquette avec SPI1 et OCTO-SPI1 plus quelques IO notamment une PWM.Pour commencer j'ai d'abord réalisé un bout de code pour faire clignoter une led (LED_GREEN); à une certaine fréquence réglée par HAL_Delay.Le souci est que cette fonction bloque car le Tick ne semble pas être validé, (HAL_GetTick  me retourne toujours 0)...Je crois pourtant avoir validé les interruptions :Hello,I am using the CUBEMX and CUBEIDE suite to create my project based on a NUCLEO-U575ZI-Q development board.I created my project on CUBEMX, keeping the NUCLEO BSP to use the LEDs and, above all, debugging via the embedded ST-LINK.I added I/Os to create a model with SPI1 and OCTO-SPI1, and a few I/Os, includi

Title edited - originally said, "sharing data between two boards" Good day y'all, I'm trying for the first time to have the two cores on a H7 board share data between one another on shared memory, in particular cm7 writing data and cm4 read it. From what I understand I need to use a semaphore to signal back and forth to alert the cm4 when there is new data in every iteration, the theory I get, but I'm not sure of the shared memory allocation and the semaphore correct availability. Is there any example code I can see to understand how it's supposed to go? I tried looking at the ide examples, but anytime I try to open the example folder the ide application just dies :\  Thx all for the advices,  P.S. I'm also using FREERTOS but it's not supposed to cause any problem but you never know 

Hello, I've been following closely with the github while I work on the recording portion myself, and I saw that x-cube-azrtos-h7 was updated today.  I immediately looked for the recording project, and couldn't find it. Even this page shows up Error 404: https://github.com/STMicroelectronics/x-cube-azrtos-h7/tree/main/Projects/STM32H743I-EVAL/Applications/USBX/Ux_Device_Audio20_Recording Do I not have access to it?

I am testing Ethernet on STM32H723ZGT6 by transmitting UDP packets (1024 bytes) every 1 ms. Setup / Implementation: No CubeMX / HAL used Fully bare-metal Ethernet driver (lwIP integrated manually) Ethernet interrupts enabled and serviced RX handled inside while(1) loop Non-blocking transmit path MPU enabled Memory configuration: RX pool located in AXI RAM lwIP heap: 32232 bytes in D2_SRAM Observed Behavior: System runs normally for many hours (sometimes >12 hours) Eventually UDP transmit stops working Ping continues to work without issues Debugging shows failure occurs at: pbuf_alloc(PBUF_TRANSPORT, len, PBUF_RAM); After failure: 1) pbuf_alloc() returns NULL (ERR_MEM) 2) ETH->DMACSR reads 0 while (1) { sys_check_timeouts(); if (eth_rx_rdy) { eth_rx_rdy = 0; ethernetif_poll(&gnetif); ETH->DMACIER |= ETH_DMACIER_RIE; } if (sys_now() - udp_tx_timer >= 1) // 1 ms transmit interval { ret = udp_server_send(udp_tx, sizeof(udp_tx)); if (ret

Hi everyone,I am experiencing a strange discrepancy in the behavior of HAL_UARTEx_ReceiveToIdle_DMA between LPUART2 and LPUART3 on an STM32U083RCT6.Environment:MCU: STM32U083RCT6IDE: STM32CubeIDE v1.17.0Library: STM32CubeU0 Firmware Package V1.3.0 (Released 04-June-2025)The Issue: I am using HAL_UARTEx_ReceiveToIdle_DMA to handle asynchronous reception of variable-length packets.LPUART2: Works perfectly. When an IDLE line is detected, the DMA transfer stops as expected, and HAL_UARTEx_RxEventCallback is triggered.LPUART3: When an IDLE line is detected, the interrupt is generated and HAL_UARTEx_RxEventCallback is triggered correctly. I am able to handle and process the variable-length packets without any issues. However, the DMA transfer itself does not stop (it remains in an active state), unlike the behavior observed on LPUART2.Configuration: Both instances are configured in STM32CubeMX as follows:Baud Rate: * LPUART2: 230400 bpsLPUART3: 115200 bpsDMA: DMA1 [Channel configuration]Mode

Hi,we are trying to get SDMMC1 running on our evaluation boards (STM32H757-EVAL) but without any success so far.To further investigate the issue we started a new project from scratch, using CubeMX with sdmmc1 enabled. It doesn't work neither.btw: board and SD interface are OK. i.e.the demo that came with the board is reading video files from SD card successfully.Please, can someone provide a ruuning setup for Cube-MX (STM32H7 firmware 11 or 12) with the specific settings for Clock Configuration and SDMMC1.We are using CubeMX 1.15, STM32H7 firmware package V. 12.1.The error happens during SD PowerOn(), i.e. there is no response from CMD8, CMD55...Thanks for your helpTom  

I need gateway firmware binary for EU433 + Loriot.for my PNUCLEO LRWAN 3 gateway

I have setup HAL, systems clocks, etc.  ADC 1 & 2 work PC4 (channel 14).  ADC3 with PF3 (channel 9) PF4 (channel 14) or PF5 (channel 15) don't work with the same code.  Port C & F enabled, ADC1-3 clocks enabled. Thanks for your help!   { GPIO_TypeDef *ThePort; int ThePin, TheChannel; ADC_TypeDef *TheADC; ADC_HandleTypeDef hadc; __HAL_RCC_GPIOC_CLK_ENABLE(); __HAL_RCC_GPIOF_CLK_ENABLE(); //PF3 Thermisor ADC3_CHANNEL_9 //PF4 Thermisor ADC3_CHANNEL_14 //PF5 Thermisor ADC3_CHANNEL_15 //PC4 Power ADC12_CHANNEL_14 /* works ThePort = GPIOC; ThePin = GPIO_PIN_4; TheChannel = ADC_CHANNEL_14; TheADC = ADC1; // or ADC2; */ ThePort = GPIOF; ThePin = GPIO_PIN_4; TheChannel = ADC_CHANNEL_14; TheADC = ADC3; // Configure PF3 as Analog Input GPIO_InitTypeDef GPIO_InitStruct = {0}; GPIO_InitStruct.Pin = ThePin; GPIO_InitStruct.Mode = GPIO_MODE_ANALOG; GPIO_InitStruct.Pull = GPIO_NOPULL; HAL_GPIO_Init(ThePort, &GPIO_InitStruct); // Enable ADC3 Clock __HAL_RCC_ADC1_C

Hi all,I am a beginner working with the STM32N6570-DK development kit using STM32CubeMX(V6.16.1) and STM32CubeIDE (v2.0.0). I am looking to deploy an AI model from the ST model zoo and need guidance on the proper configuration for integrating the camera and display modules. Could anyone provide a step-by-step cub MX project configuration for camera and display interfacing. RegardsSradha

HiI am new to display and camera interfacing, as well as the STM32N6570-DK. For a project, I want to display the output from the camera (come along with STM32N6570-DK) into the display included with STM32N6570-DK. Could you explain the necessary configurations in STM32CubeMX and how to write the code in STM32CubeIDE to interface these components?My Tool version infoCube IDE 2.0.0Cube MX 6.16.0Best RegardsRanjith

I got an angle encoder with SSI interface, which is Synchronized Serial Interface. The output data is 21-bit. No CS signal is needed.I have implemented using SPI1 master mode RX only reading this encoder, with SPI_CLK as the serial clock and SPI_MISO for data input. The data size to read is set to 3 bytes,  but the clock is transmitted one more byte as intended. HOW DID THIS HAPPEN? Does the SPI send a dummy address on receiving?The clock is generated immediately upon calling __attribute__((aligned(4))) uint8_t raw_angle[16] = {0}; HAL_SPI_Receive_IT(&hspi1, raw_angle, 3);The data captured by logic analyzer:The CubeMX setting is as below: I found that SPI_SR_RXNE is left triggered after 3 bytes read by the HAL API, so I have to clear the flag before calling HAL_SPI_Receive_IT. while((SPI1->SR & SPI_SR_RXNE)){ SPI1->DR; } HAL_SPI_Receive_IT(&hspi1, raw_angle, 3); I have also tried DMA mode using HAL_SPI_Receive_DMA(&hspi1,

DescriptionHello, I am using STM32F411RET and STM32F407ZGT microcontrollers.Using STM32CubeMX, I configure a PWM output on GPIOB Pin 8 using TIM10 Channel 1.After code generation, the following GPIO initialization code is produced: GPIO_InitStruct.Pin = GPIO_PIN_8; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; GPIO_InitStruct.Alternate = GPIO_AF3_TIM10; HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); The PWM output works correctly on hardware.However, when full assertions are enabled by defining USE_FULL_ASSERT, an assertion failure occurs inside HAL_GPIO_Init() at the following check: assert_param(IS_GPIO_AF(GPIO_Init->Alternate)); After inspecting the IS_GPIO_AF() macro for STM32F4 devices, I noticed that GPIO_AF3_TIM10 is not included in the list of valid alternate functions, even though TIM10 uses AF3 on STM32F4 devices and is correctly generated by STM32CubeMX.This causes a false assertion failure when using

There's a bug in STM32N6 HAL DCMIPP driver function DCMIPP_SetConfig.It only sets capture mode bits for PIPE0 to PIPE2, but does not clear them: /* Set the capture mode */ hdcmipp->Instance->P0FCTCR |= CaptureMode;CaptureMode options are:#define DCMIPP_MODE_CONTINUOUS 0U /*!< DCMIPP continuous mode (preview) */ #define DCMIPP_MODE_SNAPSHOT DCMIPP_P0FCTCR_CPTMODE /*!< DCMIPP snapshot mode */As a result, after having DCMIPP in snapshot mode it is not possible to re-configure DCMIPP into continuous mode using HAL.Workaround is to manually clear CPTMODE bit.

Chip model: STM32H723VGTxBoth the RX and TX buffers are allocated in the D2 domain.1.CubMx settings are correct.2.HAL_UART_Transmit_DMA runs normally on the first run.However, after running HAL_UART_AbortReceive, HAL_UART_Transmit_DMA fails.Tracing the HAL_UART_Transmit_DMA function:The huart->gState value is always 0x33.

I’m currently working with an STM32F4 series MCU and using UART with DMA for receiving data from an external module.The incoming data packets are variable length and don’t always end with a fixed delimiter. Right now I’m using:HAL_UART_Receive_DMA()Circular DMA modeIDLE line interrupt to detect end of frameHowever, I’m noticing occasional frame misalignment when packets arrive back-to-back with minimal delay.A few questions:Is using the UART IDLE interrupt still considered the most reliable method for variable-length packet detection?Would switching to LL drivers improve timing control significantly in high-throughput scenarios?Are there recommended buffering strategies to avoid data corruption when processing data inside the IRQ context?System details:MCU: STM32F4Baud rate: 115200No RTOS currentlyProcessing happens in main loopAny advice or production-proven approaches would be appreciated.Thanks!

Hello,I hope someone with more experience with the STM32N6 and ThreadX can help me get an efficient solution.I'm using STM32N6 to communicate with multiple peripheral devices via UART. The protocol they are using to send data however, does not allow me to know what the message is in advance, or how many bytes the received packet would be. I only know the packet ends with 0x0D 0x0A. Other MCUs I've used in the past have some built in Pattern matching in the DMA so the DMA interrupts when a combination of symbols is received (0x0D 0x0A). However I don't see something like that in the STM32N6 HAL. I did a driver using the simple HAL_UART_Receive_IT(huart, &UART2_rxByte, 1); and interrupt on every byte to check if a packet is received, but It is really painful to know CPU time is wasted on entering interrupts when I need it for processing data. Maybe ThreadX can be more efficient with some polling thread? Or I missed some configuration option? What would you suggest?

I'm creating a CANopen protocol, but I'm having a problem with the code. I used two while loops, and as far as I understand, this is preventing me from seeing the data I'm getting from the sensor in the 'live expression' section. Do you have any suggestions?/* USER CODE BEGIN Header */ /** ****************************************************************************** * @file : main.c * @brief : Main program body ****************************************************************************** * @attention * * Copyright (c) 2026 STMicroelectronics. * All rights reserved. * * This software is licensed under terms that can be found in the LICENSE file * in the root directory of this software component. * If no LICENSE file comes with this software, it is provided AS-IS. * ****************************************************************************** */ /* USER CODE END Header */ /* Includes ------------------------------------------------------------------*/ #include "main.h"

Hello,I'm working on a project where, per SPI channel, I need to:Read voltage from four AD4630, 2x6 bytes read and 2x3 bytes read.Calculate outputSet 4 MAX5719 DAC output 4x3 bytes transferEach of them use separate cs pinI need to handle 3 channels like one described, so the blocking method is not possible. For now, I manage to achieve a 25 kHZ update loop of a single channel update working in a loop, where after triggering MAX5719, I immediately trigger conversion of AD4630 and another SPI transfers.My setup consists of:STM32H755ZIQ, firmware runs on M7 coreI set up a project with CubeMX and then modified the HAL SPI DMA TRANSFER/RECEIVE functions to remove all unnecessary boilerplate codeAccess the chip select GPIO by directly modifying the BSRR registerInlined a bunch of functions related to handling the interruptsEnabled O3 optimizationOptimised/Removed all data processing and focused only on transferMy loop is affected by the transfer speed of the SPI in the following way:12.

I'm using STM32F429 and trying to read the internal temperature sensor and convert it to a degree C value. Absolute accuracy is not important right now, I just want to make sure a reasonable representation of temperature is being produced. The ADC is running continuously with DMA dropping the result into a uint16_t variable which I'm monitoring. The variable gives a raw value around 1220 (decimal) at room temperature, and feeding this value into the __LL_ADC_CALC_TEMPERATURE_TYP_PARAMS macro gives an output of around 21C. So far so good.Warming up the micro gently with a hairdryer shows the ADC value increasing, as I believe it should. However, the calculated output from the macro falls, and reviewing the content of the macro this is not surprising:#define __LL_ADC_CALC_TEMPERATURE_TYP_PARAMS(__TEMPSENSOR_TYP_AVGSLOPE__,\ __TEMPSENSOR_TYP_CALX_V__,\ __TEMPSENSOR_CALX_TEMP__,\ __VREFANALOG_VOLTAGE__,\ __TEMPSENSOR_ADC_DATA__,\ __ADC_RESOLUTION__) \ ((( ( \ (int32_t)(((__TEMPSENSO