Skip to main content
Graduate II
February 26, 2025
Solved

STM32H563ZI Nucleo "device unknown" with everything but STMCubeProgrammer

  • February 26, 2025
  • 1 reply
  • 504 views

MBC_0-1740607699012.png

I'm having trouble getting GDB to recognize my brand new STM32H563ZI Nucleo board on Linux. The board has never been programmed.

Current situation:

  • st-info tool detects the programmer but not the target (works fine with our F1, F4, and H7 boards)
  • STM32CubeProgrammer can access the board successfully (verified, and did a chip erase)
  • Board provisioned state is OPEN
  • Using Cube command line tools (CLT) results in "TARGET UNKNOWN ERROR 32"
  • VS Code debug session (GDB) fails to recognize the target

My matching linux env udev rule:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374e", \
 MODE="660", GROUP="plugdev", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv3_%n"



Has anyone encountered similar issues with the H563ZI Nucleo? Any suggestions would be appreciated.

 

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

    Solved it. Really ***.

    In order to connect to the STM32H563 SINGLE CORE ARM PROCESSOR you must use the `-m 1` which means use MULTI CORE CONNECTION and attach to core 1.

    So.... Yea, that makes a ton of sense and is well documented in just a ton of places!!!

     

    (My guess is that SWD instance 1 is the swd interface that works, and that zero is reserved for some TrustZone provisioning that doesn't allow for full access only regression or password?.. But then why that interface is zero for existing tool incompatibility I have no idea!)

     

     

    1 reply

    MBCAuthorAnswer
    Graduate II
    February 27, 2025

    Solved it. Really ***.

    In order to connect to the STM32H563 SINGLE CORE ARM PROCESSOR you must use the `-m 1` which means use MULTI CORE CONNECTION and attach to core 1.

    So.... Yea, that makes a ton of sense and is well documented in just a ton of places!!!

     

    (My guess is that SWD instance 1 is the swd interface that works, and that zero is reserved for some TrustZone provisioning that doesn't allow for full access only regression or password?.. But then why that interface is zero for existing tool incompatibility I have no idea!)