STM32 MCUs Embedded software

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 @B.Montanari  I am working with the STM32N6570-DK board and facing an issue while configuring LTDC in a dual-project (FSBL + Application) setup. As an initial step, I tested the "LTDC_Horizontal_Mirroring" example provided for STM32N6. This example is built as an FSBL-only project, and after building and flashing it, the display works correctly as expected. However, my final goal is to use LVGL for GUI development. Since I need more memory space for image storage and application resources, I created two separate projects: FSBL project – responsible for boot and low-level initialization Application project – intended to handle LTDC and GUI (LVGL) In my setup: The device boots successfully. FSBL execution appears correct. Control jumps to the Application project. LTDC peripheral configuration in the Application project is replicated from the working example. RIF configuration is performed in the FSBL project. Despite this, the display remains gray after

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

Hi, I'm have a trouble with UART Interrupt when using FreeRTOS.I want to receive a string buffer send from Serial Terminal ( Hercules Software ) using UART interrupt mode. But when I send data, I just receive 2 character. Ex: When I send "Resume", I just got echo back 2 line: "Rx_data:R","Rx_data:e".Has anyone else encountered this problem? Please share a solution with me.This is my call back function: void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; HAL_UART_Receive_IT(&huart1, &Rx_data, 1); if(Rx_data == '\n') { Rx_buffer[Rx_index] = '\0'; if(strcmp((char*)Rx_buffer,"Resume") == 0) { xTaskResumeFromISR(AboveNormalHandle); } Rx_index = 0; } else { if(Rx_index < sizeof(Rx_buffer)-1) { printf("Rx_data: %c \n",Rx_data); Rx_buffer[Rx_index++] = Rx_data; } } portYIELD_FROM_ISR(xHigherPriorityTaskWoken); } 

Many small format LCD displays do not provide parallel RGB interfaces but instead rely on high-speed serial interfaces such as QSPI. To support this class of display is it possible to use the XSPI peripheral in QSPI mode to drive them? An example LCD controller transaction is shown here:  The data line mapping is as follows:SDI_SDA -> IO0DCX     -> IO1D[0]    -> IO2D[1]    -> IO3

stm32_IEC_project_CM7.elf [cores: 0]Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)0xfffffffe<signal handler called>() at 0xfffffff1HAL_TIM_IRQHandler() at stm32h7xx_hal_tim.c:3,777 0x8055b74TIM3_IRQHandler() at stm32h7xx_it.c:185 0x804a352<signal handler called>() at 0xfffffffdprvPortStartFirstTask() at port.c:267 0x8065f78xPortStartScheduler() at port.c:379 0x806608cpxPortInitialiseStack() at port.c:214 0x8065ed0   This is the error which comes suddenly. here i use tim3 as base source for the tick interrupt of task scheduler as replace of  systick. Previously this code works fine. suddenly creates issues in worked hardware itself  . after some time device works and fails randomly but same code what reason    

Hello, I saw the thread below and now a bit confusedhttps://community.st.com/t5/stm32-mcus-embedded-software/update-about-usb-pd-stack-to-support-epr-mode/td-p/829168It says EPR is supported with a TCPP package but the TCPP-M18 itself - rated to 100W max.  Do I install the software package but do not put TCPP chip? If so How do I know which functions I need to Disable/enable because I know TCPP communicates with MCU over I2C (which is hidden BTW in main.c)

I want to calculate the resistance/power of an AC heating element by measuring voltage (via a voltage divider) and current (using an ACS71240 current sensor). The hardware setup is fine. I get the expected values. I checked this when using Arduino Framework's analogRead(). But that call is so slow (because it does the whole ADC initialization and deinitialization every time), that there's too much time between the voltage and current measurement.So while I'm still using the Arduino Framework for most of the code, I've used CubeMX to configure the ADC with DMA and integrated that code into mine. I initialize the ADC/DMA, run one ADC calibration, then in a loop call HAL_ADC_Start_DMA(), wait on a dma_complete variable, that is set in the HAL_ADC_ConvCpltCallback(). This works ... almost.At some point the values of the channels end up in the wrong order in the DMA buffer. So the second channel's conversion result is first in buffer and the first's in the second place. This

I'm trying to make audio equipment using stm32f446re board and pcm5102 module. When I used the audio equipment, when I sent music using i2s communication, the output came out well, but when I finished DMA setting after selecting i2s protocol in sai, the output didn't come out smoothly. (DMA checked operation using callback)Also, I checked pcm5102 can be operated no external sck.What's the problem?   

Hello,I am working with STM32 IDE v2 and stm32u585 processors. I have a project which is configured with the help of stm32 cube mx and has its own core/Drivers/.ioc files. It is like a ground for using the processor together with other external modules, like sensors, flash chip, LED drivers which are on the same PCB together with the MCU. I have two products using a processor of this family - one is with 64 pins and other with 100 pins. But they have basiccally the same hardware design and use the same pin mapping and peripherals as close as possible to one another. So both can use the same ground project and its configuration and picking different peripherals based on needs. The customer interface is defined separately, in a project that used to be called Application where MMI part is. It is a higher level project and does not need to know what hw there is. Before it was possible to have the ground project as a submodule to  a couple of application projects and it was building wi

