Paul, all,

while I perfectly agree with anything that is said on the post about JTAG/SWD debugging, I would like to propose another solution that doesn't require any hardware modification.

Some time ago, Thomas Roell implemented the GDB debug protocol on the ARM in software, using a simple UART connection (external FTDI board) and mentioned it in the diyRovers group (https://groups.google.com/forum/#!to...rs/GtfSQDLP2_E). Throughout the last few days, we tried to port it to the Teensy and the first results were inspiring.

However, it turned out that the Mini54 bootloader processor uses the breakpoint feature of the K20 in order to detect bootloader requests through JTAG. It programs a bit called C_DEBUGEN in the SCB_DHCSR register, which cannot be undone by software. From that point on, software breakpoints are routed to the external JTAG pins and trigger the bootloader process instead of generating debugger exceptions in software.

Unfortunately, as said before, the only way to change C_DEBUGEN is through external debug hardware - there is no way to clear it by software. This means that this bit effectively prohibits the use of a software debug stack, as it never will receive a debug exception.

My suggestion is to implement a mechanism that permits to clear this bit. As far as I can see, breakpoint arguments ("BKPT #<nn>") seem to be a feasible way to do this, maintaining compatibility with existing versions. On a breakpoint event, the Mini54 could recover the argument <nn> and, if it matches a predefined number, clear C_DEBUGEN in DHCSR through JTAG. From that point on, a software based debugger stack could take over.

This would be a pure software solution, requiring only an update of the bootloader code in the Mini54.