Recently active topics

Hi all, for minimum wake time I want to use UDP with DTLS.However, I wonder if it is OK to keep the Socket open for a longer time (not closing it ever)? Even during PSM?Opening the DTLS-Sockets costs 2 seconds (handshake) and energy, for a Raw-Socket it is almost zeroDTLS: Init->Wait->Use[000000]> AT#SOCKETCREATE=5,0,UDP,0,60,60,9,0,0[000116]< #SOCKETCREATE: 0[000118]< OK[000000]> AT#DTLSCONNECT=5,0,xxx.xxx.xxx.xxx,pppp[002011]< #TLS: 3,0x00A8,2048,0[002012]< OK[000000]> AT#IPSENDUDP=5,0,xxx.xxx.xxx.xxx,pppp…Raw[000011]< #SOCKETCREATE: 0[000012]< OK[000000]> AT#IPSENDUDP=5,0,xxx.xxx.xxx.xxx,pppp…Thanks for any helpful infos,Jo

Hello,I ran into a bug in fx_stm32_sd_driver function.Our firmware was calling fx_media_volume_set on a partitioned card and we found it was corrupting the disk. The issue is  that the FX_DRIVER_BOOT_WRITE case statement hardcodes the boot sector to be at sector number 0. This works for unpartitioned (superfloppy) layouts, but does not work on partitioned SD cards with a master boot record. Calling fx_media_volume_set on a partitioned drive overwrites the MBR instead of the boot sector and corrupts the disk.Note that the FX_DRIVER_BOOT_READ, which also has to manage this problem correctly calculates the offset using the _fx_partition_offset_calculate function.Regards,Mike

I’ve implemented a sort of dynamic menu where there are 6 positions and you can resize the menu item to become 2x1 or 1x2 (see screenshot for a better understanding)It is achieved by a custom widget class built on top of ShapeThe elements can be dragged and moved around and I’m using handleDragEvent to achive that. When dragging around there’s a method that re-position the element to avoid overlapping.For some reason, sometimes, not always, when the elements are moved automatically around, some strange artifacts. Is there a reason for that; where should I watch?(at the moment I’m only using the simulator)artifactshow it should render

I am trying to use a STM32G0B1CBT3 for standard (non-FD CAN communication).The device is running from a 8 MHz HSE oscillator.This is the clock topology I am using: As you see the CCS is disabled and the CAN clock and the system clock is running on 64 MHz.In some cases my CAN frames are transmitted with a bitrate faster than expected:The edges some times falling totally to the sampling points, the calculated bit times are lower than 4 us: Putting the correct and incorrect frames the difference is more visible: I have tried to route the HSE to the MCO to see how stable is it, but I have not detected any deviation which could cause this deviation.I also tried to run an overnight test to send a CAN frame continuously and capture the waveform and calculate back the bit times are quite identical: Any hints, ideas would be welcome!

