WiFi-Probe

[rgrr]

Cut the CMSIS-DAP/debug console communication in the middle and put WiFi in between.

Pico at the target would be the AP, Pico at the host would be the STA. That means that the two Picos would create their own WiFi net.

Two dedicated Picos are required then.

Another approach could be to book the target Pico into the WiFi network and the host PC accesses the target Pico via WiFi which would require a special application on host side.

[JustAnother1]

Another approach could be to book the target Pico into the WiFi network and the host PC accesses the target Pico via WiFi which would require a special application on host side.

Another option would be to implement GDB Server protocol. This way the Host would not need a special application. It could also skip OpenOCD/pyOCD. That might also improve the performance, as less back and forth between Host and probe is needed.

See Black Magic Probe for reference implementation.

Would that be an option?

[rgrr]

I understand. Using the gdbserver protocol would give WiFi without additional cost.

There is already a picoprobe around which exactly does that: https://github.com/essele/pico_debug. Very nice project, but I wasn't happy with stability - one of the reasons why I forked my project.

I also thought about implementing a gdbserver into my probe, but that's some effort to do. And I have the feeling, that CMSIS-DAP is more generic (for the ARM platform) and thus selected this the way to go.

But if you want to implement a gdbserver into yapicoprobe, feel free to submit a PR.

[JustAnother1]

A gdbserver implementation would go directly to swd (and JTAG) and not through CMSIS-DAP. gdbserver can be more generic as also non ARM targets can be supported. And yes it will be quite the effort.

The gdbserver also needs an communication interface to the host. Another serial interface (the 3rd or 4th) might be a bit confusing, right?

One solution would be to implement a USB-Ethernet protocol. The host would think that an USB to Ethernet adapter was plugged in with a Ethernet cable connected and some server on the other side of the cable. This way the different serial ports could be replaced by different port numbers.

Downside is that is would add some overhead to the USB communication. I also don't know the best IP address to use for the virtual server.

Another solution might be a "config.txt" file on the mass storage device. If the User reads this file it is a plain text file with current status information and settings like "gdbserver = off". If the file gets written to the firmware checks the content. If some settings changed then the firmware resets and boots with this new configuration in use. This way the user could only have the interfaces active that he/she intends to use.

Downside is that some editors make backup copies of files that they change. That might complicate the implementation a bit.

I think we should start with a solution where the gdbserver interface is an "experimental" additional feature that then gets better over time. This way it would also be easy to remove if this effort fails.

What do you think?

[rgrr]

A gdbserver implementation would go directly to swd (and JTAG) and not through CMSIS-DAP. gdbserver can be more generic as also non ARM targets can be supported. And yes it will be quite the effort.

You are moving complexity from the tool side into the probe side. Of course you gain more flexibility if everything is in your own hands. But check what effort e.g. DAPLink does to control just ARM targets. Still CMSIS-DAP on the host side.

But if you want to do a black magic probe implementation for the RP2040, go ahead.

Concerning IP address and so on: why not limit to a PicoW n the first step?

[JustAnother1]

Concerning IP address and so on: why not limit to a PicoW n the first step?

That does not solve the issues. It just pushes them down the line and creates new ones.

I was looking for the best way to integrate gdbserver into yapicoprobe.

[rgrr]

in a first go I'ld use PicoW with a static configuration. I think the TCP configuration is not the major problem, it is more like sugar coating.

Of course, you could also use RNDIS with a fixed configuration.

[JustAnother1]

The benefit of gdbserver in the probe that I see is to make it easier for the user. It skips the step of needing to configure OpenOCD/pyOCD. But now the probe needs to be configured (SWD clock speed,...). But the probe needs to be configured anyways (connect com port to host software, serial terminal,...)

I agree that "TCP configuration" is something that can be solved in different ways, and therefore should not be a blocker. But it also complicates things unless we find a clever solution.

My aim is to make the overall process simpler to be setup. The currently discussed design is a lot of work and complicates things.

[rgrr]

I fully understand and partially agree concerning the tools complexity. But this gives you flexibility as well. pyOCDs API is a nice example: https://github.com/pyocd/pyOCD/blob/main/docs/api_examples.md

Configuration of course adds complicated things, but for the beginning static configuration works well. I think this is established.

Awaiting your PR ;-)

[JustAnother1]

