Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

programmer - implementation in userspace #23

Open
geissdoerfer opened this issue Dec 8, 2022 · 0 comments
Open

programmer - implementation in userspace #23

geissdoerfer opened this issue Dec 8, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@geissdoerfer
Copy link
Collaborator

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.

@orgua orgua added the enhancement New feature or request label Dec 8, 2022
@orgua orgua mentioned this issue Jan 31, 2024
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants