Skip to main content
Visitor II
November 6, 2025
Solved

STWINKT1B_pysdk can no longer connect

  • November 6, 2025
  • 2 replies
  • 162 views
 

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.bin
  • Full 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:

  1. What does the fast-blinking red LED (~4 Hz) indicate on STWINKT1B with DATALOG2?

  2. Can keeping ST-LINK attached cause the MCU to stay halted or block normal USB/CDC enumeration?

  3. What Option Bytes (BOOT settings, RDP, BOOT_ADD0) are required for normal flash boot on this board?

  4. 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



    moon2001_0-1762422606791.png

     

    This topic has been closed for replies.
    Best answer by SimonePradolini

    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?

    SimonePradolini_0-1763547428939.png

     

    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

    2 replies

    Technical Moderator
    November 18, 2025

    Hello @moon2001 

    I'm trying replicating your setup.

    In the meantime, can you make a couple of further experiments?

    • By using STM32CubeProgrammer, in Option Bytes check SWAP_BANK or BFB2 value. The flag should be disabled
      SimonePradolini_0-1763469808871.png
    • Have you already tested the DATALOG2 firmware without USB? Is it working if only battery-powered?

     

    Best regards,

    Simone

    Technical Moderator
    November 19, 2025

    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?

    SimonePradolini_0-1763547428939.png

     

    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