porting gdbserver from pico_debug or from Black Magic Probe is one thing. Fitting it into yapicoprobe is another thing.

I don't think that µC auto detect makes much sense. Also the flash algorithms and other settings vary from chip to chip. Like OpenOCD the firmware should therefore only have a framework and would then need configuration information for the specific chip used. Therefore configuration is necessary.

Static Ethernet configuration will work only for a group of users. If you go with 192.168. some home users will get conflicts with their home routers. If you go with 10.0. then employees at big companies will run into issues. And this only works for RNDIS. On the Wifi side the routing is more complicated as you need to have an IP in the users Wifi address space. Otherwise the packets wont find there way from a Ethernet connected PC through the Wifi router to the picoW. With DHCP on the Wifi the issue becomes that the user now needs to know the address that got assigned. Some routers may give a network view, pinging the whole subnet might be another way. But routers and firewalls complicate it here and there. Having each user compile the firmware and provide the IP address at compile time would solve most issues, but that is a user experience nightmare.

Having a firmware that can do DAP and gdbserver and RTT and UART and sigrok and so on is nice. But ideally I would like to deactivate everything I don't use. I want all the functionality if I need it. And I can manage complicated configurations. But for a tool that I "only" want to use, I only want to configure it once and then forget about it.

I work on different projects and have to switch from one µC to another often. It is OK if I need to reconfigure my debug setup for each new project. But only once! If I come back to it months later I just want to go back to that configuration and it should work again. Exactly as before. New versions of tools that changed the configuration settings, sometimes even having to install tools, are pain points. That the picoprobe needed its own openocd version, or that it now changed from its own protocol to dap cause work that would not be necessary.

Ideally I would want a project specific uf2 file or a uf2 and a config file. Then I could take a pico flash the uf2, apply the config and the probe would be perfectly set up for that specific project. The uf2 and the config file could then just live in the projects source code repository and everything is fine. That might mean that that probe then only has DapV2 and UART and nothing else. Or DapV2 and RTT or only gdbserver and nothing else.

A firmware that can do absolutely everything, but has 5 serial ports exposed to the PC and I need to figure out by myself which one I need to use and which I can ignore is a bad solution. I will need to use different parts for different projects. It has more features, but the user experience is much worse.

A new feature that I would want is en environment/tool support to get new chips supported. For example I have a chip that is currently not supported and then some algorithm would try to gather information. Usually the debug part is easy to get working. A memory map could probable be found by try and error. But a flash algorithm (programming the flash) currently has a chicken and egg problem. With a working debug environment and the documentation is is easy to program such an algorithm, but without the debug environment? Having something that allows to write values to registers, read values from registers or memory could help figuring things out. If pyocd can do such things that would be cool. But the link you shared seems to be more a "write a python script instead of clicking the debug button in your IDE" kind of thing.

If you just want to add gdbserver to the yapicoprobe feature list then just copy the code from the pico_debug project. I then have to start my own project. If we can find good solutions to improve the user experience towards a configure once for rock solid experience then we can talk about pull requests.

[rgrr]

Hmmm... I'm a little bit overwhelmed by the length of your post.

To make one point clear: you were asking for an integrated gdbserver. Not me.

Also you want a stable configuration so you can pick up work where you left. My intention too. To my opinion this is asking for a "dumb" probe. "Intelligence" and configuration is on the host side, in tools like pyocd or openocd.

If you want only one CDC exposed to the host to reduce confusion: I agree. The Pico Debug Probe version currently has just two instead of three CDCs. Should be a snap (for you) to put the probe and target output into one CDC. This has currently no priority for me, because under Linux I can clearly distinguish between the two CDCs.

Yapicoprobe does not require a special openocd version for the RP2040. PlatformIO delivers (with some additional help) a very good debugging environment, but you are currently stuck at version 0.11. This openocd version can be used under Eclipse as well. The special thing of that openocd is that it handles the dual core of the RP2040 better than unmodified versions.

You also found out, that the flash algorithms are target dependent (not only the flash algorithms). This is true and this is the reason why the probe only supports RP2040 & some nRF52xxx for MSC. But other ARM targets should be no problem via CMSIS-DAP. If you have a look at pyocd or DAPLink you will find flash algorithms for a lot of targets, so the chicken/hen problem has been solved in most cases. Actually I'm adding algorithms and auto detect if there is a requirement on my side. But I'm open if anybody wants support for another device.

