Ask questions and find answers on STM32Cube packages, including HAL, LL and middleware, and expansion software.
Most recent activity
Hello everyone, I have the following use case: I want to receive raw data via Ethernet, which works fine, but I have a problem: When I send 100 bytes, I only receive 14 bytes in my software on the MCU (STM32H7S3L8). I was able to fix this by settingAutomaticPadCRCStrip to DISABLE. Now I receive 104 bytes, which is also not the desired behavior. After a little research, I found out that the 4 bytes are CRC, so I continued searching. After some searching, I found the CRCStripTypePacket property and set it to ENABLE, but unfortunately this property has no effect. What do I need to do to get my 100 bytes but not the CRC? Do I need to set something else? Is this a bug? Please help me, I'm stuck.Thanksstm32h7rsxx-hal-driver 1.2.1Best regards,Paul B
My board does not have the default firmware anymore and I do not have a backup of it either. I have the source code and the HAL driver and have tried for hours to get the code to compile. I get many errors for various HAL header files and the source does not include a HAL config file. Is it possible to get the compiled default firmware as it is for various other Discovery boards?
Hello everyone,I am working on Ethernet communication using the STM32H750B-DK with STM32CubeIDE and LwIP. I am using the onboard LAN8742 Ethernet PHY and a direct Ethernet connection between the PC and the board. LwIP is configured with NO_SYS = 1, and I am continuously calling MX_LWIP_Process() in the main loop. When I check the Ethernet traffic in Wireshark, the PC continuously sends ARP requests asking for the STM32 MAC address, but the STM32 does not send an ARP reply. While debugging the gnetif structure, I see PHYLinkState = 0, speed = 0, and duplex = 0. I also checked the STM32H750B-DK documentation and found that the onboard Ethernet PHY is connected through MII. My CubeMX project was initially configured for RMII, so I changed the Ethernet configuration to MII. I am also checking the Ethernet DMA/LwIP memory configuration and moved the Ethernet descriptor and RX buffer sections to D2 SRAM using the linker script. However, I still cannot get a ping response from the board.Curre
I’m having an issue where I get no output when trying to do PWM with DMA using Timer 3, Channel 1 on an STM32F401RET6.I am using PB4 for my Timer 3, Channel 1 pin.Regular PWM output works perfectly on this channel and pin.But if I try and do DMA transfers, there is no PWM output (voltage stays at 0).I’ve confirmed that I can do PWM DMA on another timer, Timer 2 Channel 1; this works perfectly. But when I switch to Timer 3, Channel 1, there is no output.My timer setup:/* TIM2 init function */void MX_TIM2_Init(void){ /* USER CODE BEGIN TIM2_Init 0 */ /* USER CODE END TIM2_Init 0 */ TIM_ClockConfigTypeDef sClockSourceConfig = {0}; TIM_MasterConfigTypeDef sMasterConfig = {0}; TIM_OC_InitTypeDef sConfigOC = {0}; /* USER CODE BEGIN TIM2_Init 1 */ /* USER CODE END TIM2_Init 1 */ htim2.Instance = TIM2; htim2.Init.Prescaler = 0; htim2.Init.CounterMode = TIM_COUNTERMODE_UP; htim2.Init.Period = 90-1; htim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; htim2.Init.AutoReloadPreload = TI
I’m trying to set up flashing firmware and initializing the RTC clock on a blank or chip erased STM32H747Xi using the STM32Cube CLT package that contains the STM32_Programmer_CLI.exe command line tool. I can’t seem to write to the critical registers for RTC. Is there a procedure to set the RTC? If so, can you list the steps needed to do so?Thanks,Johnas
Hi there, I tried to build NetXDuo stack with IPV6 and SLAAC version on H563ZI Nucleo boardHowever compilation of system libraries failed due to not linked symbols, it happened in all 3 ways of generations form CubeMX (copy all files, copy only required files, reference libraries).I.e. linker complained about lack of symbol _nx_nd_cache_add_entry and I noted filed is nx_nd_cache_add_entry.c is not compiled nor copied to project sources.
Hello,We are currently working on STM32C542CCT6 from the STM32C5 series and developing custom Flash and Data Flash drivers.Issue 1 – Hard Fault when accessing FLASH_SIZEWhile executing code generated by STM32Cube, the following check causes the system to enter the Hard Fault handler:if (FLASH_ADDR < (FLASH_BASE + FLASH_SIZE)) /* Main User Flash */The FLASH_SIZE macro reads the value from the device information area. However, when the code attempts to access FLASH_SIZE, the system immediately enters the Hard Fault handler.If we manually hardcode the flash size value, the code works correctly.Our questions are:Is there any specific register configuration or initialization required before accessing FLASH_SIZE on this device?Is this region restricted due to Trust Zone or privileged access on STM32C5 devices?Issue 2 – NMI when reading Data FlashWe have enabled Data Flash by setting: EDATA_EN = 1We are trying to read from the Data Flash base address:0x09000000using a pointer-bas
Greetings,I am working with nucleo_c5a3zg board and I am using zephyr RTOS for my project. I wanted to interface the sd card and try to do some data logging. I had a adafruit data logger shield which can fit on nucleo_c5a3zg board and there is a shield support in zephyr. When i build and uploaded the code i am getting a error that CMD8 is not supported. During debugging i found out that there is no state change on MISO line. Just to check if my code is wrong i tried same code with nucleo_f446re board and it works fine.Following is the capture from saleae loggic for necleo_c5a3zg board. I can provide other details like code, .dts file, etc.If someone can help me solve this issue it would be much appreciated.
I am working on stm32 C5A3ZG platform for one of my projects. I want to use SD card for data logging. I have working SD card module. I tried to use it with nucleo_c5a3zg board using zephyr RTOS and there infrastructure of file management that code is not working on this C5 controller which uses HAL2 driver. It works on other STM32 controllers which use HAL driver.I tried to create a project in STM32CubeMX2 but couldn’t find configuration for SDMMC over SPI which would be required to interface SD card.I checked in STM example library https://dev.st.com/stm32-example-library/result?filters=N4IgpgHghgtgDgGzAOVmEAuA2gXQDQgwDGArpliAMoAqAsgMwBMAwgKwj4gBGA9lAE4ATcpxgBLQYKQB3AemyjSAEX5iAbmH4iCvAYIAKUIgGsoAc3m4Cg1Rv7UAnnEs4AvkA but was not able to find any sample or SD card.Can someone provide a sample code to me otherwise i have to look for potentially changing the platform and move to some other controller.
Hello,I am facing some issues with NetXDuo, where i see traffic on the RGMII RX lines, but RX DMA does not process any frames / no interrupts fire. I have the following setup:I am using a custom board based on the STM32N657 with an ADIN1300 Gigabit Ethernet PHY connected over RGMII.Software stack:STM32Cube FW_N6 V1.3.0 ThreadX NetXDuo Static IPv4 configuration Secure only application Caches disabledThe PHY is configured over MDIO and link comes up successfully. The resolved PHY speed matches with what is seen on the host side and with the MAC speed configuration.What is working:The PHY side appears to be working correctly. For example, when forcing 10Mbps, i can clearly probe the RGMII lines and see:RX_CLK present RX_CTL activiy for each incoming ARP/ping RXD0..3 activity during the frameThis confirms that Ethernet frames are being received by the PHY and forwarded onto the RGMII interface toward the MCU.The following have also been checked/tried:RGMII pin mux tried disabling broadcast
in “usbd_msc_scsi.c” at function “SCSI_ModeSense6”/* Check If media is write-protected */ if (((USBD_StorageTypeDef *)pdev->pUserData[pdev->classId])->IsWriteProtected(lun) != 0) { MSC_Mode_Sense6_data[2] |= (0x1U << 7); /* Set the WP (write protection) bit */ } else { MSC_Mode_Sense10_data[2] &= ~(0x1U << 7); /* Clear the WP (write protection) bit */ }is writing to the wrong place !!! Change it to:MSC_Mode_Sense6_data[2] &= ~(0x1U << 7); /* Clear the WP (write protection) bit */Note:The wrong write mainly cause the write protection to stay on if its once set and never be able to unset without reseting the scsi device.Took me days to track down this bug !! best regards,Labmaster
Environment - Device: STM32H562ZI- Reference manual: RM0481 Rev 5- HAL: STM32Cube H5 HAL Driver V1.5.0- Peripherals: GPDMA used for SPI slave Tx/Rx. SPI in slave mode, normal (non-circular) transfers, no linked-list. Summary On our SPI slave DMA path, the DMA channel becomes permanently stuck after an SPI error, and SPI communication never recovers until the device is power-cycled. The cause is that `GPDMA_CxCR.SUSP` gets written to a channel that has **already completed its transfer and stopped** (EN=0, IDLEF=1). In that state `GPDMA_CxSR.SUSPF` is never set, so `GPDMA_CxCR.RESET` is never written and **SUSP stays set**. Setting `EN=1` afterwards suspends the channel immediately after start, and the driver can no longer escape that state. Observed register sequence (Tx channel, real measurements) ```1) Block transfer completes. Hardware clears EN.CxCR = 0x00805D00 (EN=0, SUSP=0, SUSPIE=0)CxSR = 0x00000001 (IDLEF=1) 2) An SPI error occurs right after this point.SPI ErrorCode = 0x84 (UD
Hello,I am debugging SPI3 communication between two STM32H755 boards: UC1 = SPI master UC2 = SPI slave SPI3, full-duplex DMA used for TX/RX FreeRTOS STM32H755 The problem is that the first SPI transaction can be completed correctly, but the following transaction does not behave as expected.Before starting the SPI data exchange, I also perform a handshake/synchronization sequence between the two boards to ensure that both sides are ready. The handshake itself is implemented before the SPI test, but adding this synchronization does not resolve the issue.The intended sequence is:UC1 (Master) UC2 (Slave)SYNC ----------------> receive SYNC <---------------- OKPING ----------------> receive PING <---------------- PONGPING ----------------> receive PING <---------------- PONGIn the actual test, the first exchange can be received correctly, but the slave does not continue responding correctly on
Hello,I am using an STM32H7S3 with STM32CubeH7RS HAL [V1.2.1]. SPI5 drives a display over 3-wire SPI with 9-bit frames (the 9th bit carries D/C).With USE_FULL_ASSERT enabled, HAL_SPI_Init() triggers an assert in stm32h7rsxx_hal_spi.c (line 259 in the current GitHub version):if (IS_SPI_LIMITED_INSTANCE(hspi->Instance)){ assert_param(IS_SPI_LIMITED_DATASIZE(hspi->Init.DataSize)); assert_param(IS_SPI_LIMITED_FIFOTHRESHOLD(hspi->Init.FifoThreshold));}In stm32h7rsxx_hal_spi.h, the macro only accepts 8-bit and 16-bit:#define IS_SPI_LIMITED_DATASIZE(DATASIZE) (((DATASIZE) == SPI_DATASIZE_16BIT) || \ ((DATASIZE) == SPI_DATASIZE_8BIT))However:1. RM0477 [rev 10], section 55.3, Table 578 states that for SPI4 and SPI5 the data and CRC size is "configurable from 4 to 16 bits".2. The HAL itself is inconsistent. A few lines below the assert, the runtime check in HAL_SPI_Init() only rejects sizes above 16 bits for limited instances:if ((IS_SPI_LIM
I am using an STM32H755, and attempting to send 35 bytes of data over SPI.The data is copied into the TXDR, one byte at a time, but then only the first two bytes are send. The TSIZE is set to 35 and the CTSIZE counts down from 35 to 33, and then the TXDR bit goes high and no further data is sent. Could anyone suggest any reason why this may be happenning? Thanks
Hello,RM0431, section 8.3.18, contains the following warning:"To switch off a peripheral connected to a DMA stream request, it is mandatory to, first, switch off the DMA stream to which the peripheral is connected, then to wait for EN bit = 0. Only then can the peripheral be safely disabled." However, HAL_ADC_Stop_DMA() in the STM32F7xx HAL driver v1.3.3 (stm32f7xx_hal_adc.c) uses the opposite order:1. Line 1526: __HAL_ADC_DISABLE(hadc);2. Line 1532: hadc->Instance->CR2 &= ~ADC_CR2_DMA;3. Line 1538: tmp_hal_status = HAL_DMA_Abort(hadc->DMA_Handle);Could you clarify which sequence should be used?
I have been writing some code to recover from the NMI after reading unwritten OTP addresses but I found a bit of a snag when checking that the Address listed in FLASH_ECCDETR is what I would expect after a read.The Table 42 of the H503 reference manual (RM0492 Rev 2) lists a minimum ADDR_ECC offset of 0x0600. I was a little unsure what exactly this meant but `HAL_FLASHEx_GetEccInfo()` clearly runs:// FLASH_ADDRESS_OFFSET_OTP is defined as 0x600 as you would expect herepData->Address = (FLASH_OTP_BASE + ((addr_reg - FLASH_ADDRESS_OFFSET_OTP) * 4U)) & 0xFFFFFFFFU;Seems simple enough then - the number is just which OTP word triggered the error minus 0x600.Except the actual offset I am seeing in the address field is 0x200 instead of 0x600.Reading an unwritten OTP at 0x08FFF010 gives me an ADDR_ECC of 0x204, reading 0x08FFF020 gives me 0x208, and so on...Is this an error in the Reference Manual and HAL? Should the listed value be 0x200 or am I missing something here? Thanks!
On STM32H733, the HAL provides __HAL_DBGMCU_FREEZE_FDCAN() in stm32h7xx_hal.h but it is conditionally compiled:#if defined(DBGMCU_APB1HFZ1_DBG_FDCAN)#define __HAL_DBGMCU_FREEZE_FDCAN() (DBGMCU->APB1HFZ1 |= (DBGMCU_APB1HFZ1_DBG_FDCAN))#endifDBGMCU_APB1HFZ1_DBG_FDCAN is not defined in stm32h733xx.h, so the macro does not exist at compile time and calling it gives:error: implicit declaration of function '__HAL_DBGMCU_FREEZE_FDCAN'Questions:Is FDCAN freeze during debug halt supported on STM32H733? If yes, why is DBGMCU_APB1HFZ1_DBG_FDCAN missing from stm32h733xx.h — is this a bug in the device header? What is the correct bit position to use as a workaround via direct register write? I need to pause the FDCAN peripheral during debugging, that is my goal. Thanks you very much for helping me out.
I configured ADC1 to be triggered by TIM2_CH2 and TIM2 compare channel 2 on STM32F429 with CubeMX, and enabled their interrupt, TIM2 CC2 ISR was run but ADC EOC ISR not run. I tested both by LED and by debug in CubeIDE, both results were the same. When debug in CubeIDE, after TIM2 CC2 ISR was run, STRT=0 and EOC=0 in ADC1 SR, which indicated that ADC1 was not triggered. However, if I configured ADC1 to be triggered by TIM2_TRGO and TIM2 trigger output from Update event, ADC1 was triggered.My settings in CubeMX:CubeMX and CubeIDE project files:
I'm working on an STM32H743-based project driving a parallel LCD through LTDC, with the framebuffer sitting in external SDRAM via FMC. I keep running into intermittent display corruption that I suspect is cache-related, since the M7 core has D-Cache enabled by default.What's the recommended approach for setting up the MPU region for the framebuffer — mark the whole SDRAM region as non-cacheable, or is it better to keep caching enabled and handle cache maintenance manually (SCB_CleanDCache_by_Addr) around framebuffer writes? Curious what's worked best for people running LTDC + SDRAM at higher resolutions/refresh rates without a performance hit.
Hi all, i have very simple gpio pushbutton debounce code, but 50% of the time it still gets a double-bounce (led toggles twice), i.e. the debounceCount is double incremented as the interrupt service routine is mysteriously called twice. How can this be if the interrupt is immediately disabled?. Is the switch bounce sometimes so quick that two presses are queued up before the interrupt is disabled?Within main() , if the button is pressed, there is a while(1) if(butIsPressed) {butIsPressed=FALSE; HAL_Delay(1000); and then HAL_NVIC_EnableIRQ(EXTI4_15_IRQn);}void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin){HAL_NVIC_DisableIRQ(EXTI4_15_IRQn);debounceCount++;HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_3); // Toggle The Output (LED) PinbutIsPressed = TRUE;}
Hi all,I am using the VENC H.264 encoder (Middlewares/Third_Party/VideoEncoder from the STM32 model zoo object detection application) on the STM32N6570-DK Discovery Kit with the IMX335 camera. The encoder is fed RGB565 frames from DCMIPP (1280x720 buffer in external PSRAM), and the output goes to a PSRAM buffer.Problem:H264EncInit, H264EncSetPreProcessing, H264EncSetRateCtrl and H264EncStrmStart all return OK. The first H264EncStrmEncode call (intra frame) then returns -17 (H264ENC_FUSE_ERROR). In the driver, this is raised when the VENC status register has ASIC_STATUS_FUSE (0x200) set. The register description in encswhwregisters.h says: "IRQ stream format fuse status bit. Format disabled by fuse."After that, later frames often fail with -7 (INVALID_STATUS), then -14 (INSTANCE_ERROR), sometimes -3 (INVALID_ARGUMENT) or -16 (HW_RESET). At times the encoder recovers after frame 0 and produces a stream; at other times it never does. The behaviour is not consistent between runs, even at 6
Where can I find STM32H5F5J-DK demonstration firmware full source code?
Hi,On STM32U575CGU3, I see a reproducible +200 µA increase in current after calling MX_ADC1_Init() once. Even after HAL_ADC_DeInit(), ADC reset, and disabling VddA, the additional current does not return to the original baseline.Here is the minimal code:cint main(void){ HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_GPDMA1_Init(); MX_ADC1_Init(); // +200uA increase MX_OCTOSPI1_Init(); MX_SPI1_Init(); MX_USB_OTG_FS_PCD_Init(); MX_USART1_UART_Init(); MX_ICACHE_Init(); // ADC Disable HAL_ADC_DeInit(&hadc1); __HAL_RCC_ADC1_FORCE_RESET(); __HAL_RCC_ADC1_RELEASE_RESET(); HAL_PWREx_DisableVddA(); while (1) { __NOP(); }}Questions Has anyone observed similar behavior on U5 devices (ADC bias or VREFBUF staying active after initialization)? Are there known conditions where ADC/VREFBUF analog blocks remain powered even after DeInit and VddA OFF? Any hints on additional steps required to fully shut down the analog domai
Hello everyone,I used to work with U5 family microcontrollers. Recently I migrate to C5 families, and to MX2 UI.When I wanted to create interruptions for DMA UART events, normally I worked with RxEventCallback (classic). However, seems I´m not capable to find this same __weak function anywhere inside the hal_uart.c file. Am I missing something? I´m working with STM32C562R mcu, in CubeIDE 2.2Thank you everyone.
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.