Infinite hang in read() about edbg HOT 8 CLOSED

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.

from edbg.

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?

from edbg.

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

from edbg.

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

from edbg.

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.

from edbg.

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.

from edbg.

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

from edbg.

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

from edbg.