No best answer

Hi everyone,I’m developing an open-source project called Embedded Power Audit, a lightweight shell-based tool for inspecting power-management and thermal information on embedded Linux devices.The project has already been tested on several platforms, including: NXP i.MX6 NXP i.MX8M Plus NXP i.MX93 Raspberry Pi AMD/Xilinx Zynq I would now like to add support for STM32MP25.If anyone here has access to an STM32MP25-based board running OpenSTLinux, Yocto, or another embedded Linux distribution, I would really appreciate a very simple test:run the script and share the generated output with me.The tool is read-only and mainly inspects Linux interfaces such as: CPU frequencies and governors cpuidle states thermal zones memory information interrupts device runtime power-management settings other power-related sysfs/procfs interfaces Repository:https://github.com/br1pastore/Embedded-Power-AuditAt this stage I’m mainly interested in understanding which power-management interfa

Section 51.4.15 of the current (RM0433 Rev 8) reference manual for STM32H753 states the order of disabling the SAI master and slave sub-blocks.Is this true when using multiple SAI blocks on an MCU?For example:My SAI configuration is as follows:SAI 2A - Master TXSAI 2B - Slave RXSAI 3A - Slave TXSAI 3B - Slave RXWould the correct order of disabling be:SAI 2A SAI 2B SAI 3A SAI 3B?Since the master provides the clocks for the slave SAI blocks, I find it strange that the master should be disabled first, since the slave blocks may be halted during a transaction.

Hi ST Team,In our design, the USB pin pairs from PA11, PA12 our failing short multiple times during hot plug in of type C port to power the board. The USB pin pairs does not directly go to type C port rather it goes through this chip PCMF3USB3S (ESD + EMI filter) from Nexperia. Currently we do not have any ESD protection on VBUS pin. The VBUS +5V currently generates 3.3VDD to power the STM32H56V3G on our board. There is also a diode as connected reverse b/w VBUS +5V and 3.3Vdd output as recommended in AN4899.Can you please give us some insights on why this could be happening and what would be the possible solution  

Hi,Unable to set the Product state to OPEN using the Provisioning script in the STiROT_OEMuROT example.Getting the below error: But,when i’m trying to set the Product state as CLOSED it is getting Success.Note: Ensured to connect the CN7/pin5 to CN7/pin7. Also,Below is the obkey_provisioning.log content:C:\My_New_Stuff\GIT\STM32H5\Projects\NUCLEO-H533RE\ROT_Provisioning\STiROT_OEMuROT>call ../env.bat Provisionning the .obk files ...      -------------------------------------------------------------------                       STM32CubeProgrammer v2.20.0                        -------------------------------------------------------------------ST-LINK SN  : 000E00264142501820353451ST-LINK FW  : V3J13M4Board       : NUCLEO-H533REVoltage     : 3.29VSWD freq    : 8000 KHzConnect mode: Hot PlugReset mode  : Software resetDevice ID   : 0x478Revision ID : --Error: Fail to read Flash SizeDevice name : STM32H533/523Flash size  : 512 KBytes (default)Device type : MCUDevice CPU  : Cortex-M33BL

Hello,I need to confirm the top marking for the IC ST232EBDR, on the datasheet there is an information that I think that it might be a little confusing.The datasheet indicates that the marking for ST202EBDR and ST232EBDR are both “ST202EB”. but I believe that the mark for ST232EBDR should be “ST232EB” at least it is that is written on the components that I bought.Can someone confirm this information?

I have tried to programme and reset stm32F103C8T6 (Blue Pill) via different st-links, uart serial bridge via arduino uno with switching the bootloaders boot0 to 1 and also boot1 to 0. But still it cannot connect the the stm32cubprogrammer gives an error "activating device Ko”. Is it a driver issue like the esp8266 has, that worked with the previous version of driver that I hads to install manually. Is it the problem with blue pill or something else?Can anyone suggest me the solution ?

I am using a STM32H723ZGT6 based custom PCB. The PCB is being soldered using ChipQuick’s TS391LT solder paste and CQ4LF-0.5 no clean liquid flux it is then cleaned using isopropynol (IPA) and an anti-static brush. We are using the hot air gun at 350 C. These are our findings so far with respect to the corrosion issue:There is a pale yellowish gunk deposit near the pins of the micro-controller which i suspect is the flux residue carried by the IPA and getting removed due to small pitch of the IC. The solder mask above the copper layer (specially the ground) underneath the STM chip getting pealed off. The exposed copper getting corroded (as shown in the picture - bluish part under the removed chip) There is an off-white residue under the chip surface in shape of a dried out liquid spot.Since the average humidity of my area is 77% with a peat of about 90% we suspect that the gunk is trapping the moisture and a electrolytic cell is getting completed and hence the corrosion.These Boards wer

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?

The new forum seems to be wrapping lines within source code blocks; eg lines 44 & 45 here: This really messes with the layout - surely, it’s one of the things which a code block specifically should not do ?

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. 

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

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 *

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

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

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.