2025-11-06 1:54 AM - last edited on 2025-11-06 1:57 AM by Andrew Neil
Hello,
My STWINKT1B (STEVAL-STWINKT1B) had been working fine, but suddenly it is no longer detected by PySDK.
Now the red LED blinks rapidly (≈4 Hz) and no USB/COM device appears in Windows Device Manager.
To recover it, I performed a full flash using STM32CubeProgrammer + ST-LINK (SWD), with the official firmware:
C:\Users\User\Downloads\fp-sns-datalog2\STM32CubeFunctionPack_DATALOG2_V3.1.0\
Projects\STM32U585AI-STWIN.box\Applications\DATALOG2\Binary\datalog2_release.binFull erase → Program + Verify = OK, but after reset the symptom remains: fast red LED blinking and still no USB device.
During the firmware update, both the ST-LINK and the board were connected to my laptop.
I also powered the board via micro-USB for more than 2 hours, but the red LED keeps blinking at the same rate (no green LED).
I tried different cables/ports/PCs, battery OFF/ON, and a FAT32/MBR microSD (also tried empty card), but the issue persists.
Could you clarify:
What does the fast-blinking red LED (~4 Hz) indicate on STWINKT1B with DATALOG2?
Can keeping ST-LINK attached cause the MCU to stay halted or block normal USB/CDC enumeration?
What Option Bytes (BOOT settings, RDP, BOOT_ADD0) are required for normal flash boot on this board?
Any recommended recovery procedure (e.g., disconnect ST-LINK, power via USB OTG only, required SD card format/content) to get PySDK detection back?
Environment / Facts
Board: STWINKT1B (STEVAL-STWINKT1B)
Firmware: FP-SNS-DATALOG2 v3.1.0 (datalog2_release.bin)
Tool: STM32CubeProgrammer + ST-LINK (SWD)
Symptom: Red LED fast blink (~4 Hz); no USB/COM device
Tried: Reflash, different PCs/cables, battery OFF/ON, microSD FAT32/MBR (empty), long USB power/charge
2025-11-18 4:50 AM
Hello @moon2001
I'm trying replicating your setup.
In the meantime, can you make a couple of further experiments?
Best regards,
Simone
2025-11-19 2:19 AM
Hello @moon2001
I finally replicated your issue. It’s related to the latest STWINKT1B production batch. I can solve the bug via firmware.
First, I need a further confirmation on your side.
Which is the number you can see on the back side of the board? It should be 2431?
On the front side, is U2 unpopulated?
On 2431 production lot, the U2 sensor is unpopulated, thus exposing an IRQ pin. In previous lots instead, U2 sensor was available.
DATALOG2 up to the publicly available v3.1.0 is enabling that IRQ. So, 2431 boards have this IRQ pin left floating, thus generating the issue.
From the upcoming v3.2.0 this pin will be properly set up as GPIO_Analog, solving the bug.
Best regards,
Simone