Skip to main content
Visitor II
September 5, 2026
Question

STM32F411RE NUCLEO STLINK I2C issue STLINK NOT FOUND

I have encountered a specific issue using the STM32F411RE NUCLEO Board and I2C peripherals:

The problem:
When i plug in the board with I2C devices (DFROBOT BMM150, MPU6050, ADAFRUIT ICM20948) already connected to the board my PC (LINUX) cannot find the device.
when trying to flash CUBEIDE says something along the lines of ‘STLINK not found’ 
and PROBE-RS says:
ERROR nusb::error: interface not found (errno 2) WARN probe_rs::probe::list::linux: Make sure you have reloaded udev rules after setting everything up WARN probe_rs::probe::list::linux: Read more under https://probe.rs/docs/getting-started/probe-setup/ Error: Failed to open probe: Failed to open the debug probe. Caused by: 0: The debug probe could not be created. 1: A USB error occurred. 2: interface not found (errno 2)

The fix:
1) UNPLUG BOARD
2) DISCONNECT I2C peripherals
3) PLUG in BOARD
4) RECONNECT I2C peripherals
5) the STLINK is found again and I can flash code like normal

Will this be an issue if I design a PCB with permanently connect I2C devices, and using and external STLINKV3 programmer with a STDC14 connection to program and flash?

 

2 replies

jiangfan
ST Employee
September 7, 2026

What is likely happening

Your I2C devices are probably:

  • loading the power rail too heavily at plug-in, causing the STM32 or ST-LINK interface not to enumerate reliably,
  • holding a line in an unexpected state during reset/boot,
  • or interfering through shared signals / poor power sequencing, especially if the sensors are powered before the MCU/debug interface is fully up.

The fact that unplugging the I2C peripherals restores ST-LINK detection strongly suggests a board-level electrical/boot interaction, not a software/CubeIDE problem.

NOTE: reviewed answer mostly from AI

jiangfan
ST Employee
September 7, 2026

 

Will this happen on a custom PCB?

Potentially yes, unless you design for it carefully.
If I2C devices are permanently connected, you should verify that:

  1. The MCU can always boot cleanly
  2. SWD/JTAG pins are not disturbed
  3. Reset and boot-mode circuitry are robust
  4. Power-up sequencing does not cause brownout or bus contention
  5. The I2C devices do not back-power the MCU through SDA/SCL

Using an external STLINK/V3 with STDC14

An external STLINK/V3 will usually be more reliable than the onboard NUCLEO ST-LINK, but it does not automatically eliminate the electrical issue.

If the target board has:

  • proper SWD routing,
  • correct pull-ups,
  • stable reset circuitry,
  • and no power/bus interference from the I2C devices,

then programming should work normally.

But if the peripherals are causing:

  • MCU reset loops,
  • power rail collapse,
  • SWD pin corruption,
  • or the target not being held in a debuggable state,

then even an external STLINK can still have problems.

Key design recommendations

To make a custom PCB robust:

1) Keep SWD pins dedicated

Do not share PA13/PA14, NRST, or related debug pins with other circuitry if possible.

2) Add a solid reset strategy

  • Expose NRST
  • Add proper pull-up / capacitor values per ST recommendations
  • Make sure the debugger can drive reset if needed

3) Check I2C pull-ups and power domains

  • Use appropriate pull-up resistors
  • Avoid too-strong pull-ups
  • Ensure sensors don’t drive SDA/SCL before VDD is valid
  • Consider series resistors if needed for protection / signal integrity

4) Watch for back-powering

Some sensors can unintentionally power the MCU through I/O pins when their supply is present but the MCU supply is off.

5) Validate power-up behavior

Test:

  • MCU only
  • MCU + one sensor
  • MCU + all sensors
  • cold plug-in
  • power cycling
  • debugger attach under reset

6) Consider isolating peripherals during debug bring-up

For early bring-up, put I2C loads behind:

  • jumpers,
  • 0-ohm resistors,
  • solder bridges,
  • or a load switch

That makes debugging much easier.

Bottom line

  • Yes, this can be an issue on a custom PCB if the I2C peripherals affect power-up or reset behavior.
  • An external STLINK/V3 helps, but it is not a guarantee unless the electrical design is sound.

NOTE: reviewed answer mostly from AI