I can build it successfully using west but when I program it I get: "Warning: The core is locked up" and no LED blinks. I also made my own blinking LED but that doesn't work either. I can program the board using stmcubeide and that work. It seems to be an stm32cubeprogrammer issue?

I'm checking the output of internal opamp in the STM32U083C-DK.In both PGA and Follower modes, I found that the opamp output voltage was lower than the actual input signal. Follower mode/before calibration(Factory trim/0xe13): - Input signal: 0.2502V -> Output signal: 0.2488V PGA mode(Gain: x8)/before calibration: - Input signal: 0.1010V -> Output signal: 0.7942V So, I used the opamp's internal calibration function. Follower mode/after calibration(User trim/0x1f12): - Input signal: 0.2502V -> Output signal: 0.2350V PGA mode(Gain: x8)/after calibration(User trim/0x1f12): - Input signal: 0.1010V -> Output signal: 0.6852V However, the opamp output signal level was further reduced, indicating that something was wrong.Before calibration, the opamp's factory trim code was 0xe13, but after calibration, the user trim code was set to 0x1f12. It appeared that the P terminal calibration value was set to the max (0x1f). (As an additional condition, I opened SB12 on the STM32U083C-DK bo

Custom board. STM32U5G9. I am running Zephyr and trying to use PB8 and PB9 for the FDCAN peripheral. In loopback mode, it does not get any errors but in normal mode it does. The odd thing is that if I change the pins in the dts file to PA11 and PA12, it works fine.  I am guessing that it is a timing/clock issue or something but I have been arguing with this for two days and I am out of ideas. The device tree entry is: &fdcan1 { // pinctrl-0 = <&fdcan1_rx_pb8 &fdcan1_tx_pb9>; pinctrl-0 = <&fdcan1_rx_pa11 &fdcan1_tx_pa12>; pinctrl-names = "default"; bus-speed = <250000>; bus-speed-data = <250000>; status = "okay"; can-transceiver { max-bitrate = <250000>; }; }; If I uncomment the first pinctrl (pb8 & pb9) I see no output on the TX GPIO pin (PB9). If it is configured as shown, I do see packets on PA12.   Thanks!

Hello ST Community,I’m working on bringing up audio capture using the X-NUCLEO-CCA02M2 microphone expansion board with the NUCLEO-N657X0-Q (STM32N6), and I’m struggling to obtain any audio data.According to the CCA02M2 documentation, the board is compatible with STM32 Nucleo boards via the ST-Morpho connector and supports acquisition through I²S, SPI, DFSDM, or similar digital audio peripherals. However, I have not been able to find any example, tutorial, or application note specifically targeting STM32N6 devices.My goal is to run an Edge Impulse audio model on the STM32N6.I was able to successfully run inference using manually provided raw features from the example in this repository:https://github.com/edgeimpulse/example-standalone-st-stm32n6So the ML pipeline itself is working correctly.My difficulty is specifically with capturing audio from the X-NUCLEO-CCA02M2, due to lack of clear documentation or examples for STM32N6 boards.My setup:• Boards connected pin-to-pin through ST-Morph

Does ST maintain any automated tests for ST development boards and Zephyr?  If so, where may I find more details about the hardware used and test coverage?

Not sure that I have the latest version of the HAL but I used two ip address for the ETH MAC and tried to enable both in the L3 filter.But I could not get any data to the second interface. with the filter turned on-Looking more closely on the HAL_ETHEx_SetL3FilterConfig I found what can only be a copy paste mistake.Writing the destination address for IPv4 was mede to the MACL3A0R1R register instead of the expected: MACL3A1R1RMight be fixed in newer version but using two IP-address perhaps is a bit unusual.  

Hello! Recently I discovered that my program (STM32 TCP client) gets stuck in netconn_connect() function for about 5 minutes if server to which I want to connect to is not available when this function is called. Only after that time program would go intoif ((tcp_rexmit_rto_prepare(pcb) == ERR_OK) || ((pcb->unacked == NULL) && (pcb->unsent != NULL))) {statement (which is present in tcp_slowtmr() function). Once it happens, the debugger shows that:TCP PCB shown in debuggerIt's the tcp_rexmit_rto_prepare(pcb) condition that allows program to go into the if statement. Also, as debugger shows, nrtx is equal to 0, which means there were no retransmissions in the last 5 minutes (rtime=575, which is 287 seconds).Interesting thing is it's possible to "unfreeze" the program way sooner by pinging the client device or by replugging Ethernet cable. netconn_connect() would finally finish and device could try to connect to server once again. By the way, the netconn I used was

Hello, I have a query about how HAL_UART_Receive_DMA and HAL_UARTEx_ReceiveToIdle_DMA work?For my application there is a varying payload size, so I am wondering how would I trigger the HAL_UART_Receive_DMA(&huart3, rx_buffer, 4096, 0xFFFF); interupt? As from my understanding it would be waiting for all 4096 bytes of data which won't arrive unless a different frame was sent.Whereas  HAL_UARTEx_ReceiveToIdle_DMA(&huart3, rx_buffer, 4096); triggers once the serial port stops communicating, however it stores the received data in 512 byte chunks, which has proven difficult to access when generating a LUT from the rx_buffer.If anyone can shed some insight over how these interrupts work? And how to make them applicable for a variable payload would be great.