Product forums

What is repopulating the security database on the stm32wb55 when it reboots and how do I stop it.   I’m calling aci_gap_clear_security_db() and verifying that the bond list is empty with aci_gap_get_bonded_devices().   When the device reboots, the bond entry that was deleted is back when aci_gap_get_bonded_devices() is called.  What’s going on?

I purchased  X-NUCLEO-53L9A1 with NUCLEO-H563ZI as it was recommended by ST. I just want to load the binary and see a simple ranging output value array. The binary provided didn´t work. Now it seams like they recommend  Nucleo N657X0. Could please someone clarify what board should I use so that there is a working binary provided?

Hello,I've got a problem with displaying an image classification AI on my board. So far I've been following this tutorial:https://wiki.st.com/stm32mcu/wiki/AI:How_to_use_Teachable_Machine_to_create_an_image_classification_application_on_STM32starting from step 3, as I already have a trained AI model as .tflite file.The execution with the .yaml file is working fine, it's flashing but the display is only showing artifacts.Hardware details:STM32H747I-DISCO: MB1248-H747I-D03- LCD Daughterboard: MB1166-A09- Panel Controller: NT35510B-CAMS-OMV:Camera module adapter board: MB1683-CAMS-A02- Camera module:  MB1379-2V8-A05- Image sensor: OV5640The display was a newer version so I changed the defines inapplication_code/image_classification/STM32H7/Application/STM32H747I-DISCO/Inc/CM7/stm32h747i_discovery_conf.hto this:#define USE_LCD_CTRL_OTM8009A             0U#define USE_LCD_CTRL_NT35510                1U#define USE_LCD_CTRL_ADV7533                0UThe nt35510.c and .h files already existed in

Board: NUCLEO-N657X0-Q (MB1940), STM32N657X0H (Cortex-M55 + Neural-ART NPU), Device ID 0x486 Rev Z.Toolchain: ST Edge AI Core v4.0.1-20581 (STM32Cube.AI 12.0.1-RC2), atonn 1.1.3-275, NetworkRuntime1201_CM55_GCC, arm-none-eabi-gcc 14.3.1 (STM32CubeCLT 1.21.0). SUMMARYA small int8 QDQ model (TCN: Conv2D x7 + Gemm x2, macc ~2.37M, int8 weights ~20 KB) generated with "stedgeai generate --target stm32n6 --st-neural-art" runs to completion on the NPU but produces wrong outputs: high-input forecasts collapse to baseline. Independent cross-check: onnxruntime on the same int8 ONNX gives 9.664 (ppm, log-domain output dequantized) on our golden window; the NPU returns ~0.26. Confirmed on hardware with ST's own "stedgeai validate --mode target" (regression head rmse 8.78, cos 0.589 vs the reference). LOCALIZED ON-TARGET TO A SINGLE OPPer-layer on-target validation (backbone stage outputs exposed as ONNX outputs):- input projection Conv: cos 0.999 (correct)- block 0 (dilated Conv + Slice + residual

Hi all, Any well defined step by step for STM32N6 disco board? a link would be appreciated.  Thank you. 

Hello, I recently encountered this error while deploying an AI model on an STM32N647 for performance verification. I noticed that others have encountered the same issue on the official website, but following the suggested solutions did not resolve my problem—I’m still getting the same error. This issue has been troubling me for a week now. Are there any other ways to resolve it? 

I'm currently developing with the STM32N6570-DK, using STM32N6 1.4.0 firmware, and using AI Studio and CubeMX to generate projects.However, I've encountered a very confusing problem. In the program generated by AI Studio, after calling MX_EXTMEM_MANAGER_Init() in the FSBL, it calls functions like BSP_XSPI_NOR_Init() and BSP_XSPI_RAM_Init(). This seems to be an additional Flash and SRAM driver written separately by the official documentation. /* Initialize all configured peripherals */ MX_GPIO_Init(); MX_XSPI1_Init(); MX_XSPI2_Init(); MX_EXTMEM_MANAGER_Init(); /* USER CODE BEGIN 2 */__HAL_RCC_AXISRAM2_MEM_CLK_ENABLE(); __HAL_RCC_AXISRAM3_MEM_CLK_ENABLE(); __HAL_RCC_AXISRAM4_MEM_CLK_ENABLE(); __HAL_RCC_AXISRAM5_MEM_CLK_ENABLE(); __HAL_RCC_AXISRAM6_MEM_CLK_ENABLE();/** Workaround for an issue generated in STM32CubeN6 FW 1.4.0 **/ extern XSPI_NOR_Ctx_t XSPI_Nor_Ctx[XSPI_NOR_INSTANCES_NUMBER];

