No best answer

Hello, We are trying to implement ECDSA where cloud generates Public and Private key and calculates hash of our firmware using SHA 256 and Sign the firmware using P256 method. I am using ECDSA API to verify the firmware in our bootloader I am facing some issues in verification I am using all the things based on example project prime256v1.c file for constantsuint32_t verify_firmware_signature_P256( const uint8_t* hash ){  PKA_ECDSAVerifInTypeDef in = {0};   in.primeOrderSize  = 32U;            // 256 bits = 32 bytes  in.modulusSize   = 32U;            // 256 bits = 32 bytes  in.coefSign     = 1U;             // 1 indicates a is negative (-3)  in.coef       = prime256v1_absA;      // Coefficient |a| = 3  in.modulus     = prime256v1_Prime;      // Prime p  in.basePointX    = prime256v1_GeneratorX;   // Generator Gx  in.basePointY    = prime256v1_GeneratorY;   // Generator Gy  in.primeOrder    = prime256v1_Order;      // Curve order n  in.pPubKeyCurvePtX = pub_x;           // Public key X 

Respected Sir/ Mam,Can you please tell me the maximum current for all peripharals enable in sleep mode for stm32U5G9, along with the dedicated settings mode.Thankyou

Hello,We are investigating a recurring failure of an L7983 used in a medical device.Application:VIN ≈ 40 V VOUT = 5 V L = 68 µH Cout = 2.2 µF LCM mode Very light load conditions possibleFailure mode:5 V output lost. After removing the output inductor, LX remains shorted to GND. Resistance LX-GND ≈ 2.5 Ω. High-side MOSFET appears intact (no abnormal resistance between VIN and LX). Failure seems limited to the internal low-side MOSFET.Field observations:The failure is always preceded by a battery-related error. Batteries are often found degraded or unable to charge correctly. Similar failures have also occurred during production.Tests performed:Startup without battery. Startup with low battery conditions. Long-duration operation with low battery voltage. Heavy battery discharge during operation. Various startup sequences.No test has reproduced the failure so far.Measurements:LX peak ≈ 50 V. Undershoot down to approximately -1.7V No obvious overcurrent event detected.Questions:Have you se

Hello,I have successfully implemented the High Sensitivity Observer using the following configuration:MCU: STM32G474RETx, 170 MHz Power board: EVLDRIVE102BH, configured as a Custom Power Board in STM32 Motor Control Workbench Phase-voltage sensing configured according to the HSO hardware requirementsHSO is operational with this configuration. However, I am observing rotor alignment movement and vibration during startup, before stable closed-loop operation is established.Could you please clarify the expected HSO startup behavior?What startup stages are performed before the HSO reaches stable closed-loop operation? What is the expected extent of rotor movement during the initial alignment and observer-lock sequence? Is some vibration or oscillatory rotor movement expected during this stage? How does the selected startup method, such as PolPulse or RSDC, influence rotor displacement and vibration? How significantly do the motor parameters, mechanical load, inertia, friction, and initial r

 SummaryWe program a slave STM32H757 through its system bootloader over SPI (AN4286), driven by a second STM32H757 acting as SPI master. About 20 % of our production boards cannot be programmed: after the 0x5A synchronization byte, the bootloader returns the byte 0xA5 on every poll and never 0x79 (ACK) or 0x1F (NACK). The other 80 % of the boards are programmed reliably with exactly the same master firmware.Bootloader version (0x91), device ID (0x450) and silicon revision (Rev V) are identical on working and failing boards. The failing boards are otherwise fully functional: firmware loaded through JTAG/SWD runs normally on them. Register dumps taken through SWD show that the bootloader has selected SPI2 and is running, but that the SPI2 slave is in TX underrun (SR.UDR = 1) on failing boards and not on working boards. Hardware configurationItem Value Slave device STM32H757XI , device ID 0x450, Rev V, bootloader V9.1 (0x91) (identical on working and failing boards) Slave clock 25

Hello everyone,I am having an issue with EEPROM Emulation initialization in my STM32 project.I am currently trying to implement the EEPROM Emulation utility using STM32CubeMX2 v1.1.0.The program starts with mx_system_init(), which initializes the peripherals and other required modules such as FLASH, RCC, etc. After that, I call mx_eeprom_emulation_init(). During this initialization, the MCU enters a HardFault.Detailed informationThe call hierarchy is:main() → mx_eeprom_emulation_init() → EE_Init() → EE_FLITF_Init() → Page_GetState() → EE_ITF_FLASH_ReadData()Inside EE_ITF_FLASH_ReadData(), the code tries to access address:0x09000018and immediately enters a HardFault.I also analyzed the fault using the Fault Analyzer in STM32CubeProgrammer. The results are:SCB_BFAR: 0x09000018 BusFault: Precise data access error (PRECISERR) The BusFault is escalated to a HardFault (FORCED)I also checked the EDATA_EN option bit in STM32CubeProgrammer, and it appears to be enabled correctly.At this point,

Hi,I am working on flash memory protection mechanisms on STM32 microcontrollers (specifically STM32L476RG) and I have two closely related questions that I want to confirm at the hardware level.I understand that:RDP (Readout Protection) levels are stored in the Option Bytes The Option Byte Loader (OBL) reads these values at every power-on reset, before any user code executes Under RDP1, external debugger access to flash is blocked but the CPU can still read its own flash normally Under RDP2, the debug port itself is permanently disabledMy question is: what specific hardware block is actually responsible for enforcing this protection? and blocking the read request to secure flash region ?Specifically I want to confirm:Is this enforcement done purely in silicon/hardware, with no software component involved? Under RDP1, why does the CPU running normal user code still get real flash data, while an external SWD/JTAG debugger gets blocked — is this distinction made by the flash controller its

Background info:I am looking at ditching Microchip and moving to STM32 H5 or H7.My application requires networking and support for HTTP server, SNTP client, SNMP V2 & V3 agent and SMTP client with TLS etcI am looking at H5/H7 primarily because of the larger RAM to support a TFT display of 320x240 or possibly 480x320. I only need 16 bit color.  Now the question:I am evaluating my choices for a TCP/IP stack. The “free” contenders appear to be LWIP and Azure (NetX) and I have seen some not free offerings such as CyloneTCP and Mongoose.I suspect that any of them can be made to work with enough effort but in the interest of not wasting company resources I thought it prudent to see who has had successes and frustrations with the offerings that I have been exploring.Yes. I am the guy who asks how deep the water is before I jump in….   

I am using an LSM6DSV320X (STEVAL-MKI251A) read over SPI.Settings: high-performance mode, ODR 1.92 kHz, gyroscope ±4000 dps, LPF1 off, low-g ±16 g, high-g ±320 g, BDU = 1.Problem: after a sharp mechanical shock the gyroscope X and Y outputs become noise swinging up to ±4000 dps from one sample to the next. It lasts from 60 ms to 1.7 s and then stops abruptly, as shown in the first picture. The shock is along Z, about 250 g for about 2 ms.- Y is always affected, X nearly always, Z hardly at all.- Both accelerometers and the temperature output are normal during it. All FIFO tags are valid and no samples are lost. Also, here is a comparison of an ISM330DHCX with the same strikes; only small gyro ringing is observed.What is the issue, and is the new LSM6DSK320X immune to this? 

I’m using the OEMiROT_Boot example with the OEMiROT_Appli_TrustZone secure and non-secure example applications.I can build the code and correctly provision the NUCLEO-H563ZI board. The applications run correctly and I can attach to the secure and non-secure applications using the debugger. If I use regression to return the board to the OPEN state, I am not able to debug the applications by downloading the code from the debugger. When I try, I receive HardFault when the secure app tries to switch to the non-secure app. I have followed the directions in application note “AN5421” when configuring the secure and non--secure projects. I’m using V9.70.4 of the IAR Embedded Workspace. Using the debugger, I can see the correct code in the secure and non-secure addresses.Below is the debug log.Thu Oct 01, 2026 16:20:47: IAR Embedded Workbench 9.70.4 (C:\iar\ewarm-9.70.4\arm\bin\armproc.dll)Thu Oct 01, 2026 16:20:47: Loaded macro file: C:\iar\ewarm-9.70.4\arm/config/debugger/ST/STM32H5xx.dmacThu

Hello,I’m working with a NUCLEO-N657X0-Q board and trying to run inference using the ST Edge AI embedded client API. The STM32CubeIDE project I’m using was generated with CubeAI Studio. Input, output, weights and activations buffers are preallocated. Here are the advanced settings I used in CubeAI Studio: Even though the validation with CubeAI Studio was successful, I edited the app_x-cube-ai.c file in order to validate my samples again so that I know I’m feeding data into the network and obtaining the outputs correctly. This is were I noticed that the prediction of every single sample is incorrect. Since I got over 98% accuracy with CubeAI Studio, I assume I’m doing something wrong in my code. Unfortunately, I can’t really figure out what it is. I only made a few minor changes to the app_x-cube-ai.c template. I’m basically interacting with the network like follows:static float* input_states_ptr;static float* input_currents_ptr;static float* output_states_ptr;static stai_ptr stai_input

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

Hello,I understand that ToF sensors inherently have limited performance under daylight conditions. However, I would like to know which ST ToF sensor family currently offers the best performance in daylight, regardless of whether it is a single-point or multi-zone sensor.The VL53L9 series looks very promising for our application, but unfortunately, its cost is above our target budget. Therefore, I am looking for a more cost-effective alternative that still provides good performance under daylight conditions.A wider FOV would be preferable for our application.Would it be reasonable to select a sensor based primarily on its maximum specified detection range? If so, the VL53L1 series seems to be a good candidate. However, I am not sure whether the maximum specified range is the best parameter to use when comparing sensors for real-world daylight performance.I also assume that a wider FOV reduces the number of photons received per unit area, which could potentially reduce the sensor's perfo

I’m using X-NUCLEO-IHM08M1 with NUCLEO-G474RE evaluation board for FOC speed control of PMSMs.My main sensor is SE461000AB10030 encoder (I do not intend to use a sensorless system) and I’ve set it to 1000 ppr on the MC Workbench. With other commercial inverters, I’ve always used it with only its A, B and Z outputs (not the differential inverted ones)When I power up via usb the evaluation board (DC bus off), I turn the rotor with my hand and connect the oscilloscope to CN7_17 and CN10_31, I can see the encoder pulses correctly; and when I turn the encoder by hand through one mechanical revolution (360 degree), TIM2->CNT goes from 0 to 4000, as it should.  The problem is that as soon as I press START (blue push botton), the rotor gives a brief slow jolt, the state machine switches to “alignment” and finally enters “run” mode without any faults; the currents across the three phases are these         but the rotor is stuck (it isn't moving...)  On the hardware side, I followed the chang

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?

Although the data sheet specifies a field of view of either 27 degrees or 36 degrees (depending on where about it is mention in the data sheet, I have found the effective FOV to be aound 8 degrees. Setup as follows  sensor.setDistanceMode(VL53L1X::Medium); sensor.setMeasurementTimingBudget(33000);  sensor.setROISize(16, 16); startcontnuous(100);with all other sensor settings at defaultA large all black target set up at 140 cm from the sensor, reulted in a invalid reading. I then moved a white target in from one side until a valid reading was made, marked the position and repeated this for the other side top and bottom.This resulted in an area in the middle of about 20 x 25 cm which represents a FOV of around 8 degrees. Any target outside this selected area will reults in an invalid reading (i..e canot be trusted). Targets with in ths area will be detected although the accuracy is very dependent on the refectivity of the oblect, the variation between measured and actual by as much as 30

Hi,We found an issue in VL53L4CD_CalibrateXtalk() (ULD v2.2.2, as shipped in X-CUBE-TOF1 v3.4.3).When the measured average distance is slightly greater than the target distance, the computed crosstalk is negative:ctmp_xtalk = (float_t)1.0 - (AvgDistance/TargetDistance);tmp_xtalk *= (AverageSignal/AverageSpadNb);The function only checks the upper bound (tmp_xtalk > 127.0). It then casts the negative float to uint16_t, which is undefined behavior in C. On our platform the value wraps. For example, −3 kcps is returned as 65533 and reported as a successful calibration, and the register is written with 64000, which corresponds to about 125 kcps.With that value applied, crosstalk compensation removes nearly the entire return signal: 125 kcps/SPAD × 77 SPADs ≈ 9,600 kcps, against a raw signal of about 9,700 kcps. Every subsequent measurement fails with "signal below threshold" (range_status 2, distance 8191 mm).Setup: offset calibrated at 100 mm, then crosstalk calibration on a white targe

I tried to create a project based on an existing STM32CubeC5 example and build it from command line.I am working on Linux and had the same issue on Ubuntu and Fedora.I opened CubeMX2 (Version: 1.1.1) and selected the “freertos_low_power.ioc2” under “STM32CubeC5/examples/middleware/freertos/low_power/NUCLEO-C562RE”, saved it to my new project folder as recommend via “save as” and tried to generate the CMake project.Direct at generation start I got the error message shown below, but a “good looking” project folder was still generated.Project extraction failed:=========================================================Example Path: /home/lecd/devel/STM32CubeC5/examples/middleware/freertos/low_power/NUCLEO-C562RE/freertos_low_power.ioc2Project Name: low_powerBoard Name: NUCLEO-C562REFormat: CMakeProject Directory: /home/lecd/devel/stm32c5_demoSW Pack Root: /home/lecd/devel/STM32CubeC5Extract STM32CubeMX2 project with the selected format: falseCopy Only Dependencies: trueExact Match Project N

Hello,I am trying the FOTA example project (ST67W611M1 Wi-Fi® – FOTA Project - stm32mcu) on a custom board. I use the provided python script to start an http server and get the binaries. While the connection with the server seems ok and the driver actually manages to read the JSON file and print the correct info, when it tries to get the STM32 binary there is an SPI timeout when parsing the response header of the http “GET” request. I can see that the server receives the request and is trying to send back the response headers. Even if I adapt the SPI timeout, there is an error at a higher level saying “Pull data from socket failed”.Since the SPI communication seems to work in general (initialization and download of JSON works), any hints why there is a timeout later on? 

We are experiencing failures on some of the STUSB4500 IC chips on production boards and from what we can tell, this is due to the power output (VBUS) being shorted to ground. We observed the STUSB4500 chip failing to negotiate PD, and the 1V2 and 2V7 LDO rails are all at 0VDC. This failure also happens on the EVAL-SCS001V1. When we replace the STUSB4500 IC, with a new one, the problem is resolved, which indicates there is no damage to any other component. This issue may be created with an off-the-shelf EVAL-SCS001V1 PCB connected to a 20V/3A source and shorting the output terminals. The datasheet claims to have short-circuit protection, but it seems to not have this. Our design already has output voltage clamping, ESD protection on VBUS, RPP, UVLO, and OVP, and the correct 1uF decoupling caps on the 1V2 and 2V7 rails, which is more protection than the EVAL-SCS001V1 has. What are some design implementations we can make to prevent this?

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

Hello,its the first time for me trying to use the X-CUBE-SBSFU. So I downloaded the latest version (V2.8.0) and updated to the STM32CubeIDE V2.2.0 to be up to date.But the SECoreBin Project is not compiling. I get the error message:C:/Program Files/ST/STM32CubeIDE_2.2.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.win32_1.0.100.202602081740/tools/bin/../lib/gcc/arm-none-eabi/14.3.1/../../../../arm-none-eabi/bin/ld.exe: ./Application/Startup/se_key.o(SE_ReadKey_1): Unknown destination type (ARM/Thumb) in ./Application/User/se_crypto_bootloader.o./Application/User/se_crypto_bootloader.o: in function `SE_CRYPTO_AES_ReadKey':C:/Users/……./Application/ThirdParty/ST/STM32CubeExpansion_SBSFU_V2.8.0/Projects/NUCLEO-H753ZI/Applications/1_Image/1_Image_SECoreBin/Src/se_crypto_bootloader.c:222:(.text.SE_CRYPTO_Decrypt_Init+0x16): dangerous relocation: unsupported relocationC:/Program Files/ST/STM32CubeIDE_2.2.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.

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

I tried to program my STM32WB09ke chip with my ST-LINK V3 MINIE. When pressing the Connect button on stm32cubeprogrammer, I got the DEV_TARGET_CMD_ERR. It says: unable to get core ID. When debugging with my J-Link, everything works completely fine. I can program, debug, ...When connecting my ST-Link to one of my other projects with other ST MCU but with exactly the same debug connector, It completely works fine. Here are my schematics: Does someone knows what the problem could be or am I missing something?I checked the SWDIO and SWCLK signals with my scope and everything looks fine. 

Hello ST team and community,I am developing a custom STM32MP257-based MPU board and I want to create a customized Linux OS for our own product.I would like to understand the officially recommended approach and the limitations of using OpenSTLinux/Yocto versus an Ubuntu 24.04 ARM64 root filesystem.My target hardware is:MPU: STM32MP257F Custom PCB/SOM Cortex-A35 used for Linux Cortex-M33 may be used for real-time firmware Custom DDR/LPDDR4 configuration Custom Ethernet/USB/SD/eMMC/UART peripherals Custom Device Tree generated/configured using STM32CubeMX Development host: Ubuntu 24.04 LTSI understand that ST's current Distribution Package supports STM32MP25x and allows users to create their own Linux distribution. Thank You,Vijaya.