Infinite hang in read()

[UweBonnes]

Testing with LPC845 Breakout:
(gdb) r -b -t stm32g0 -r
Starting program: /devel/edbg/edbg -b -t stm32g0 -r
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.26-lp151.18.7.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Debugger: NXP Semiconductors LPC11U3x CMSIS-DAP v1.0.7 0F040028 1.10 (S)
Clock frequency: 16.0 MHz
(gdb) bt
#0 0x00007ffff78e3c61 in read () from /lib64/libc.so.6
#1 0x00000000004073b0 in dbg_dap_cmd ()
#2 0x0000000000402539 in dap_reset_link ()
#3 0x0000000000402bd7 in reconnect_debugger ()
#4 0x00000000004015d6 in main ()
Running a second time hangs even earlier:
Debugger: NXP Semiconductors LPC11U3x CMSIS-DAP v1.0.7 0F040028 1.10 (S)
Clock frequency: 16.0 MHz
(gdb) bt
#0 0x00007ffff78e3c61 in read () from /lib64/libc.so.6
#1 0x00000000004073b0 in dbg_dap_cmd ()
#2 0x0000000000401b99 in dap_get_debugger_info ()
#3 0x0000000000401598 in main ()

After hang "pyocd gdb" does not see the device.
After un/replug, "pyocd gdb" sees the device.

After running "pyocd gdb" successfull, "edbg -b -t stm32g0 -r" suceeds as far as it is expected for an unknown device.:
(gdb) r -b -t stm32g0 -r
Starting program: /devel/edbg/edbg -b -t stm32g0 -r
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.26-lp151.18.7.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Debugger: NXP Semiconductors LPC11U3x CMSIS-DAP v1.0.7 0F040028 1.10 (S)
Clock frequency: 16.0 MHz
Error: unknown target device (DBG_IDCODE = 0x00000000)

[ataradov]

I'm not 100% clear on the scenario. Is the first trace not right after unplugging? Or is this intermittent.

In general it looks like the debugger does not respond. It is hard to tell why.

Also, does this board come with CMSIS-DAP debugger by default? Or you had to replace it with something? I might need to get one if this is the case?

[ataradov]

I found that this board does come with CMSIS-DAP debugger. I've ordered one.

[UweBonnes]

The traces are with running edbg in the debugger. An they are output of typing ^C after a long hang.

[ataradov]

Yes, but I don't understated the difference between the successful and hanging runs.

How is pyocd important here? What happens if you just run edbg from a command line without GDB? Does it not work consistently when edbg is run by itself?

I've got a shipping notification for the board, it should be here next week.

[UweBonnes]

I can fix by:
``diff --git a/edbg.c b/edbg.c
index c9e5113..2014652 100644
--- a/edbg.c
+++ b/edbg.c
@@ -346,8 +346,8 @@ void reconnect_debugger(void)
dap_transfer_configure(0, 128, 128);
dap_swd_configure(0);
dap_led(0, 1);

• dap_reset_link();
  dap_swj_clock(g_clock);

• dap_reset_link();
  }

Set frequency first, then reset the link.

[ataradov]

Yes, this makes sense and a clear bug. Clock should be set before anything that actually toggles pins. I will fix that.

[UweBonnes]

That is the profit that you have if you share code.

[ataradov]

There is no point mentioning that. This project is for my personal use. I don't care if it works for anyone else, but I'm happy if it does. So I will keep it in the state I like it to be.

I fix bugs like this as they come up for me or reported. Before you reported it, it was not a problem.

This is now fixed.