Hello everyone,I'm working on a custom PCB (professionally soldered, LGA packages) builtaround an STM32G474RET6, and I'm stuck on a communication issue with twoof my three SPI sensors. I'd really appreciate some insight from anyonewho has run into this before.My setup:- Host MCU: STM32G474RET6- Shared SPI3 bus: SCK=PC10, MISO=PC11, MOSI=PC12- TMAG5170 (SPI-only magnetometer), CS=PA11- ISM330DHCX (IMU), CS=PD2- MMC5983MA (magnetometer), CS=PA12The symptom I'm seeing:My TMAG5170 communicates perfectly over SPI, which tells me my SPI3 bus,my shared SCK/MISO/MOSI wiring, and my power rail are all healthy.However, my ISM330DHCX and MMC5983MA never respond in SPI mode — WHO_AM_I/ Product ID reads keep returning garbage (0xFF).Here's what I've already tried:1. I ruled out a software bug by switching from separate   HAL_SPI_Transmit / HAL_SPI_Receive calls to a single   HAL_SPI_TransmitReceive — no change.2. I checked for solder bridges under the LGA packages with a multimeter   (MISO to 3V3,

Hello,We are designing a custom board using the STM32MP157FAC1 device (361 balls with 0.5 mm pitch).As per AN5031 (Page 50), laser vias with a 100 µm (~4 mil) drill hole diameter and 250 µm (~10 mil) outer pad diameter are recommended for BGA balls located within the 0.5 mm pitch matrix. A snapshot of the relevant section is attached for the reference.We would like to clarify whether a Via-On-Pad strategy can be used instead of laser vias for the BGA balls within the 0.5 mm pitch matrix of STM32MP157FAC1 device.Specifically, can we use a via of 200 µm (~8 mil) drill hole diameter and 400 µm (~16 mil) outer pad diameter as via-on-pad on the STM32MP157FAC1 BGA pads instead of the recommended laser vias ? Kindly confirm whether this approach is acceptable from the CAD layout perspective and whether it can be used in the CAD layout of our design.Regards,PS  

Is there a demonstration project (outside of the CLI) for the target-wake-time feature?

Hi, We are using PCB coil antenna. We need your support to tune the filter circuit.Thanks,Sankar.K

Hi,I'm integrating a newly ordered X-NUCLEO-67W61M1 shield with a NUCLEO-H753ZI board, using the X-CUBE-ST67W61 package. I'm hitting an init failure and want to confirm the root cause before I flash anything, since I have some open questions about the flashing process itself.1. Original symptom — SPI header validation failure at bootRunning the ST67W6X CLI/Echo application, I consistently get:EXTI callbackInvalid magic 0x5501Invalid spi header from peer, magic 0x5501, len (0, 0x0), version 0, type 0 flags 0x0, rsvd 0x1sem_if_ready not receivedsem_if_ready not receivedCould not init Modem handler[ERROR] in W6X_Init APIW61 Init failedFailed to initialize ST67W6X Driver, 2This happens on every boot, identically, every time — not intermittent. Expected magic is 0x55AA; I consistently receive 0x5501 (high byte correct, low byte wrong).2. What I've verified so farTo isolate whether this is a wiring issue or a missing-firmware issue, I connected a USB-to-UART (Silicon Labs CP210x) adapter dir

I’m trying to migrate a project from the P NUCLEOWB55 MB1355 board to the P NUCLEOWB55 MB-1293 USB dongle.I retargeted the board in MX & check the pinouts etc, all fine. Opened up the project in CubeIDE & built the project.I then switched the board to BOOT0=0 (SW2) & plug it in & open CubePrgFirst issue, its really hit & miss if Prg detects the board. Most often I get Port: No DFU detected but then sometimes I actually get Port: Port 1 and the board can be connected to. It really appears to be pot luck if Prg decides it can connect.If I do manage to get it to connect, I update the FUS & stack, press the Start Stack button as outlined in a previous question, and continue to upload my *.elf file.Second issue, I get nothing from the BLE, no advertising at all. This project works fine on the MB-1355 board by the way.

I open up CubeIDE, select a workspace, click “Import projects”  the project explorer tab (excuse the typo)  There is project there, But nothing appears in the Project Explorer,  

 You can currently set tick rate using setVsyncInterval().I want to be able to get the tickrate using getVsyncInterval(). This would make timing things in the gui easier (blinking cursor, animation speed, boot logo, etc.). I made a topic about this earlier, but it got closed. 

I am using TIM1 CH1 in PWM mode with the TIM1 repetition counter (RCR) to generate a finite number of STEP pulses for a stepper motor. The desired step frequency is calculated from the motor speed, and ARR/CCR1 are configured accordingly. RCR is set to steps - 1 so that the PWM should generate the requested number of periods and then stop.I am using HAL_TIM_PWM_Start() and the TIM1 update interrupt to detect when the required number of pulses has completed. The update callback is working correctly and HAL_TIM_PeriodElapsedCallback() is being called at the expected completion point.However, TIM1 CH1 is not generating the PWM pulse train correctly, or in some cases no PWM is visible at all on the output pin. I have tried configuring PSC, ARR, CCR1, RCR and the update event/flags before starting PWM, but I am still unable to get the finite number of PWM pulses reliably.I have attached my motor_driver.c file for reference. Could you please review the implementation and let me know if I am

at stm32wl33 datasheet there is RX sensitivity topic but i think wrong– RX sensitivity @ 1% BER:◦ -132 dBm @300 bit/s 433 MHz OOK◦ -128 dBm @300 bit/s 868 MHz 2(G)FSK◦ -112 dBm @38.4 bit/s 868 MHz 2(G)FSKit should be kbit/s .  

Support request: STM32WL33CC — DEEPSTOP average current rises well above datasheet spec, even within a single uninterrupted dwellPart / packageSTM32WL33CC (custom board, not a Nucleo/eval board).SummaryOn our custom board, DEEPSTOP average current starts near the expected low-µA range on entry but climbs over tens of seconds to a plateau of roughly 360–390 µA — two to three orders of magnitude above the datasheet's Table 13 "Current consumption in DEEPSTOP mode" figures (≈1.2–2.1 µA ICORE across all listed LSI/LSE/RTC/IWDG/LPUART configurations). This is reproducible, happens within a single uninterrupted DEEPSTOP dwell (i.e. it is not an artifact of repeated entry/exit cycling), and we have ruled out every peripheral, sensor, and firmware-level cause we can identify. We'd like ST's input on whether this is a known/expected behavior of the DEEPSTOP power architecture (e.g. an internal analog settling time not captured in the static spec table) or points to a board- or configuration-lev

We are currently working on flashing an STM32L071KZ MCU using the STM32 bootloader.The flashing process completes successfully when using a 64-byte payload. However, when we reduce the payload size to 8, 16, or 32 bytes, we observe unexpected behavior. In each case, only the first 8, 16, or 32 bytes of every 64-byte flash block are programmed successfully, while the remaining writes within the same 64-byte block do not take effect. This pattern repeats consistently for every subsequent 64-byte-aligned address.We have verified that:The correct data is being transmitted to the MCU. The target flash address is incremented correctly for each write operation. The bootloader acknowledges the write commands.Despite this, the flash programming behaves correctly only when using a 64-byte payload.Is there any known limitation or programming requirement for the STM32L071KZ bootloader or flash controller regarding payload sizes? Are there any additional steps or constraints that must be followed w

Hi all,I have this kit but I don’t have any bolts holding the display PCB to the main PCB. I tried to look at the BOM for a reference to the part number but I don’t see anything for the bolts. I took one of the bolts holding the standoffs to the main PCB and it looks like an M4mm x 0.5 but I rather be sure before I order a few online. I have enough stuff that doesn’t match them and I rather not add more :-).Thanks

