Join conversations with your peers and ST experts. Explore the full potential of STM32 microcontrollers for your embedded design.
Most recent activity
I am using ADC + DMA + USART1 + Timer in STM32 IDE in a setup consisting of:Motor → Sensors → MCU (STM32N6) → PCI am capturing the signal received at the serial port using NanoEdge AI. I have shared screenshots of:The actual current waveform observed on the oscilloscopeThe data received through the STM32N6 MCUMy doubt is:Is there anything inside the MCU or ADC that could suppress or distort the natural sinusoidal shape of the current waveform?Note:I have converted ADC values to actual current values using a 3.3V reference.I have removed the sensor bias.I have properly accounted for sensor gain.I would like to confirm whether the MCU/ADC processing could be affecting the waveform shapeEdited to place the images in the post:
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
OTP portion of FLASH is a valuable asset in some STM32 families and represents a convenient place to store things like security keys. For this, it is desirable - and, as it's part of FLASH, also quite logically expected - that setting read-out protection to any level above 1 prevents the debugger from reading it.In RM0444 Rev.5 and RM0454 Rev.5 (the current 'G0 manuals), the following text indicates that this should be the case:The following table appears to indicate the same behaviour:However, user @DAlbe.3 reported, that he was able to read out OTP using debugger, while RDP was set to Level1.This, together with the fact, that the above table has changed across RM revisions, rises questions about the OTP's security.Can ST please comment? Thanks,JW
I am using STM32H563 and using seven pins to read data, all through ADC1 with GPDMA1 Channel0 -2 Words internal FIFO. I connected all seven pins to ground, expecting to get all zeros or values close to zero, but the readings seem to fluctuate randomly.Although the ADC values do increase when connected to Vcc (>3000) and decrease when connected to ground (<2000), how can I ensure that the readings are correct? Are there any settings that I should adjust?uint16_t adcbuf[7] = {0}; HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED); HAL_ADC_Start_DMA(&hadc1, (uint32_t *)adcbuf, 7); while(1) { printf("ADCBUF: "); for (int i = 0; i < 7; i++) { printf("%d, ", adcbuf[i]); } printf("\r\n"); HAL_Delay(1000); } Below is the ADC1 configuration from my .ioc file. (All ranks are configured identically, except for the channel.) Below is the GPDMA1 configuration. (Use Standard Request Mode)
Heyho,the title says it...In RM0486, 14.6.5 PLL description, page 437 / 438 I find this:Using the PLLs in fractional modePLL off ... set FRAC ... PLL onCaution: Do not update DIVN and DIVNFRAC after the PLL has been enabled.On the other hand, there are comments that some dividers can be changed on the fly.So maybe it might work? Has anybody tried? With these 4 PLLs and the great clock routing possibilities, the ability to change FRAC values on the fly with this high resolution would be a fantastic feature for synchronization, without using an external VCO.
Does anyone know what settings are needed to check the internal flash memory using the STL library? I wrote a small test firmware (for a 61508 safety application without TZ) using the STL library, which is supposed to perform a self-test flash memory check.However, this test always fails. I ran the checksum check using STM32CubeProgrammer v2.20.0. I had to manually enter the settings for FlashStart, FlashEnd, and FlashSectionSize (0x08000000 0x0800E000 0x00010000) because the macros from the readme file didn't work. The STM32CubeProgrammer then reports: CRCs area injected successfully. After loading the modified ELF file, the STM32CubeProgrammer displays: Number of segments: 2segment[0]: address= 0x8000000, Size = 0xC314segment[1]: address= 0x800E000, Size = 0x2000 But what settings should be specified to perform the flash test?Unfortunately, this information is not available in the manual or the STL documentation. I've already tried the following unsuccessf
Hello, I made a board with an STM32F103C8T6 which uses USB.My issue is that when conecting USB (self powered or with external power) I get the following error on windows:Windows has stopped this device because it has reported problems. (Code 43) A request for the USB device descriptor failed.Things I checked:- When no USB is connected, the D+ line is pulled to 3v3, but when connecting the USB it goes down to 2.8 with 0.5v being on the resistor.- Checked continuity from USB header to A11 and A12 pins (when unpowered)- Resolder pins to ensure propper contact (Except FL1, I checked that everything else is proppery soldered, but I guess continuity is a good proxy test)- Changed MCU, USB header and FL1 for new ones in case they got damaged- Firmware was tested with a bluepill and everything worked.It's been a week with this issue, if someone know what could be happening or could give me tips to help diagnose this I'd appreciate it.Here are the schematics for that part of the board: &n
I am struggling with an intermittent boot issue with Nucleo STM32L432. What happens: When the board boots up from VIN of 7V, sometimes (I would say 50% of the time) STM32 struggles to run the code, it's almost like it stuck during the boot up. When i power it up from USB to check what is the issue, problem goes away and board is running fine. My application involves ~40 of these boards and i am seeing this issue in 5 boards and it happens 50% of the time in those 5 boards. Only mods i have done to the nucleo board are - 1) I have taken a suggestion made in this post: Solved: STM32L432 Nucleo-32 External Power - STMicroelectronics Community i.e. to remove SB9 to be able to power it from VIN of 7V. 2) Connected a solder bridge at SB17 for HSC Anyone faced this issue or any troubleshoot tips anyone can share. Thanks in Advance
Hi everyone, I'm looking for a way to be able to encrypt my flash on stm32g030. How do I do it? Thanks
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
Hi,Can the equivalent gate count for the STM32H750VB be provided for reliability research?Thanks
Hi,I selected STM32H7A3ZIT6Q to use external SDRAM. However, in STM32CubeIDE under Connectivity → FMC, the SDRAM option is not available.When I select STM32H7A3ZIT6 (non-Q), the SDRAM option appears.Does the STM32H7A3ZIT6Q support SDRAM, or is this a CubeIDE limitation?Thanks.
..
Hello everyone,I'm trying to disable the TrustZone (TZEN bit) on an STM32L562E-DK development board to leave it in a completely clean state (without protections) so I can use it as a standard MCU. However, I'm encountering errors when trying to modify the Option Bytes with STM32CubeProgrammer, and I would appreciate your help.My configuration:Board: STM32L562E-DKSoftware: STM32CubeProgrammer v2.21.0Connection: Integrated ST-LINK (SWD at 8000 kHz)Current Option Bytes status (initial read):TZEN = 0x1 (Trust Zone enabled)RDP = 0xAA (Level 0, no readout protection)SECWM1_PSTRT = 0x0, SECWM1_PEND = 0x7F (Safe area defined)Screenshots of the complete configuration are attached.The problem:From the STM32CubeProgrammer graphical interface, I can modify and apply changes to almost all Option Bytes (such as safe areas or write protection) without issue. However, when I try to uncheck the TZEN box (to set it to 0) and click "Apply," I get the following errors:Error: Option Byte Programming failed
I'm using an STM32F469I-DISCO ($AU1) board that I've used for a few little projects and have come to try to prototype something using it's MEMS digital microphones (MP34DT01-M). In the documentation for the discovery board it lists the connections of these microphones to the DFSDM peripheral pins of the MCU, however looking in the datasheet of the F469 it doesn't list the DFSDM peripheral anywhere and on pages that discuss the DFSDM peripheral the F469 is not listed as an MCU with DFSDM compatibility. Furthermore, on the CubeMX example project for the F469I-DISCO the pins connected to the MEMS microphones are configured with the SAI peripheral.Is this a documentation issue for the discovery board or are there extra steps I need to take to use the DFSDM peripheral? Thanks for any help anyone can provide.
Hey guys,I am searching for RoHS/REACH records for STM32G431KBU3/STM32G431KBU6 but they're only accessible for one of the STM32G431 parts.Any of you have any pointers to how I may else obtain such documentation?
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)
Hello, after some time trying to debug the PA2 pin on my Nucleo H503 I realized, by looking at the board, that PA2 goes into SB7 and SB1. Reading the manual it seems like both SB1 and SB7 must be off for USB Device to work, however, this will disable PA2 and doesn't seem to be documented in the manual for the H503 board (while there are some explicit SB configs for PA2 on the H533 board). Am I missing something?
SYS CONFIG =========================================== IO Supplys = 3,3V, VCORE = 2,5V regulator used, FSystem = 200 MHz Timer1 is configured for Output Compare CH1, sig 0.1MHz 50% duty expected (all necessary clk enabled) Compare SIG is routed to PK1 via alternate conf __HAL_RCC_GPIOK_CLK_ENABLE(); GPIO_InitStruct.Pin = GPIO_PIN_1; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; GPIO_InitStruct.Alternate = GPIO_AF1_TIM1; HAL_GPIO_Init(GPIOK, &GPIO_InitStruct); After exec of this routine, PK1(J15) pin is in floating mode (1V because of 2Meg external pull-up to supply) . Same signal routed to another port/same load with same routine is working properly Same problem and behavior with TIM8 witch can use the same PK1 pin Note1 : if internal pull-up or pulldown added to pin conf, the pin is no longer floating, Hi(3,3V) for pull-up, Low(0,1V) for pulldown but still no signal output (input mode suppose
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
Hello everyone. I am trying to build an i2c multi-drop network with STM32C0316CT6 targets. To achieve that i use the differential buffer PCA9615. Each target (and the master of course) has its own PCA9615, the topology is as shown in the picture below. My problem is that when clock stretch is enabled (default) and master pulls the clock low, then the target pulls the clock also low for a tiny amount of time during the normal pulse duration. PCA9615 i2c a-side (non-differential) sets the SCL (a-side) low to ~0.3V (as expected) and then the target pulls the SCL to 0V for that tiny amount of time. For that tiny amount of time, the master and the target are both holding the clock low. That results in an extra voltage offset on the differential side of the buffer. On the multi-drop network, all targets do the same and the differential voltage offset is multiplied and gets huge. The expected behaviour would be from the target to pull the line low only in the stretched pulse and not on
This example work perfectly using non interrupt driven UART HAL library, HAL_UART_Receive and HAL_UART_TransmitAny idea on changing to HAL_UART_Receive_IT and HAL_UART_Transmit_IT?Many thanks https://forum.digikey.com/t/easily-use-scanf-on-stm32/21103
Hi,I am making updates to a custom PCB where I would like to add ADC functionality. My board is powered by batteries and I expect the supply voltage to fluctuate slightly and I need the ADC conversions to be accurate. The reference manual says I can use the internal Vrefint to calculate what the value of VDDA/VREF+ so that I may calculate my conversions with better accuracy. Additionally, I wanted to follow this guide (https://community.st.com/t5/stm32-mcus/how-to-use-the-stm32-adc-s-internal-reference-voltage/ta-p/621425) to understand how I may implement this in firmware.The issue I see now is that on the chip's datasheet it mentions that Vrefint is internally connected to ADC1_IN0, however, ADC1_IN0 has no pinout on this package of the chip. Furthermore, in STM32CubeMX the ADC1_IN0 channel is not able to be selected (although Vrefint channel is able to be selected).Now I have some confusion since the datasheet mentions the internal connection. Maybe this package does not have this a
ST Community highlights – April to June 2026
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.