Hello ST Community,I am working with the STM32N6570-DK and running a custom-trained ST YOLOX Nano object detection model using the STM32N6 Getting Started Object Detection application.My custom model has 5 classes.The model is successfully generated and integrated into the STM32N6570-DK object detection project. The application starts correctly, the camera/display starts running, and I can see a few frames initially.However, after processing a few frames, the display freezes/stops updating. The board itself does not appear to continue normal inference after this point.I also noticed an unexpected LED indication on the board. This LED was not active when I previously ran the standard/reference object detection model. I have attached photos of the front and back of the STM32N6570-DK showing the LED state. My setup is:Board: STM32N6570-DK Application: STM32N6 Getting Started Object Detection Model: Custom ST YOLOX Nano Input: 480 x 480 x 3 Number of classes: 5 Camera: ST camera module con

Hello ST Community,We are currently using the x-cube-n6-ai-face-landmarks pipeline on the STM32N6570-DK. We now want to extend the BlazeFace stage so that it can detect additional DMS-related classes along with face detection. The classes we are interested in are:Phone, Seatbelt, Smoking, Face, Drinking. At present, the BlazeFace model used in the ST face-landmark project is a single-class face detector, and we could not find a public ST training pipeline for retraining or extending this specific BlazeFace model. Is there any ST example or reference repository for training BlazeFace on:WIDER FACE, custom datasets, or custom multi-class datasets?Our goal is ideally to reduce the number of separate detection models while keeping the existing face-landmark pipeline functional on STM32N6570-DK.Any guidance on the recommended training flow, supported model architecture, or available reference code would be very helpful.