Hi Team,good day,may we seek your expertise regarding these two PNs.L9369-TR and L9369S-TR.Does the "S" suffix indicate a newer, improved model?What specific design changes have been made?Is there any official documentation from the manufacturer for S?thank you very much.

I am designing a custom board using the STM32WL55 in UFBGA73, operating at 433 MHz, and I am currently facing higher-than-expected TX current consumption together with lower RF output power.I would like to know whether ST can provide load-pull data, optimum complex load impedance, or PA matching information at 433 MHz, particularly for approximately 0 dBm and +14 dBm TX power.I have compared my custom board against an STM32WL Nucleo board using the same firmware and RF settings.My measurements so far are:Nucleo board TX current: approximately 65.8 mACustom board TX current: approximately 72 mADifference: approximately 6–7 mA higher on my custom boardConducted RF power measurement on my custom board indicates approximately 10 dB lower output power than expectedMy next step is to measure the impedance presented to the PA at the beginning of the RF matching network and determine whether the PA is seeing the correct load at 433 MHz.Ideally, I would like to compare my measured impedance wit

Hi,We’ve been trying to implement secure-boot on our STM32H573-based device and the new code boots fine when the product state is OPEN. From what I understood, the PROVISIONING state does not boot the user code, and we thus need to put the device in iRoT-Provisioned to see if our boot chain works as expected.More info about our setup: Part: STM32H573AIIxQ DBGMCU_IDCODE (0x44024000): 0x10076484 Boot: STiRoT (BOOT_UBE=0xC3), TZEN=0xB4 Layout: secure app at 0x0C000400 (24 KB), non-secure app at 0x08006400 Software: STM32CubeMX-generated project, STM32Cube H5 HAL Debug: ST-LINK + OpenOCD, debug authentication (certificate chain), session reports Secure stateBack to the topic, I can see that te PKA register interface is fully alive, but the PKA compute engine never starts once thedevice is in iRoT-Provisioned product state. HAL_PKA_Init() spins in PKA_WaitOnFlagUntilTimeout() waiting for PKA_SR.INITOK, times out after 5 s, and the application lands in Error_Handler().The exact same binary a

