4 ms·
Cortex processors have a tracing functionality which allows capturing the entire instruction and data stream of the processor, allowing rr-style debugging. The
by rcxdude 6y ago
Cortex processors have a tracing functionality which allows capturing the entire instruction and data stream of the processor, allowing rr-style debugging. The main problem is this is almost always a very high-bandwidth stream which required dedicated pins on the microcontroller and a specialised (and usually expensive) adapter to collect. I've never actually seen it used, I don't know how many embedded developers actually use it (the only place I've heard tell of it being used is inside ARM). It's possible there's some configuration which only records the minimal trace needed to reconstruct the trace later in a way that is accessible to the software running on the chip (allowing extracting the data without needing a debugger attached), but I've not seen it, and the details of this functionality seem to vary substantially across different devices.
- joezydeco 6y agoThe go-to companies for these devices are Segger and Lauterbach. I'm a Segger user for JTAG debugging, although it's rare that the shops I work in will have a J-TRACE device on the shelf. J-TRACE is the thing you buy when it's 5 minutes to production and your hair is on fire and you can't figure out what the problem is. Which is why Segger prices it at $2,000.
- db48x 6y agoYea, that’s how program recording is done natively by GDB as well; it inserts a breakpoint after every single instruction, and records the the state of the program after every one. It’s mind–bogglingly slow, and the log files are gigantic. You generally have to limit it to record only a few instructions, generally tens of thousands rather than billions, in order to get any use out of it. At least if you can do it in hardware then it doesn’t have to be slow, even if the recorded state is still huge.