So feel free to modify (or not) the sources and create pull requests.

[JustAnother1]

Also you want a stable configuration so you can pick up work where you left. My intention too. To my opinion this is asking for a "dumb" probe. "Intelligence" and configuration is on the host side, in tools like pyocd or openocd.

I disagree. yapicoprobe is not dumb enough to be treated like an USB cable. Therefore with intelligence on the host the user has two things to configure. Picking the support for just the one chip you are currently using into the probe could eliminate the second thing that needs to be dealt with. Just handing a configured pico to a colleague is easier than to point him to a howto guide that explains how to install the correct version of OpenOCD.

If you have a look at pyocd or DAPLink you will find flash algorithms for a lot of targets, so the chicken/hen problem has been solved in most cases.

I have to disagree again. Supporting hundreds of old chips does not help if the new or exotic chip is not supported. Renesas RA*, Renesas S124, RISC-V, ... What I described was intended as a help to self help in such situations.

I would appreciate it if more vendors would make their chips work with OpenOCD or other open source solutions instead of keeping the documentation under NDA and providing a dev board with Segger on board. The vendor pays about $5k to segger. segger has a team that implements the flash routine (they are currently hiring new people for this position) and the user pays for that service when buying a J-Link and paying more than the $5 that a pico costs.

For companies it makes sense to "outsource" this to segger. But for maker/hobby use the price of a J-Link is not so easy to swallow.

[rgrr]

Just handing a configured pico to a colleague is easier than to point him to a howto guide that explains how to install the correct version of OpenOCD.

Unfortunately this problem cannot be fixed on probe side. This has to do with handling of multi-core by gdb as far as I understood.

I have to disagree again. Supporting hundreds of old chips does not help if the new or exotic chip is not supported. Renesas RA*, Renesas S124, RISC-V, ... What I described was intended as a help to self help in such situations.

To be honest those MCUs are not target of the project. In fact it is limited to CMSIS-DAP, thus Cortexes AFAIK.

I agree with your Segger comment. In my company we are using Nordic DKs which contain the Segger chip. I'm not a fan of that and that's one of the reasons for my project. May be I can establish it at work.

[JustAnother1]

Just handing a configured pico to a colleague is easier than to point him to a howto guide that explains how to install the correct version of OpenOCD.

Unfortunately this problem cannot be fixed on probe side. This has to do with handling of multi-core by gdb as far as I understood.

gdb has no issue with handling multi core. It can be fixed by using a gdbserver probe as it was solved by a change in OpenOCD. The functionality of OpenOCD is to convert the DAP into gdbserver!

The RP2040 uses the SWDv2 protocol. In this protocol the SWD lines can be shared between several chips. The SWD communication starts by selecting the chip one wants to talk to (will probably be a major issue for auto detect once more chips do this) it also has some new registers in the protocol. RP2040 uses this to put both cores on there. So the addressing as seen from the probe is the same as if two single core chips were connected to the same SWD lines.

My understanding is that RP2040 is the first to use SWDv2 and therefore they needed to patch support for it into OpenOCD. Please correct me if I'm wrong.

I agree with your Segger comment. In my company we are using Nordic DKs which contain the Segger chip. I'm not a fan of that and that's one of the reasons for my project. May be I can establish it at work.

To avoid miss understandings. Segger is a good company. They do a lot of very interesting things. And also have free offerings (RTT) and fair license terms. But they also seem to avoid open source software and are therefore sometimes hard to integrate smoothly. If you want to use Segger tools the way they want to be used and someone else pays the bill then it probably is a very good experience.

[rgrr]

I have to admit that I'm not happy with RP2040 support. A special OpenOCD 0.11 for the RP2040 is almost not acceptable, because it hinders further development on probe side (e.g. Auto target type identification of pyocd).

But I'm convinced, that the pyocd and openocd guys know about their flaws concerning support of multi core devices (and perhaps SWDv2). And therefor I'm hoping, that better support will flow into those tools.

Perhaps it is more efficient to put effort into the adaption of the tools. With the response times of the pyocd project I have made good experience, so this may be the way to go.

[JustAnother1]

Last thing I heard was that OpenOCD 0.12 would include RP2040 support. And the release note seems to support that. Did you test OpenOCD 0.12 ?