Hi,I am developing application on B-U585I-IOT02A (STM32U585), using mx_wifi component V2.3.3 (SPI transport, socket mode MX_WIFI_NETWORK_BYPASS_MODE == 0), EMW3080B module firmware V2.3.4, bare-OS shim, link associated and DHCP lease verified before every test.Symptom. MX_WIFI_Socket_setsockopt() returns -1 immediately for MX_SO_BLOCKMODE (0x1000) at level MX_SOL_SOCKET (0xfff). The refusal is value-invariant: optval 0 and 1 behave identically (0 would request the module's default state), and OptLen 1, 2 and 4 all fail — so the option name, not the payload, is rejected. MX_WIFI_Socket_getsockopt() on the same option is refused as well, so the effective mode cannot even be read back. Mainstream options on the same socket (MX_SO_REUSEADDR, MX_SO_SNDTIMEO, MX_SO_RCVTIMEO) succeed.Minimal reproint32_t sock = MX_WIFI_Socket_create(obj, MX_AF_INET, MX_SOCK_STREAM, MX_IPPROTO_TCP);int32_t optval = 1;                        /* 1 = non-blocking */int32_t ret = MX_WIFI_Socket_setsockopt(obj, soc

Built a minimal on-device training stack for STM32 — fits in 608 bytes RAM total.The problem: Adam optimizer needs exp_avg + exp_avg_sq — 2× parameter RAM. On STM32F103 (20KB SRAM) with a 5K parameter model that's 40KB just for optimizer state. Doesn't fit.What I built:GravOptMini — momentum optimizer with quantile-based gradient freeze. Only exp_avg (1× param RAM). Freezes low-gradient parameters to reduce compute.W-Twin Lite — power-law baseline fitted on early steps, tracks deviation. Pure float32, no scipy, no numpy. Rolling window of 20 values. ~240 bytes.Benchmark (Python simulation, STM32 memory constraints):- Model: 46 params, 184 bytes- GravOptMini state: 368 bytes (exp_avg only)- W-Twin Lite: 240 bytes- Total: 608 bytes- MNIST accuracy: 93.2% vs Adam 97.4%- W-Twin overhead: 3.9% per step- Detection: anomaly caught 96 steps before visible loss divergence, 0 false alarms on clean runNext step is a real STM32 test with physical hardware. C port of both components is the plan.Has

Hi,I'm developing an STM32 application that utilizes mx wifi component from  B-U585I-IOT02A board support package, i am trying to configure it to utilize CMSIS_OS but it fails to build out of the box then.Symptom. Setting MX_WIFI_USE_CMSIS_OS == 1 does not compile against a CMSIS-RTOS v2 environment. The component's CMSIS layer declares and uses CMSIS-RTOS v1 identifiers that do not exist in the v2 shim (cmsis_os.h here only forwards to cmsis_os2.h, osCMSIS = 0x20001U):/* mx_wifi_cmsis_os.h */#define LOCK_DECLARE(A)  osMutexId A          /* v2 type is osMutexId_t            */#define FIFO_DECLARE(Q)  osMessageQId Q       /* line 187: v1 type, v2 has none    */void *fifo_get(osMessageQId queue, uint32_t timeout);          /* line 238        */osThreadId thread_new(const char *name, void (*thread)(void const *), ...); /* 250 *//* LOCK_INIT's osCMSIS >= 0x20000U branch still calls v1 macros: */osMutexDef(MUTEX); (A) = osMutexNew(osMutex(MUTEX));           /* osMutexDef/osMutex are v1 *

Hello everyone. I read that V8 will become available for OEM in Q1, but is there any estimations when V8 will become available for independent engineers or maybe even NUCLEO V8 will be released?

Hey,I am having a big issue with ESD discharges and the STUSB4500. Essentially, I auto negotiate to 20V, and on ESD discharge, the STUSB shuts off VBUS_EN_SINK, while the supply continues to supply 20V. My thought is that on ESD discharge, the chip for some reason thinks it has had a disconnect event, waits for the supply to recover to 5V, but the cable has not been disconnected so continues to supply VBUS with 20V, and the STUSB then is in a hard stuck state until actual unplug and re-plug. There is no error seen, as GPIO does not pull low and is configured to show error states.I cannot find a document that exposes all of the register values, but after every shut down, the chip register state reads the same failure state. The dump is as below. # Before dischargeSTUSB4500 @ 0x28, registers 0x00..0xff 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f00: 00 00 00 00 00 00 12 00 11 20 00 63 fb 01 41 0a10: 0a 13 00 40 00 02 0c 2c 00 00 00 21 01 80 00 0020: 10 c8 5f 00 00 9c 00 02

I’ve been using STM32CubeIDE, STM32CubeMX, STM32CubeProgrammer, and STM32CubeMonitor on a Mac currently running macOS 26.6.When I run env or export in Terminal (which uses Zsh by default), I find these two STM32-related environment variables.STM32CubeMX_PATH=/Applications/STM32CubeMX.app/Contents/ResourcesSTM32_PRG_PATH=/Applications/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/Resources/binExamined Zsh dotfiles in my home folder and found the following two *export*s in ~/.zshrc that set them.export STM32CubeMX_PATH=/Applications/STM32CubeMX.app/Contents/Resourcesexport STM32_PRG_PATH=/Applications/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/Resources/binWhich apps have added these; CubeMX, CubeProg, or perhaps the respective plugins from CubeIDE? What is their intended purpose, and in particular, which other STM32Cube tools rely on them? Also, do the apps add these every time on launch or only once during installation?

Hello everyone, I have seen that is possible to generate a pdf report using STM32CubeMX (version 6.18.1) as shown in the image: Is there a way in order to launch a command line to run this operation? In order to automatize my development process.Thank you in advance, Alberto

Good day. Thank you for taking the time to review this query. We have recently developed a USB PD board using the STUSB4500. Most features seem to be in working order: PDO negotiation and NVM programming are functional and reliable. We have added a SMPS on the board (at the output of the STUSB4500 power path) for a 3v3 output in addition to USB PD. There is a problem when probing the STUSB4500, however. When the board powers on, everything seems fine, until the board's GND is probed with the GND of a battery-powered multi-meter or oscilloscope connected to mains (without connecting the positive connection) - when this happens, it seems like the chip resets, because power is cut to the SMPS. We are using a 10K pull-down that is 2 mm from the RESET pin (and we did also try 1K and 100K, but this did not resolve the resetting issue). After a decent amount of debugging, I noticed that there is improvement under these conditions:The GND probe is connected before the board is plugged in and p

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? 

Hi ST Community,I’m looking for the schematic/reference design for B-LVDS7-WSVGA, or the LCD part number or datasheet of LCD used on this board.

I am experiencing two separate issues with the generated LPTIM1 configuration in STM32CubeMX2.1. Clock configuration is removed when assigning a label to LPTIM1The first issue occurs when assigning a user label to LPTIM1.As soon as a label is assigned to LPTIM1 and the code is regenerated, the RCC initialization and peripheral clock configuration are removed from mx_system_init().The deleted code looks like this:system_status_t mx_system_init(void){......... LL_ICACHE_Enable(ICACHE);- /*- Clock system section- */-- /* Initialize RCC peripheral */- if (mx_rcc_init() != SYSTEM_OK)- {- return SYSTEM_CLOCK_ERROR;- }-- /* peripherals clock configuration and activation- is centralized: no clock activation/deactivation in pppi_init */-- if (mx_rcc_peripherals_clock_config() != SYSTEM_OK)- {- return SYSTEM_CLOCK_ERROR;- }.........Therefore, the calls tomx_rcc_init();mx_rcc_peripherals_clock_config();are no longer present after assigning the LPTIM1 label.A

Hello,Greetings for the day.As the ST community is already aware based on my previous questions, I have started using the latest ST MCU STM32C5 series and I have configured my launch.json to have SWO support for the MCU (hoping that this works as the application was previously running on L4).  This is the snapshot of how my launch.json looks like, I had to comment out the SWO feature if I have to set up the MCU in debug mode and work. If I place the configuration back, the MCU goes into a hard trap and the only way to get it running is to do a power cycle.Does anyone have a workaround for this for the STM32C5 MCU?Regards,

There is a problem with STM32 signing tool version 2.21.0. When header version is 2.3 and alignment flag is used, then image length in header is greater by the alignment byte count.To reproduce:Create dummy.bin that is filled with 256 bytes of FF's. For example with HxD tool.Sign it with no keys:STM32_SigningTool_CLI.exe -bin dummy.bin --type fsbl --no-keys --option-flags 0x80000000 --output signed.bin --dump-header signed.bin --header-version 2.3 --alignView the signed.bin with hex viewer (e.g. HxD) at offset 0x6C which is Image length by UM3234 rev 2:It is 0x2C0 = 704. This is 448 bytes more than original 256 bytes.When removing --align flag from signing call, the length becomes correct, but this image is not bootable anymore because STM32N6 Boot ROM expects FSBL image start address to be aligned to 0x400.I want to use this length field to check during OTA that FSBL upgrade file size and checksum are correct before programming it into Flash. But I wonder how does N6 Boot ROM treat th

I am using the STM32H5F5 and plan to implement the Secure Manager. I would appreciate clarification on the following questions: Can the user application key be provisioned to the OBKey area during Secure Manager installation? After the Secure Manager is installed, can the user application write a key to the OBKey area? How can an application—secure or non-secure—read a provisioned OBKey?

Hello ST Community,While studying the STM32G491RE at the bare-metal level, I noticed a statement in RM0440 Rev. 9 that looked inconsistent with the Cortex-M4 architecture and the STM32G4 documentation when i compared. RM0440 - STM32G4 series advanced Arm-based 32-bit MCUsRevision: Rev. 9Section: 1.1 — General informationPage: 74The document states: “The STM32G4 series devices have an Arm Cortex-M4 with FPU core with Arm TrustZone.” However, the STM32G491RE uses a Cortex-M4 with FPU, which implements the Armv7E-M architecture. And Arm TrustZone-M is part of the Armv8-M Security Extension. Could ST please confirm whether the above statement in RM0440 Rev. 9 is incorrect?Thank you.

Hi Can you please tell me where I can find the safety manual for the SR5E1Ex series of micros? Many thanks Paul W.