debugger via UART without ST-LINK on NUCLEO-H755ZI-Q

[Domy_ST]

hello ST Community!

I'm trying to connect via UART without USB ST-LINK to the NUCLEO-H755ZI-Q for debugging from the STM32CubeIDE environment, but I can't connect.

What settings do I need to make in the STM32CubeIDE environment to debug via UART?

I tried connecting via UART from the STM32CubeProgrammer environment to simply read flash memory, but it won't connect.

What settings do I need to make in the STM32CubeIDE environment to debug via UART without USB ST_LINK?

Thanks for supports

[Domy_ST]

@Andrew Neil 

I would like to do full debugging via UART because in the future the Nucleo-H755ZI-Q microcontroller will be integrated into a board and I will not have access to the ST-Link USB connection (I'm not sure if I will have access to the SWD using the STDC14 - MIPI10 connector) but I am sure I will have access to the UART and will also need to debug the UART alone (and maybe the STDC14 - MIPI10 connector). So I have to debug the UART.

[Andrew Neil]

---

@mƎALLEm wrote:

---

So not possible to debug your application over UART

---

The Debug Monitor approach remains a possibility...

I remember the days when it was the only option without spending many thousands of $$$ on a large and unwieldy ICE!

But it is limited compared to SWD (or JTAG) - so not sure why @Domy_ST would want to go back to the Bad Old Days?

PS:

A real ICE:

[mƎALLEm]

---

@Domy_ST wrote:

@Andrew Neil 

I would like to do full debugging via UART because in the future the Nucleo-H755ZI-Q microcontroller will be integrated into a board and I will not have access to the ST-Link USB connection (I'm not sure if I will have access to the SWD using the STDC14 - MIPI10 connector) but I am sure I will have access to the UART and will also need to debug the UART alone (and maybe the STDC14 - MIPI10 connector). So I have to debug the UART.

---

Again that's not possible and that doesn't make any sense.

Please review my previous posts.

[mƎALLEm]

---

@Andrew Neil wrote:

---

@mƎALLEm wrote:

---

So not possible to debug your application over UART

---

The Debug Monitor approach remains a possibility...

I remember the days when it was the only option without spending many thousands of $$$ on a large and unwieldy ICE!

But it is limited compared to SWD (or JTAG) - so not sure why @Domy_ST would want to go back to the Bad Old Days?

PS:

A real ICE:

---

Does it allow a full debug over UART? viewing register content? setting break points etc ?

[Andrew Neil · Accepted solution]

---

@Domy_ST wrote:

I would like to do full debugging via UART because in the future the Nucleo-H755ZI-Q microcontroller will be integrated into a board .

---

You realise that integrating ST Development boards into a final product is not allowed?

See the Terms of Use (via: https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html#documentation)

---

@Domy_ST wrote:

I'm not sure if I will have access to the SWD using the STDC14 - MIPI10 connector.

---

How to do this is described in the User Manual:

https://www.st.com/resource/en/user_manual/um2408-stm32h7-nucleo144-boards-mb1363-stmicroelectronics.pdf#page=17

also via: https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html#documentation

[Domy_ST]

OK, I only have two options: Debug Monitor (printf only) or debug using the MIPI10 connector.

Thank you very much.

[Andrew Neil]

---

@mƎALLEm wrote:

---

Does it allow a full debug over UART? viewing register content? setting break points etc ?

---

Yes - see: Step-through debugging with no debugger on Cortex-M.

@Domy_ST but it all become code that you have to write yourself (or find from somewhere):

• To set breakpoints
• to do single-step
• to read & modify registers
• to communicate with the operator.

To make it work with STM32CubeIDE, you'd effectively have to implement the GDB on your target.

It'd be a whole lot less effort to just use SWD - which is exactly why we have SWD!

[Andrew Neil]

---

@Domy_ST wrote:

Debug Monitor (printf only)

---

No.

A Debug Monitor is different from "printf only".

PS:

Here's an example of a Debug Monitor which works over CAN:

https://mcuoneclipse.com/2025/09/25/using-can-fd-for-remote-hardware-debugging-of-cortex-m-devices/

And here's one that works with GDB:

https://github.com/adamgreen/mri 

[Andrew Neil]

I think it could be summarised as:

     SWD    -- most  capable; least intrusive
      ^
      |
      |
   Monitor  -- more  capable; less  intrusive
      ^
      |
      |
   printf   -- least capable; most  intrusive

#DebugMonitor