[rgrr]

Yes, I did. It is working basically. If you are using e.g. PlatformIO Arduino/RP2040 to generate a simple program for the RP2040, upload etc works.

But if you single step through the program you will stuck soon because the second core is stopped and at some place the framework waits for the second core for sync. AFAIR the same is true for pyOCD.

This is working with the rapsi version of OpenOCD 0.11.

Currently I'm testing everything with a Nordic DK (PCA10056), so it actually doesn't matter to me.

[rgrr]

Hello Lars, perhaps for you of interest as well: https://mcuoneclipse.com/2023/04/08/open-source-picolink-raspberry-pi-rp2040-cmsis-dap-debug-probe/ (comment section)

[JustAnother1]

https://mcuoneclipse.com/2023/04/08/open-source-picolink-raspberry-pi-rp2040-cmsis-dap-debug-probe/ (comment section)

I mostly agree with Erich. My intention wasn't to just port BMP to RP2040. As previously stated I only want a framework on the probe and have a board/chip specific configuration. The SWD protocol and also JTAG are not intended to support auto detection. They both assume that the user knows the chip. Therefore and because of board specific stuff such as the QSPI flash on the Pico we will always need some sort of configuration for the device/board we want to debug.

Both OpenOCD and PyOCD understood that. And yes Python is better than TCL, but I user OpenOCD anyway.

I think the biggest issue right now is to get the debug system configured. We need to make it easier to figure out the configuration for a new board/chip. An easy way to share working configurations with others would also help.

My intention was to use the Mass Storage for configuration. But it is broken #41.

[rgrr]

Ich finde nicht, dass die Konfiguration das größte Problem ist. Sie ist sicherlich ein Problem. Aber man kann wie immer mit einer statischen Konfiguration anfangen.

Ich sehe viel mehr das Problem darin, dass man alle Kommandos des gdbservers korrekt implementieren muss (oder gibt es da unterschiedliche Level?). Und das Ganze dann noch multicore. Das ist m.E. ein "netter" Job. Ist zwar schon teilgelöst, Du möchtest aber offensichtlich die generische Variante (die konfigurierbar ist).

Zu Überlegungen bzgl Konfig speichern: die MSC ist aktuell ja nur virtuell. Da müsste man also auch anpacken.

[JustAnother1]

Ich finde nicht, dass die Konfiguration das größte Problem ist. Sie ist sicherlich ein Problem. Aber man kann wie immer mit einer statischen Konfiguration anfangen.

Mit Konfiguration meine ich nicht die Netwerk Konfig (statische IP) sondern die Chip/Board spezifischen Einstellungen. Das statisch zu machen würde bedeuten nur ein Board debuggen zu können. Außerdem wollte ich zum testen erst mal die DAP Interfaces und sigrok deaktivieren können.

Ich sehe viel mehr das Problem darin, dass man alle Kommandos des gdbservers korrekt implementieren muss (oder gibt es da unterschiedliche Level?). Und das Ganze dann noch multicore. Das ist m.E. ein "netter" Job. Ist zwar schon teilgelöst, Du möchtest aber offensichtlich die generische Variante (die konfigurierbar ist).

gdb server ist zum Beispiel hier definiert: https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html Viele Funktionalität ist und bleibt also im gdb. Aber ja ist nicht gerade mal an einem Nachmittag runter gecoded. Deswegen ja erst mal als experimentelles Feature rein. Damit dann erst mal die wichtigsten Funktionen implementiert werden können und man dann schritt für schritt alles implementiert.

Zu Überlegungen bzgl Konfig speichern: die MSC ist aktuell ja nur virtuell. Da müsste man also auch anpacken.

Aktuell ist mein Problem das ich noch nicht komplett durch den Code durchblicke. Ich habe schon mal ein Virtuelles MSC gebaut auf einem AVR. Ist immer noch kommerziell im Einsatz für genau so eine Konfig-Geschichte. Ich wollte einfach auf einem funktionierendem Stand aufbauen.

Wenn da aber noch mehr im argen liegt macht es vielleicht Sinn wenn ich ein separates Projekt für die gdbserver Geschichte starte. Dann kann ich auch cMake und Ninja raus schmeißen.

In meinem github Profil ist eine Email Adresse.Ist vielleicht passender für private Diskussionen ;-)