Testing Raspberry Pi's New Debug Probe(jeffgeerling.com)
jeffgeerling.com
Testing Raspberry Pi's New Debug Probe
https://www.jeffgeerling.com/blog/2023/testing-raspberry-pis-new-debug-probe
15 comments
RPi specifies the target voltage would be 3.3V. This would make VCC optional. The debug port speed can vary quite a lot in SWD and JTAG.
As far as professional debuggers...
Those typically have much larger buffers, much larger transfer speed, port voltage threshold can be set higher than 5 V and even under 1 V, data and instruction trace (and often code coverage), the ability to debug multi-core (synchronous or async), recording performance monitor counters, an interface that is easier to use than gdb, built-in workarounds for unconventional attach sequences (and info sharing with manufacturers so the latest chip is supported at or before its unveiling), instruction set simulation, support for virtual targets, task/OS awareness, "unlimited" on-chip/flash breakpoints, add-ons for recording/protocol decoding/triggering based on external signals (aka scope probes), more port options e.g. Aurora, a scripting language and modularity that lets you take debugging expertise from one architecture to an entirely new one e.g. PowerPC to RISC-V, support contracts so that their customers aren't "on their own" when something isn't working with the debugger or target...
There is a huge price disparity, but for the companies with a vision to get their product to mass market with the latest chip IP, it really does not make sense to give them only JTAG wigglers and OpenOCD. If you know your domain is something straightforward from the previous generation of popular Cortex-M, a cheap probe just makes sense. A company on a budget can get away with one professional debugger and a whole collection of slower probes that you can get working with CLion or Eclipse---a bit like having a wood shop full of basic power tools plus one fancy CNC machine.
In software terms, the difference (to me) is a bit like Mathworks vs Octave, AutoDesk/SolidWorks vs FreeCAD/OpenSCAD, Adobe vs GIMP/Inkscape/Darktable. I use the cheap stuff at home, but things are often three-click trivial in the paid software that would take an hour or more to figure out on the low- or no-cost front.
-----
What to look for:
* before anything else, check if you need something that is not found on the onboard debugger, if one exists
* ease-of-use (works with your IDE, loads symbols from your toolchain, easy to manipulate memory/list instructions/watch variables/navigate stack/set complex or conditional breakpoints)
* target voltage
* port data rate
* onboard buffer size, unless your probe can stream data as fast as it reads. (The pro debuggers will use Ethernet or USB 3.0+ but still have between 0.5 and 8 GB, often)
* trace capability (speed, max port width, buffer size, supported protocols), if the chip/port supports it
* supports internal and (if needed) external flash input/output/breakpoints
* if needed, works with multicore (SMP, AMP, heterogeneous AMP)
* data disassembly, instruction set simulation
* lets you do energy profiling or performance monitoring, if important
* advanced hardware techniques, like adjusting the exact timing and voltage of each debug and trace pin independently so you can still trace on a board with less-than-optimal EM design (mismatched trace lengths, weird pin impedances)
* software techniques for speeding up data transfer (computing checksums to skip unneeded flash I/O when a target has this info available)
* existence of (and conformance to) any license restrictions
-----
You'll find the cheapest USB things just use USB 1.2 (1.5 MB/s), 3.3 or 5 volts which is fine for a lot of popular targets, can still read SWO, might be able to read an onboard trace buffer, let you connect via a gdb server to your preferred IDE, can do the basic JTAG/SWD communication. You either get jumpers or the right ribbon cable for your target, which would usually be MIPI-10 or maybe ARM-20 (so you basically need one cable plus an adapter PCB if you plan to debug many different board types and not do extensive tracing)
I don't know enough about the free scene, but I suspect that scripts are what determine whether a Cortex-M is supported in 90 percent of cases. If you need to do a weird JTAG sequence on a second access port, a script will almost always open that door. If you need to hold the clock line high while communicating serially via TDO and TDI? That's a case that might not be supported by a 20 dollar debugger.
As far as professional debuggers...
Those typically have much larger buffers, much larger transfer speed, port voltage threshold can be set higher than 5 V and even under 1 V, data and instruction trace (and often code coverage), the ability to debug multi-core (synchronous or async), recording performance monitor counters, an interface that is easier to use than gdb, built-in workarounds for unconventional attach sequences (and info sharing with manufacturers so the latest chip is supported at or before its unveiling), instruction set simulation, support for virtual targets, task/OS awareness, "unlimited" on-chip/flash breakpoints, add-ons for recording/protocol decoding/triggering based on external signals (aka scope probes), more port options e.g. Aurora, a scripting language and modularity that lets you take debugging expertise from one architecture to an entirely new one e.g. PowerPC to RISC-V, support contracts so that their customers aren't "on their own" when something isn't working with the debugger or target...
There is a huge price disparity, but for the companies with a vision to get their product to mass market with the latest chip IP, it really does not make sense to give them only JTAG wigglers and OpenOCD. If you know your domain is something straightforward from the previous generation of popular Cortex-M, a cheap probe just makes sense. A company on a budget can get away with one professional debugger and a whole collection of slower probes that you can get working with CLion or Eclipse---a bit like having a wood shop full of basic power tools plus one fancy CNC machine.
In software terms, the difference (to me) is a bit like Mathworks vs Octave, AutoDesk/SolidWorks vs FreeCAD/OpenSCAD, Adobe vs GIMP/Inkscape/Darktable. I use the cheap stuff at home, but things are often three-click trivial in the paid software that would take an hour or more to figure out on the low- or no-cost front.
-----
What to look for:
* before anything else, check if you need something that is not found on the onboard debugger, if one exists
* ease-of-use (works with your IDE, loads symbols from your toolchain, easy to manipulate memory/list instructions/watch variables/navigate stack/set complex or conditional breakpoints)
* target voltage
* port data rate
* onboard buffer size, unless your probe can stream data as fast as it reads. (The pro debuggers will use Ethernet or USB 3.0+ but still have between 0.5 and 8 GB, often)
* trace capability (speed, max port width, buffer size, supported protocols), if the chip/port supports it
* supports internal and (if needed) external flash input/output/breakpoints
* if needed, works with multicore (SMP, AMP, heterogeneous AMP)
* data disassembly, instruction set simulation
* lets you do energy profiling or performance monitoring, if important
* advanced hardware techniques, like adjusting the exact timing and voltage of each debug and trace pin independently so you can still trace on a board with less-than-optimal EM design (mismatched trace lengths, weird pin impedances)
* software techniques for speeding up data transfer (computing checksums to skip unneeded flash I/O when a target has this info available)
* existence of (and conformance to) any license restrictions
-----
You'll find the cheapest USB things just use USB 1.2 (1.5 MB/s), 3.3 or 5 volts which is fine for a lot of popular targets, can still read SWO, might be able to read an onboard trace buffer, let you connect via a gdb server to your preferred IDE, can do the basic JTAG/SWD communication. You either get jumpers or the right ribbon cable for your target, which would usually be MIPI-10 or maybe ARM-20 (so you basically need one cable plus an adapter PCB if you plan to debug many different board types and not do extensive tracing)
I don't know enough about the free scene, but I suspect that scripts are what determine whether a Cortex-M is supported in 90 percent of cases. If you need to do a weird JTAG sequence on a second access port, a script will almost always open that door. If you need to hold the clock line high while communicating serially via TDO and TDI? That's a case that might not be supported by a 20 dollar debugger.
I do wish I had something more than the on-chip debugging USB JTAG setup the ESP32-S3 has (at work), but to be honest it works well enough for what we need. And it works well with Nim, which is nice!
I would rather buy original STLink than this debug probe from two simple reasons - SWO and Reset.
SWO: Does exactly what UART-TX would do and more. And the most important thing is that you are not sacrificing UART port for debugging.
Reset: Some targets are stubborn and you can't connect anytime, but you need to connect "under reset". Impossible with this probe.
SWO: Does exactly what UART-TX would do and more. And the most important thing is that you are not sacrificing UART port for debugging.
Reset: Some targets are stubborn and you can't connect anytime, but you need to connect "under reset". Impossible with this probe.
I find it fascinating to see what the Foundation is turning its mind to now it has a seemingly high-volume, reliable supply of its house-design ARM chip.
I wonder if the future of Raspberry Pi products will be going even lower-end, rather than dealing with the complexities of making a competitive Pi n+1
I wonder if the future of Raspberry Pi products will be going even lower-end, rather than dealing with the complexities of making a competitive Pi n+1
The problem - as always - with all the clones is that their ecosystems are either immature or are complete crap. Most of the Rockchip knockoffs are technically superior at a better price point, and most importantly, available for purchase, but their websites are hacked-together Chinese clones with broken downloads, non-verifiable server OSes, and zero documentation.
RPi has a foothold primarily due to the community and software support. I'd love to see that get broken up, but building that took years, which is not what most fly-by-night places and clone shops are interested in doing. I say this as someone who largely depends on RPi 3 and 4 models for embedded work and would prefer to switch to something like oDroid (and we have to some degree), not necessarily as someone who is an RPi lover.
I hope that the foundation's supply is for real and the pricing gets down to normal market rates.
RPi has a foothold primarily due to the community and software support. I'd love to see that get broken up, but building that took years, which is not what most fly-by-night places and clone shops are interested in doing. I say this as someone who largely depends on RPi 3 and 4 models for embedded work and would prefer to switch to something like oDroid (and we have to some degree), not necessarily as someone who is an RPi lover.
I hope that the foundation's supply is for real and the pricing gets down to normal market rates.
At least with the rockchip-based designs you can get the TRMs for the SOC.
https://github.com/Hao-boyan/rk3588-TRM-and-Datasheet https://opensource.rock-chips.com/wiki_Main_Page
For the raspberry Pi 4b, the publicly available documentation for the BCM2711 SoC is laughable, barely 160-odd pages long and missing key details (such as which timers are accessible from the ARM core, and which are accessible from the GPU).
P.S. if anyone knows where to find the full TRM for the broadcom BCM2711, I'd be really grateful if you got in touch or sent me the pdf.
https://github.com/Hao-boyan/rk3588-TRM-and-Datasheet https://opensource.rock-chips.com/wiki_Main_Page
For the raspberry Pi 4b, the publicly available documentation for the BCM2711 SoC is laughable, barely 160-odd pages long and missing key details (such as which timers are accessible from the ARM core, and which are accessible from the GPU).
P.S. if anyone knows where to find the full TRM for the broadcom BCM2711, I'd be really grateful if you got in touch or sent me the pdf.
I've switched to using the pine64 boards for exactly that reason. All of the RPI model <X> boards feel like they're targeting hobbyists who want to build a retropi setup or school project and just need working software.
The pine boards are far more open, and the whole company is just "we give you the hardware, you self serve the software". They have a few good "pi alternatives", and some more "exotic" stuff. I've been playing around with their ox64 board and am enjoying it so far
The pine boards are far more open, and the whole company is just "we give you the hardware, you self serve the software". They have a few good "pi alternatives", and some more "exotic" stuff. I've been playing around with their ox64 board and am enjoying it so far
good luck. not to mention not even full schematics of rpis.. being in broadcoms bed and not even being able to buy standalone chips. and making hobbists think its an open platform when its one of the furthest away from that, ugh.
the effort is better spent on nearly any other arm soc
the effort is better spent on nearly any other arm soc
I smell an opportunity here. The first company to ship a chinesium Pi clone that's ServerReady is going to be a serious contender.
This is tangential, but when did Raspberry Pi get so expensive? I'm in the EU and starter kits that used to cost maybe €50 are the far side of €250 or even €300. The bare boards are over €200 (!)
This happened when commercial and industrial corporations started using them in bulk for IoT platforms. The original price made it very attractive for their BOM and now they are willing to pay >$100 per RPi because put Docker and NodeRed on them and then they sell them for $300-400.
In short, supply chain issues have made a market for scalpers.
>The Debug Probe adds on SWD and has a separate port for that, so it competes also with SWD devices like this knock-off of the SEGGER J-Link BASE Debugger, which costs $500!
I think a better comparison would be something like CMSIS-DAP (which also gives you JTAG)
https://www.l-tek.com/web-shop/cmsis-dap-debug-probe/
I think a better comparison would be something like CMSIS-DAP (which also gives you JTAG)
https://www.l-tek.com/web-shop/cmsis-dap-debug-probe/
The comparison with the Segger J-Link is not entirely fair if you use a fake J-Link instead of the real one. It is an expensive product but the value also sits in the included software and excellent support. In a professional setting it is definitely worth the money.
I feel like we should expect JTAG support (for ARM7/9/11 and I think some other misc devices, but I could well be making up that last part) for the Pi Debug Probe eventually? Maybe there's some hardware complexity of the bus that makes this hard, but since this is just a Pico, it feels like it should likely be flexible enough. (By contrast the SWD port it does have is for thew newer ARM Cortex chips.)