Currently, the programmers for SBW and SWD live in the PRU and expose a simple firmware upload interface through the kernel module. This has the advantage that the low level SWD and SBW transactions execute with well defined timing on the PRU. However, the interface is rather simple and allows only uploading firmware while the underlying implementation would generally allow debugging attached devices with, for example, gdb. Also, the information how to control the specific device, e.g, an nRF52840 must be implemented by us on the PRU.
A better approach would be to offer a standard interface for programming/debugging that is accessed and controlled by existing userspace applications like pyOCD for SWD and mspdebug for SBW. Our software would just execute the lowest-level operations and leave the device-specific operations to these well-maintained tools. There exist well-defined interfaces that a debug probe needs to implement in order to work with the tools. CMSIS-DAP is the reference implementation of such protocol for ARM Cortex M microcontrollers. These protocols exchange commands and responses between the host and the debug probe through a serial interface, mostly USB.
We could implement two virtual debug probes that expose standard interfaces for debugging attached MSP430 and ARM Cortex-M microcontrollers as character devices. A tool like pyOCD opens the corresponding character device and writes commands into it. A kernel module receives the commands and either executes them itself by bitbanging the corresponding sequence on the programmer pins or passes them to the PRU for processing. The response is fed back to the character device and received by the user space tool.
Currently, the programmers for SBW and SWD live in the PRU and expose a simple firmware upload interface through the kernel module. This has the advantage that the low level SWD and SBW transactions execute with well defined timing on the PRU. However, the interface is rather simple and allows only uploading firmware while the underlying implementation would generally allow debugging attached devices with, for example, gdb. Also, the information how to control the specific device, e.g, an nRF52840 must be implemented by us on the PRU.
A better approach would be to offer a standard interface for programming/debugging that is accessed and controlled by existing userspace applications like pyOCD for SWD and mspdebug for SBW. Our software would just execute the lowest-level operations and leave the device-specific operations to these well-maintained tools. There exist well-defined interfaces that a debug probe needs to implement in order to work with the tools. CMSIS-DAP is the reference implementation of such protocol for ARM Cortex M microcontrollers. These protocols exchange commands and responses between the host and the debug probe through a serial interface, mostly USB.
We could implement two virtual debug probes that expose standard interfaces for debugging attached MSP430 and ARM Cortex-M microcontrollers as character devices. A tool like pyOCD opens the corresponding character device and writes commands into it. A kernel module receives the commands and either executes them itself by bitbanging the corresponding sequence on the programmer pins or passes them to the PRU for processing. The response is fed back to the character device and received by the user space tool.