There are some fairly powerful debugging facilities available on today’s microcontrollers — if your code crashes mysteriously, chances are, there’s a debugging interface that could let you track down the exact crash circumstances in no time. Sadly, debugging tools for these powerful interfaces tend to be prohibitively expensive and highly proprietary, thus, not friendly for hobbyists. Now, there’s a community-driven high-capability debugging platform called ORBTrace, brought to us by [mubes] and [zyp].
With parallel trace, you get a constant stream of consciousness, every exact instruction executed by your CPU. [mubes] and [zyp] set out to tap into the power of parallel trace debugging for Cortex-M processors. and the ORBTrace project was born. Relying on the Orbuculum project’s software capabilities, this FPGA-based debugger platform can do parallel trace and the more popular high-speed SWO trace – and way more. ORBTrace has the potential to grow into a powerful debug helper tool, with enough capabilities for anyone to benefit. And of course, it’s fully open-source.
The ORBTrace platform has plenty of untapped potential. There’s the battle-tested JTAG and SWD that you can already use with all the open tools you could expect. However, there’s also plenty of available resources on the FPGA, including even a currently unutilized RISC-V softcore. If you wanted to add support for any other family of devices to this debugger, sky’s the limit! And, of course, there’s cool software to go with it – for example, orbmortem, which keeps a ring buffer of instructions in memory and shows you the last code executed before your CPU stops, or orbstat, a tool for profiling your embedded code.
If you’re looking to purchase effortless feature parity with Segger or Lauterbach devices, the ORBTrace doesn’t promise that. Instead, it’s an open debugging toolkit project, with hardware available for purchase, and software just waiting for you take control of it. This project’s community hangs out in the 1BitSquared discord’s #orbuculum channel, and gateware’s advancing at a rapid pace – welcoming you to join in on the fun.
ORBTrace is a powerful tool for when your goals become large and your problems become complex. And, being a community-driven experimental effort, we’ll undoubtedly see great things come out of it – like the Mooltipass project, originally developed by Hackaday community members, and still going strong.
35 thoughts on “ORBTrace Effort: Open Tool For Professional Debugging”
Are you serious? For a <$20 25k Lattice FPGA, a <$3 64Mb NOR Flash, a <$3 64Mb HRAM, a <$2 USB I/F IC, a bunch of LDOs and buffers?
And that is not including a $33.5 shipping fee for DHL to my place (Europe)?
They probably need to cover the cost for there time developing the hardware and firmware. Which I can understand..
Exactly! Development time isn’t cheap nor is it free.
When it comes to debug tools, this isn’t an astronomical price. I think using the FPGA was more for fun (using a RISC-V softcore) than necessity. Also, you are acting like they are the ones who built them for charity no less. It’s more likely that they used a turnkey solution to have the PCB made and assembled.
While there’s no intention of registering for charitable status, there’s no huge profit in ORBTrace, I assure you! The project is about bringing SWO and TRACE into regular use, not making money. If someone can deliver working hardware for less, have at it!
Approximate commercial equivalents would be something like JTrace or ULINKPro. Those are closed source but are the things we’d recommend people to buy if they’re going to rely on their tools for putting food on the table.
The RISC-V isn’t in use at the moment…it’s available as a future expansion. The FPGA is needed because of the speed of the flows off the target…signals are generally half the clock rate of the target, DDR, so pretty tricky to pick up and process with a CPU.
Weill, compared to a $75 Black Magic Probe, it is.
BMP isn’t anything more than a $5 Blue Pill with a quarter’s worth of buffers for $75. And it doesn’t do parallel TRACE. You’re paying to support their continued development of the BMP firmware.
$120 for an ECP5 dev board with programmable power supplies is not bad even without the firmware. With firmware to do TRACE it’s a steal.
> In short: This is a project, not a product. By purchasing this you’re participating in its development.
Looks like the developer is using prebuilt sales as a way to cover development costs. But I get the impression it’s also a “You should do this yourself, instead of relying on someone else to build it” situation:
> Orbcode.org doesn’t build hardware. You’re welcome to build it yourself or find someone who is building a batch.
But i can’t for the life of me find any hardware schematics/build info.
I wrote that and almost immediatly found it. https://github.com/orbcode/orbtrace_hw It’s just a pdf, but that does seem to include some “gerbers” imbedded. I’d rather see a proper set of gerber files, or even the full source, but you can def build your own with that at least.
It was quite expensive for my budget also, but there is nothing comparable below $500 or so on the market. If you only need debugging, orbtrace is overkill for that. Tracing can easily save the money in reduced debugging time.
Closest low-cost alternative is to use a logic analyzer to capture the trace data and then decode it on PC. It works, but is quite cumbersome to set up and at least with sigrok takes a lot of CPU also (it decodes in Python). There is nothing stopping from making a faster decoder in some compiled language, I just never got around to it and buying orbtrace was easier. And orbtrace goes faster than my logic analyzer anyway.
Many logic analyzers are also just FPGAS under the skin.
I know right… because you just accumulate the parts in a pile on your desk and type:
$ make board
and the bits magically solder themselves onto the PCB, and the flash chips magically program themselves.
am sure if you did that on my desk we would have the next terminator
The whole thing is Open Source….feel free to implement it on your own FPGA. We’d recommend the ECPIX-5 board ‘cos they’re really flexible and it’s the platform the whole project started off on. If we were trying to cover the number of evenings and weekends we’ve spent working on this there would be another 0 on the price of ORBTrace :-)
The intention behind all of this isn’t to make money, it’s to make SWO and TRACE more accessible to the community…if you can do that with a cheaper approach, please have at it with our blessing and we’ll happily link to your hardware from orbcode.org. Also, if you can get hold of the parts at those prices, please post links. Availability is causing grief for a lot of people at the moment.
Can you publish the pcb gerber or similar please?
Maybe it’s just me but I don’t see any logical reason to use an expensive FPGA with a proprietary toolchain. Honestly, it seems like this would be an ideal application for the RP2040 chip.
The toolchain is all open source (Yosys and nextpnr). The flow of instructions from the target is realtime and requires about 1.1bits/instruction, so you’re looking at a 200Mbps flow if you’re using something like a STM32F427. RP2040 only supports USB-FS. There are some very cool CMSIS-DAP RP2040 implementations out there though (DapperMime, DragonProbe etc) and that would be a very good solution for someone who, for example, just wants MTB access on a M0+.
BlackMagicProbe is already such a comprehensive debugging solution, I really think adding trace to it would fix make it a complete package. Much better than having a separate tool for reading trace.
Anyway, very cool project. FPGAs are underutilised by hobbyists/small scale operations.
The Orb project was ‘born’ out of adding SWO/UART to BMP., but you cannot add parallel trace to BMP without also changing the hardware… the CPU isn’t powerful enough. ORBTrace provides that power, by using an FPGA. It can still use the blackmagic codebase for the ‘debug’ part (indeed, one of the reasons for having the RISC-V in there is so the BMP code can run onboard) but can also use pyocd or openocd if you prefer.
How does the stepping-through-the-code part work?
Is OpenOCD involved? Do I ‘target remote localhost:3333’ in gdb as per muscle memory or is there a stand-alone gdb server on the Orbtrace?
The Debug-side interface is CMSIS-DAP v1 and v2, implemented natively in gateware…no CPU required. You can hook things that ‘talk’ CMSIS-DAP to it. There are a couple of minor functions that aren’t implemented (yet) but we’ve not found any problems so far.. OpenOCD works really well and gives you up to about 1.4MBytes/sec read speed from a STM32F427 (our default ‘mule’). This means you get all the nice stuff that already comes with OpenOCB, pyOCD or whatever such as RTOS-awareness etc.
On the TRACE side we use orbuculum, not the trace capabilities of CMSIS-DAP. We were concerned that they wouldn’t keep up with the speed we can generate trace data…
Part of the reason for implementing a CPU in there was so that, eventually, something like BMP or Maven could run natively on the debug interface and publish a gdb remote interface.
So, your muscles should work perfectly, but they might have to be a bit faster :-)
For me, openocd -f interface/cmsis-dap.cfg worked out of the box.
This would be a cool application for the 2019 Supercon badge. Unfortunately I think the badge lacks the RAM.
Adrian, at the moment we only use the RAM of the FPGA (the rest is for ‘future expansion’). IIRC that badge was an ECP5-45f. It’ll work perfectly on there and the effort to port it is minimal…really just a new board pinout definition as we’ve used 45f’s during development, so the platform is already in there. Just watch out for pin voltage levels. Go for it! Ping us on the Discord for support.
I know the target chip needs to support the features, but what prevents tools like the Black Magic Probe, or Edu Mini, RealView U-Link2, etc do ETM Traces?
Would OrbTrace Mini tracing work on an FPGA’s Arm M3 (ex. SmartFusion2)?
Does OpenOCD support the advanced streaming/tracing capabilities? For example, I have an AT ATMEL-ICE debugger, which supports CMSIS-DAP/SW/JTAG but no SWO. As a result, things like ITM outputs don’t work in Keil uVision but work with a Segger debugger.
The main limitation with ‘cpu based’ debug probes is purely the speed at which trace data arrive…they simply wouldn’t be able to keep up. Not only that, but they often only have a usb-fs interface so you’re limited in the speed you can get trace back to the host. Depending on your target, you’re looking at data rates of anything like 200Mbps just for trace, and if you want itm in there as well it goes up from that figure.
ORBTrace supports high speed trace collection, and also offers SWD up to 25Mhz, JTAG generally tops out around 12.5Mbps. in reality you get a reduced return as the clock speed goes up as the target returns more WAITs to the probe…I generally use 10-12Mbps for the debug interface. 25Mbps with a stm32f427 delivers a read from ram up to around 1.4MBytes/s when using swd. YMMV.
Openocd can configure the streaming and tracing, but the flows themselves are handled by orbuculum, not via openocd (that could be changed if need be). The orbuculum mux can split apart itm and etm, so if you can convince your tooling to take itm from a file or a TCP port, I don’t see any reason why you wouldn’t be able to integrate it.
If your probe target supports etm 3.5 then it _should_ work. Obviously we’ve not tested everything out there but we’ve yet to find anything that doesn’t fly. There are even people out there using the orbuculum suite with totally ‘soft’ CPUs and verilator.
I almost ordered one (and case) but the store doesn’t take paypal.
Sorry, you are not getting my credit card info.
Tony, A laudable attitude! I don’t have anything to do with the store, that’s zyp’s affair, but it’s my understanding that everything is handled by Stripe so he never sees any of it beyond your delivery address. Ping him in the Discord and I’m sure it can be sorted out somehow….alternatively, look for one of the other solutions that’s already been discussed here; ECPIX-5 or whatever.
I’ll second what Mubes said; your credit card info is collected by Stripe Elements and doesn’t go anywhere other than directly to Stripe. If you’d still like to pay with Paypal instead, drop me an email at the address listed on the support page and I’ll handle it manually.
Super — I will.
Suggest taking a look at privacy.com, which attempts to address the concerns many of us have with handing out credit card information. They create ‘virtual’ credit cards which are locked to a merchant, and can optionally have spending limits. Also helps with privacy aspects, too.
I almost always use an individual virtual credit card from privacy.com when paying online. If the info is ever included in a breach, a) it won’t work with any other merchant, and b) I can disable just that card.
So, it’s a very nice, powerful, completely open platform, with plenty of space to grow “already baked” in the initial hardware… which you can buy or build for a very reasonable price…
I can only hope there are more and more projects like this. Well done!
Thank you very much for your words of encouragement. The ‘growth room’ that we’re not yet using (or minimally using) includes 8MBytes of RAM, the RISC-V CPU (actually a VexRSIC-V), 2 programmable voltage sources, 2 current measurements, 2 voltage measurements, 6 uncommitted GPIOs and a 70-pin expansion connector on the B-side of the PCB. We still have work to do :-) That’s just for this particular hardware build standard though…you could easily build an ORBTrace- that doesn’t have that level of flexibility if you don’t need it. We didn’t do that because we wanted the headroom and we weren’t sure which direction the project requirements would take us. There are all sorts of things we can do from this point from programmable power glitching through to onboard debug interfaces (a la BMP) and code coverage analysis. We need to be clear that this is a project not a product, and we need more hands on board to cover its possibilities :-)
Lauterbash ? is it meant to be sarcastic or funny ? It is Lauterbach and their products are another category entirely, specially the ones having Nexus or Aurora interfaces with GBytes of memory for tracing on multicore embedded systems.
Or it’s just a simple misspelling. Especially since the context in which it was used specifically points out that it’s a high end product and ORBTrace isn’t a replacement. Nothing to get steamed about.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)