Ask questions and find answers on STM32Cube packages, including HAL, LL and middleware, and expansion software.
Most recent activity
I am attempting to setup a new Hello World project on the STM32N6 using the following: FreeRTOS running two tasks, a timer, and a semaphore A couple of hardware timers A USART The PSSI doing 16 bit bi-directional transfers The BSP packageRunning the debugger I getfollowed by a Hard Fault:The code is running on a Nucleo-N657XO-Q development board. My development tools are: STMCube 6.18.1 STM32Cube_FW_N6_V1.4.0 IAR 9.60.4Something not correctly setup or a bad board?
Hi, I am developing an I3C target application that responds to I3C private messages from the controller. The application starts by registering the Tx callback.static void I3C_TxCompleteCallback(hal_i3c_handle_t *hi3c); // The callback is registered during initialization hal_status_t status = HAL_I3C_TGT_RegisterTxCpltCallback(hI3C, I3C_TxCompleteCallback); if (status != HAL_OK) { SWD_printf("HAL_I3C_TGT_RegisterTxCpltCallback failed.\n"); return status; }The target responds to the controller: hal_status_t status; hal_i3c_handle_t *hI3C = mx_i3c1_gethandle(); status = HAL_I3C_TGT_Transmit_IT(hI3C, I3C_TxBuffer, 8); if (status != HAL_OK) { SWD_printf("HAL_I3C_TGT_Transmit_IT: %lx\n", status); return status; }The controller receives 8 bytes of data and the data is correct but the TxComplete callback does not trigger on the target side.I placed a breakpoint inside the HAL I3C_Tgt_ISR show below./** * @brief Interrupt Sub-Routine which han
Hi all,I am Jacopo and I am working on a project using STM32U5G9ZJ and I updated to the latest firmware package (STM32Cube_FW_U5_V1.9.0) with STM32CubeMX.I noticed that with the new package the call to HAL_ADC_Start fails to actually start the conversion if used with ADC4. Digging inside the function code I noticed that the call to LL_ADC_REG_StartConversion(hadc->Instance) got moved a couple of lines with respect to the previous version. This means that when the check for ADC4 passes nothing is done, and moving the function call back fixes the problem.Is this a bug? For now I fixed it by manually calling LL_ADC_REG_StartConversion after HAL_ADC_Start, but this is less than ideal.Thank you. Jacopo
Hi I didn’t find any topic or help for the porting of the X-cube-NFC06 to a nucleo 144 f439zi. I’m writting down all the setup I used to achieve this porting with succes, maybe that will help someone one day. IOC configurationsSPI: prescaler 16 (5.25MBits/s) / CPHA 2 edge (info from example and can be found in st25r3916b datasheet) do not enable NSS from cubeMX instead configure PD14 as GPIO_OUTPUT and name it SPI1-CS. IRQ: rising edge / no pull / don’t forget to activate IRQ from NVIC (exti line3 interrupt) *ETH peripheral is using PA7, instead of PA7 I used PB5 as SPI1_MOSI pin. U just have to use a jumper wire to wire up PB5 to D11 (old PA7).Code modificationsAfter generating the code, you should be able to compile without any trouble. If you program the nucleo, you will be facing this : The program isn’t giving any error but, it’s stuck in a infinite “loop”. If you measure with a multimeter btw GND and ST25R_IRQ pin you will constantly have a high lvl (we don’t want this). Here is
Erase sector operation is failing for more than 2 sectorsI have attached the code baseignore trace functionality added for debugging0x20 function code, (Not clear if the call to erase sector are separate or single call)write enable, erase command, wait for Busy bit to be clearedCan someone help to spot the issue
Hello,I have a project that uses I3C to connect a Nucleo-C562RE with an STM32C542CCT6 MCU. The setup was working fine with HAL 2.0.0 but it does not work in 2.1.0. I generated the code with MX2 and I observed that it is identical to the code in the private_it_controller example code. I stepped through the mx_i3c1_init function and I noticed that the moment the GPIO for SDA and SCL are enabled, the I3C clock (SCL) is turned on (visible on the oscilloscope) and does not stop. I don’t see how this could be correct. When I try to start DAA it fails instantly (the error callback is invoked) and the SDA line never changes state (it stays HIGH after reset).Can someone help with this issue?Thank you,Gil
When I was using STM32N6, I tried to generate USART with STM32CubeMx, but when you enable DCache the DMA did not properly handle USART-RX data.The USART startup code is as follows static FIXED_DMA_USER_RAM uint8_t s_ulDebugUsartRxDmaFifo[16]; bool DevUsartInit(void) { bool ret = false; //HAL_UART_DeInit(&huart1); //MX_USART1_UART_Init(); memset(s_ulDebugUsartRxDmaFifo, 0, sizeof(s_ulDebugUsartRxDmaFifo)); if (HAL_UARTEx_ReceiveToIdle_DMA(&huart1, s_ulDebugUsartRxDmaFifo, sizeof(s_ulDebugUsartRxDmaFifo)) == HAL_OK) { ret = true; } __DSB(); return ret;}/** * @brief The application entry point. * @retval int */int main(void){ /* USER CODE BEGIN 1 */ /* USER CODE END 1 */ /* MPU Configuration--------------------------------------------------------*/ MPU_Config(); /* Enable the CPU Cache */ /* Enable I-Cache---------------------------------------------------------*/ SCB_EnableICache(); /* Enable D-Cache--------------------------------------
Hi,I have a bootloader (0x08000000) jumping to an application (0x0800C000) on an STM32H503CB, everything at 32 MHz HSI, VOS3. The bootloader runs at 1WS flash latency, disables the ICACHE and jumps. About 1 boot in 5, the app dies in the NMI handler right after the jump: FLASH_ECCDETR shows a double ECC error on the very flash line being fetched, at a different address every time. The flash content is intact when read back over SWD - the read just fails transiently. It also depends on the chip: 2 of my 3 boards reproduce it, one never does.If I restore the latency to 3WS (the reset value) in the bootloader just before jumping, the problem disappears completely (200+ reset campaigns, zero failure). My question: why is the H5 sensitive to flash wait states in this situation? 1WS at 32 MHz / VOS3 should be enough on paper, and the bootloader itself runs fine with it. Is there something specific about executing uncached from flash right after a bootloader handover that requires more margin
Hi.I'm trying a simple ping application with my board that contains the H743 microcontroller. I am following the instructions in Adam Berlinger's example. But I can't get ping. I connect my computer to my board via ethernet switch. My computer's IP is 192.168.2.5. But it can't reach to my board. When I try to send UDP packet, I can see the Ip adresses of target and destination(via WireShark software). But I can't see the "Hello UDP message!\n\r". IPs are manually setted. H7 board and computer connected via ethernet switch hub. I added a breakpoint to "void ETH_IRQHandler(void)". After the initial power-on, the system reaches the breakpoint twice even when there is no ping command on the Ethernet port. But when i send ping commands, nothing happens. I can reset LAN8742A PHY via GPIO. /* Initialize all configured peripherals */ MX_GPIO_Init(); /* USER CODE BEGIN 2 */ HAL_GPIO_WritePin(ETH_RESET_GPIO_Port, ETH_RESET_Pin, GPIO_PIN_RESET); HAL_Delay(50); HAL_GPIO_WriteP
So I left my program running overnight, and when I check it this morning, the debug output had stopped. Thankfully, the IDE was still running, and it actually caught the hard fault, and even better, the call stack was intact. Here’s what I saw:Call stack showing nested interrupts while running ThreadXSo the IP thread was running, it was waiting on an event flag, another small handler popped, then the Ethernet IRQ popped, and before it could finish execution, the CAN handler popped. The CAN handler checks a queue (with TX_NO_WAIT) for items to transmit, but just before it started executing _tx_queue_receive(), a HardFault occurred.This is the view from inside _txe_queue_receive():_txe_queue_receive() contextAnd this is the view from inside _tx_queue_receive():_tx_queue_receive() contextNow, I’m not sure if perhaps the program counter hadn’t gotten far enough to populate/adjust the stack so that the local variables look correct, but I can see that _txe_queue_receive() definitely had v
Hi, I am using the STM32 NUCLEO-H563ZI board and testing the NetX Duo UDP Echo Server example provided by STM32. Setup: - STM32 NUCLEO-H563ZI- NetX Duo UDP Echo Server example- Direct Ethernet LAN cable connection between PC and board- Static IP configured on both PC and STM32 Issue:UDP communication is not working. When I try to ping the STM32 IP address from the PC, I get "Destination Host Unreachable".Since I am using the official UDP Echo Server example, I expected the board to be reachable and respond to UDP packets.Has anyone successfully tested this example on the NUCLEO-H563ZI? Are there any additional Ethernet, PHY, or NetX Duo configurations that need to be checked? Any suggestions would be appreciated.
i am trying to do HID with costom pcb but i didint find any solution yet
Hello,I am trying to intentionally force a blocking failure on the STM32N6570-DK to observe how the system handles the error and to test the PG10 BootFailed UART output.To do this, I have tried tampering with the FSBL header in various ways to force a failure, as well as simply erasing the OctaFlash.However, despite my attempts, no ID code or valid UART output ever arrives on PG10.While the Boot ROM manual (UM3234) describes what happens during a blocking failure, there are no clear notes or official procedures explaining how a blocking failure can be intentionally generated for testing purposes.Could someone from ST or the community clarify:How can we intentionally and reliably trigger a blocking failure on the STM32N6570-DK to test the PG10 BootFailed UART output?Any guidance or suggestions would be greatly appreciated.Best regards
HiI am trying to make simple setup for H755ZI-Q nucleo-board with ETH + LWIP + RTOS. I was using this Forum Section as the source of example that i used (H745ZI-Q) that is by all documents have same characteristics as my board and compatible with it . So back to the Problem, my board doesn^t respond to ping that i send even when the dhcp server that i started on my PC gives me that the board on this “IP-address” . After what the ping don^t go through. I added a breakpoint to "void ETH_IRQHandler(void)". After the initial power-on, the system reaches the breakpoint three times even when there is no ping command on the Ethernet port. Can u please help me with that?I tried to reconfigure everything from flash memory , turn off the Cache to check if that change anything , I have even Hybrid of RTOS + Raw Api ETH + LWIP that works. I could not understand is smth wrong with my board or with code that generates cause in Documents everything sounded simplier. My Project (Main Files)Example
Hello,I am currently working with the STM32N6 and debugging the boot sequence using the BootROM traces. I am dumping the secure and non-secure RAM ring buffers via STM32CubeProgrammer while the chip is in the Open state (using hotplug).To decode the traces, I am referring to the “official” ST template: Template_BootRom_traces/FSBL/Src/rom_trace_parser.c.However, I have noticed that the BootROM outputs several message IDs that are entirely missing from the switch statement in the romTrace_ParseRecord() function. Because these IDs are omitted from the table, they just get skipped by the C API, making it difficult to fully understand the boot execution flow.My questions are: 1. Is there an updated version of rom_trace_parser.c available that includes a more complete table of these message IDs? 2. Alternatively, is there a reference manual or document that lists all possible BootROM trace message codes and their meanings? Any pointers would be greatly appreciated.Thank you!
I have started a project in stm32g484. I have understood the concept of the HRTIM.i have reviewd the example projects also.I have a question regarding the Configuration of the HRTIM.I am not able to understand on what basis the Compare Unit1,Compare Unit 2,Compare Unit 3,Compare Unit 4 is being filled up.Can anyone please tell me.How to configure and on what basis we should fill the values? Is there any pdf related to the HRTIM configuration.
I have been chasing a very intermitant issue with some STM32L100 based products.The problem shows itself with the MCU being reset by the WDT part way through the initialisation sequence.This issue only displays itself when the MCU has reset itself using NVIC_SystemReset();E.G. the program flow is as followsRunning programNVIC_SystemReset(); is calledMCU resets and goes through the init section in main.cpart way through the init section, it locks up and the wdt resets the mcu. Once it has started to do this, it can stay in this reboot loop until you re-power the MCU OR it can recover after only one reboot. There is no pattern to how it recovers without a power cycleThis does not happen when you power up the mcu, it only happens when the mcu has been reset using NVIC_SystemReset();Plugging in a USB cable into the board and a pc stops the reboot cycle. (no app on the pc needs to be using the usb com port) We have several thousand products in the field and we come across this issue once e
Hello everyone,I'm trying to configure the SAI and GPDMA peripherals on an STM32 to acquire audio from an I2S microphone. My goal is to capture a 32-bit, 2-channel audio stream at a 16 kHz sample rate, with the STM32 acting as the clock master. I've followed the steps below, but I'm running into two main issues:While the HAL_SAI_RxCpltCallback and HAL_SAI_RxHalfCpltCallback functions are being called, the acquisition buffer remains unchanged (full of zeros).I'm seeing a 16 kHz signal on all three I2S lines (SCK, FS, and SD), which is incorrect. The clock (SCK) should be much higher.Here's a summary of the steps I've taken:PLL4 Configuration: I've configured PLL4 to generate a 1.024 MHz clock (16 kHz * 64 = 1.024 MHz). This clock feeds into the IC7 peripheral.GPDMA1 Configuration: I've enabled the clock and interrupts for GPDMA1 Channel 0 and added a linked-list initialization.SAI1 Block B1 Configuration: I've set up the SAI handle for I2S standard, 32-bit data, 16 kHz audio frequency,
Hi.I’m using CubeIDE, CubeMX and HAL to create an application for an STM32L451.I’ve setup USART1 to receive via DMA in circular mode and detect line idle, starting receptions with HAL_UARTEx_ReceiveToIdle_DMA(), and processing receptions in callback HAL_UARTEx_RxEventCallback().All seems to work fine except that the TC (transfer complete, or full buffer) interrupt never happens.HT (half transfer, or half of the buffer reached) and line idle do interrupt.I’m providing HAL_UARTEx_ReceiveToIdle_DMA() a buffer of size 128 bytes. I’m logging the value of the size argument to HAL_UARTEx_RxEventCallback(). When I manually send a message of 20 bytes repeatedly, but slowly enough to ensure line idle triggers, the callback is called with the following size values: 20, 40, 60, 64, 80, 100, 120, 120, 12, 32, 52, 64, 72, 92, 112, 112, 4, 24, (etc).You can see that line idle works, and also that HT is issued in the middle of a reception (size == 64), but TC isn’t, there’s no size equal to 128.What’s
Dear STM32 Advisor, I'll design a system based on Nucleo 64 H533RE. The system will act as USB CDC and USB HID Keyboard at the same time. The idea is when the CDC receive a character, here for example "F" then the Nucleo H533RE will output a high going pulse. And, if the Nucleo H533RE receive falling pulse external interrupt, the the Nucleo H533RE will press the F8 key. As a beginner on STM32, is it possible? Thanks and regards, Fuad Purnomo.
Hello ST Community,We are working with the STM32N657X0H3Q controller and interfacing an S80KS5123GABHB020 HyperRAM using the XSPI1 (Octal SPI) interface. The external HyperRAM is intended to be used as the LTDC frame buffer.We have configured the HyperRAM in memory-mapped mode, and according to our configuration, it should be accessible at the address 0x90000000.However, we are unable to access this memory region. Any read or write operation to 0x90000000 fails. For initial testing, we have configured the XSPI clock to 2 MHz.Our setup is based on the STM32N657-DK board example, and we have followed the same memory-mapped configuration.Could you please let us know if any additional configuration is required to access the HyperRAM at 0x90000000? Specifically, we would like to know:Are there any additional XSPI configurations required for memory-mapped mode? Does the MPU or cache need to be configured for this external memory region? Are there any system, clock, or pin configurations that
I am working with an STM32H743VIT6 and I am trying to migrate an existing bare-metal LVGL + SDMMC + FatFs project to FreeRTOS + LVGL + SDMMC + FatFsIn my previous bare-metal project, the SD card worked correctly.However, after creating a new project using STM32CubeMX with FreeRTOS + SDMMC + FatFs, the FatFs mount operation fails from the beginning.The problem occurs when calling:f_mount(&SDFatFS, SDPath, 1);void LVGL_Task(void *argument) { (void)argument; printf("LVGL Task START\r\n"); FRESULT fres; printf("before f_mount\r\n"); fres = f_mount(&SDFatFS, (TCHAR const *)SDPath, 1); printf("after f_mount, result = %d\r\n", fres); if (fres == FR_OK) { printf("SD success\r\n"); } else { printf("SD fail\r\n"); } printf("before ui_init\r\n"); ui_init(); printf("after ui_init\r\n"); while (1) { uint32_t delay = lv_timer_handler(); if (delay > 1000) delay = 10; osDelay(delay); }} I have placed the buf address in AXI SRAM and confirmed that the addres
Hello,I am using an NUCLEO-N657X0-Q (STM32N657) and developing an application using the FSBL + XIP application structure. Development EnvironmentSTM32CubeIDE: 2.2.0 STM32CubeMX: 6.18.1 STM32CubeProgrammer: 2.22.0 The application is stored in external Flash and executed in XIP mode. I can successfully program the external Flash and enter/run the Appli project through the debugger.The application works normally as long as I do not enable the timer update interrupt.However, when I enable a TIM update interrupt in the Appli project, the application stops working when the interrupt occurs.My project structure is:FSBL └─ Initializes the external Flash and starts the XIP applicationAppli └─ Executed from external Flash └─ TIM update interrupt enabled hereThe timer itself is initialized in the Appli project.The interrupt handler is also located in the Appli project's stm32n6xx_it.c:extern TIM_HandleTypeDef htim1;void TIM1_UP_IRQHandler(void){ HAL_TIM_IRQHandler(&htim1);}and the call
Hello,We are developing a battery-operated GPS asset tracker. To conserve power, the STM32 enters STOP mode every 10 minutes and wakes up via RTC alarm to fetch the current location.Problem:After waking up from STOP mode and toggling the power/enable pin of the GPS module, the GNSS chip takes over 60–90 seconds to re-acquire a 3D fix (Cold Start), which drains the battery significantly. Even when backup power (VBACKUP pin) is maintained to save ephemeris data, warm start is not triggering reliably.Setup:MCU: STM32L4 Low-Power seriesPower Management: WFI / STOP 2 modeIs there a best practice for managing GPIO states and UART lines before entering STOP mode to prevent current leakage into the GPS module's RX/TX pins?Best regards.
I have seen a few other posts about ADC2 calibration issues without resolution. I’m creating this new post to provide a resolution.Using ADC1 and ADC2 in Dual mode on STM32H745 from CM4 running at 240 MHz. 10% of boards in production (20/200) were continuously watchdog resetting. This was traced to the ADC2 calibration getting stuck in a loop for 5 minutes (and hardware watchdog of 4s would trip). At 240 MHz, this timeout loop should only be 2.4s. (It would be better to use a timer function, but this is STM ADC HAL code) /* Wait for calibration completion */ while (LL_ADC_IsCalibrationOnGoing(hadc->Instance) != 0UL) { wait_loop_index++; if (wait_loop_index >= ADC_CALIBRATION_TIMEOUT)I’m not sure what is going on in the H7 silicon that makes the status register read so slow or why it isn’t changing in the expected 2.4s max, but STM provided a work-around. Change the order of initialization to remove the Dual Mode config from the .ioc - generated code in ma
ST Community highlights – April to June 2026
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.