Hello ST Community,We are optimizing background listener stability and remote webhook payload handling when integrating embedded telemetry data into enterprise management pipelines.Technical Setup: Our integration architecture at Frontline Sales Consultancy (flsc.co.uk) triggers automated B2B notifications and REST API syncs over HTTPS (TLS 1.3). The Issue We're Facing: Under heavy concurrent load spikes, background POST webhook listener sockets occasionally report HTTP 504 gateway timeout responses before acknowledging payload completion. Direct REST API requests to the same remote host resolve normally under 150ms thresholds. Are there recommended TCP keep-alive settings or queue worker retries to prevent connection drops during high-volume sensor/telemetry data syncs? Any advice on managing asynchronous background worker threads would be appreciated!Thanks!

Hi there!I'd like to use the STEVAL-CAM-M01 P-board to evaluate the VD55G0 BrightSense image sensor with the Discovery kit for the STM32N6 MCU (STM32N6570-DK). The discovery kit does have a camera connector, however, looking at the schematics it seems that the polarity of the CSI data and clock lines is swapped compared to the P-board. Everything else looks fine.Is it possible to use the P-Board with the Discovery kit without destroying either of the two? ST's marketing material (slide 33) seems to suggest it is possible but the schematics are unclear. Note that a similar question has been asked in the MCU forum, but it was suggested to ask in this forum to be sure. Also note that I'm not asking about software driver support here, only hardware compatibility.Camera connector on STM32N6 discovery kit: Connector on P-board:Thanks a lot!Michael

Dear STM Community Team,We are working with the STM32N657X0H3Q microcontroller in our custom hardware design. We have interfaced S80KS5123GABHB020 Octal RAM devices with the controller using the XSPI interface.In our design, we are using a dual Octal memory configuration as described in the STM32N6 Reference Manual. The two 8-bit memories are configured to operate together as a 16-bit external memory interface.We would like your guidance regarding the correct STM32CubeMX configuration settings for this dual Octal memory setup.Our configuration details are: MCU: STM32N657X0H3Q External Memory: S80KS5123GABHB020 Interface: XSPI Memory Configuration: Dual Octal mode (two 8-bit memories forming a 16-bit interface) Intended usage: External RAM for (ltdc)framebuffer Memory mapped access: XSPI memory-mapped mode Could you please confirm the recommended STM32CubeMX settings for the following parameters? XSPI mode selection: Should the configuration be set as HEXASPI mode? Are

Dear ST Technical Support Team,I am currently working on the protection implementation of a flyback SMPS. I found the SEA05 suitable for CC/CV regulation due to its low component count, small footprint, and simple implementation.I would like to clarify the behavior of the SEA05 during a short-circuit condition.Our converter specifications are:Input voltage: 110 VDC nominal Output voltage: 15 V Output current: 5 ADuring a hard short circuit, the output voltage may fall close to 0 V. If the SEA05 is powered from Vout, its VCC will also fall below the specified minimum operating voltage of 3.5 V.In this condition, can the SEA05 still sink the optocoupler LED current through its output and maintain CC control, or does the IC stop operating once VCC falls below 3.5 V?If the SEA05 cannot provide CC control under this condition, please suggest a recommended method for implementing short-circuit protection with the SEA05.Thank you for your support.Best regards,Yajush

Hello expert, I’m using the latest version of stedgeai-dc.st.com (online) to compile my CNN model but by default, choosing the STM32 MCUs, the target is F4 family while I’d compile and optimize my  code for H723ZG board. It seems there is no way to change the target board…. why? and how can I do it? indeed If I see the stdout.txt generated at the end I see:>>> stedgeai generate --model tiny_resistor_cnn.onnx --optimization balanced --target stm32f4 --name network --workspace workspace --output outputST Edge AI Core v4.0.1-20581 7ed50de05so it’s not optimized for my board.Could someone help me please? Many thanks and regardsLorenzo