[pyOCD] Is CMSIS-DAP a requirement? (#186)
Patrick Maupin
The project title says "Open source python library for programming and debugging ARM Cortex-M microcontrollers using CMSIS-DAP." For various reasons, I have used FTDI chips for JTAG operations in the past. In the past I even developed an FTDI solution that includes a gdbserver for the Leon processor.
Now I'm doing some work with ARM Cortex and basically have to decide whether to update my current gdbserver to also work with ARM, or learn pyOCD and merge some of my lower-level FTDI support code into it -- If I develop an FTDI backend for pyOCD, would it be possible to get that accepted into master, or is the focus solely on CMSIS-DAP interfaces?
Finally, maybe I missed it, but how are regression tests performed?
Thanks!
—
Reply to this email directly or view it on GitHub.
Sam Grove
Hey Patrick glad you found this project and hope it's of use for you. As the description states the current and only transport supported is cmsis-dap. I don't see the benefit in adding more transports at the moment. There are quite a few other tools that do. If the ftdi was updated to support cmsis-dap, well that would be great.
Patrick Maupin
hope it's of use for you.
I do too, because it's usually more productive to join forces.
I don't see the benefit in adding more transports at the moment.
Are you going to update it to use something other than HID? HID transport speed is, frankly, underwhelming.
There are quite a few other tools that do.
In pure Python? Pray tell. I'm not particularly interested in C-based stuff -- I get enough of that pleasure with the actual firmware.
If the ftdi was updated to support cmsis-dap...
Sorry, I can't tell over this medium whether this comment is really sarcastic or really ignorant.
c1728p9
Hi @pmaupin ,
What kind of FTDI interface did you have in mind? Would there be code on the target microcontroller to receive uart data and convert it into debugging commands to read/write memory and control the target?
As for the HID speed, me and Sam are both aware of this. So far it isn't much of a problem since at 64KB/s stepping and running is quite fast, and flash programming is limited by sector erase/write speed and not by HID (at least for the supported targets). The only operation that would be noticeably slower is reading/writing large blocks of memory. As a test I swapped out the HID interface with a CDC (serial port) and was able to achieve higher speeds, so if needed you could use that code.
The directions for regression testing are a little old right now. The project is using pytest rather than nose for testing, as indicated in the main page. The command "py.test pyOCD/test" will run the unit tests. Some of those tests will be skipped unless you have a board with CMSIS-DAP attached. Also there is another other test suite in the top level 'test' folder. These tests are fairly comprehensive and take a while to run, but also require hardware.
Martin Kojtal
@pmaupin Can you specify the FTDI chips as asked above. I believe chips which implements JTAG.
This would a good exercise to see changes to generic layers for adapting a new transfer layer. I believe @sg- meant with the comment above, adding a new transport at the moment might complicate things, to have all under one hood.
I personally would give it a shot 
Patrick Maupin
Thanks for responding! Here's some more info:
What kind of FTDI interface did you have in mind?
tl;dr: the same ones everybody else uses :-)
Any of their chips with their MPSSE (Multiprotocol Synchronous Serial Engine), which supports JTAG and SWD. This engine is present on the FT2232D, FT2232H, FT232H, and FT4232H, and probably some others.
The 2232D can easily do 8X HID speed, and the others are high-speed devices. IIRC, I've seen write speeds around 1.5MB/s using the 2232H with a LEON core with a 15 MHz TCK.
at 64KB/s stepping and running is quite fast
I'll certainly grant this won't be the main problem.
flash programming is limited by sector erase/write speed and not by HID
My test chip doesn't even have flash :-)
The only operation that would be noticeably slower is reading/writing large blocks of memory.
Bingo! And I have some co-processors and peripheral DMA engines I want to test.
As a test I swapped out the HID interface with a CDC (serial port) and was able to achieve higher speeds, so if needed you could use that code.
That may be useful. OTOH, it's yet another moving part to play with.
testing
Thanks for the info. I'll look at the test folder again.
adding a new transport at the moment might complicate things
I guess this is what I find confusing. A cursory glance at the code seems to indicate it is modular with fairly low cohesion. Is that deceptive?
I personally would give it a shot
And this is where we get back to: I've already got a working gdb remote in pure Python with a different processor (with a half-dozen internal users and some external users). The code is almost 4 years old, but I wrote it and I understand it. Do I add support for the Cortex into that, or do I write a new transport for pyOCD? There are pros and cons to either approach, which I'm trying to weigh. It is intriguing that you appear to have fairly cleanly separated the transport layer, but then it is not so intriguing if ARM insists "There can be only one!"
Thanks,
Pat
Garrett LoVerde
Hmm, I actually thought that support for the FTDI parts was already a standard feature.
I probably based this assumption on the fact that openOCD supports FT2232D, FT2232H, FT232H, etc. out of the box.
My desire to have support for these parts is driven by the fact that it more or less gives your PC the ability to act as the debugger, in addition to providing multiple serial ports for debug or testing of the target.
These parts essentially allow this cable to act as your debugger and debug serial port.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Tomasz CEDRO
FT2(2)32 are "dumb" devices, they only send bits/bytes over USB, so the Host needs to generate a bistream that FTDI chip only transports, this puts all operations on the Host side (PC), and tremendous bottleneck on USB between Host and FTDI itself.
Transport is more "protocol" used over the bistream. For OpenOCD I have proposed to call JTAG or SWD to be a transport. The LibSWD works over "bare and dumb" FT2233H device (I was using KT-LINK), but the speed is really slow due USB latency, you will not overcome that, even with asynchronous operations, because bus directions switch and single bit operations kills all the bandwidth..
CMSIS-DAP is more an architecture than transport. It uses SWD as transport. It tells you what high level operations you have available for CMSIS-DAP compliant Target. This allows moving Host part into Firmware so it uses direct GPIO (not USB) which provides highest possible bitbang throughput, while Debugger only serve high level commands.
See the DAPLink project, compare sppeeds, to see even simple cheap HIC leaves FTDI far behind. pyOCD is the bridge between GDB and the Target MCU..
Maybe I missed something and there is really a good reason to do what you want, except you are not aware of pyOCD+DAPLink, it would be good to know :-)
Garrett LoVerde
@cederom I've just been looking at it from a what I've used succesfully standpoint.
I understand the concept that when using an FTDI part the PC esentially becomes the debug "controller".
I never realized their was such a bottleneck. Thank you for the education!
Chris Reed
Closing this issue. STLinkV2 support is being integrated starting with v0.13.0b1. JLink support in coming soon. And we'll be looking at FTDI-based interface support.
Chris Reed
Closed #186.