www.vitenka.com | ToothyWiki | Vitenka | RecentChanges | Login | Webcomic I'm looking for a MIPS debugger which closely fits the following requirements. This page is largely so that I can keep my thoughts about it in one place - but if anyone has any suggestions, they would be most welcome.
Price is an object, but this isn't a home project. A couple of thousand euros for five or six units would be ok. So long as we're sure it's good.
VITAL
Debugger must not use much memory or processor resource. Ideally, we should be able to run at DVD 16x whilst still counting watchpoint hits or waiting for a breakpoint.
Running through debugger must not cause different execution paths from running from Flash. This means that incoming interrupts etc. must be slowed down.
Do MIPS do any sort of development hardware or in-circuit emulation you could use? Those two requirements would seem to me to be quite hard to find in a software-only debugger; not that I've much experience. Bear in mind also that you will get different memory layouts (and hence may get different memory allocation patterns and hence execution paths) on builds with and without symbols. - MoonShadow
Yes, sorry - should have been clear. This would of neccesity be some kind of box that attaches to our debug boards. We're quite used to that. Memory allocation shouldn't change (not that we do any dynamic allocation anyway) since all of the map files are available. (ie. the PC would be doing the translation to symbols, not the mips) I'm not too concerned with small changes in performance - we need a bit of spare overhead anyway. But if it takes more than, say, 1% of CPU time, then we're in trouble - even worse if using the debugger impacts memory bandwidth. --Vitenka
Running through the debugger must be at least as fast as using flash or btlaunch. Preferably it should take only a few seconds to launch.
Debugging must survive across a system reset. Under UDMA on XP it is not possible to stop and restart the drive without resetting the machine. Also startup behaviour is a major source of debugging requirement.
Features (in order of priority)
All the usual debugger features - variable watch, memory and stack examination, breakpoints, view assembly and source code position.
Step BACK from a breakpoint or ASSERT
Handle multiple threads - (using MX) - when breakpoint show where each thread was
Timing information. Over a set period, how often was a particular point hit. Processor utilisation / memory bus utilisation information.
Retain breakpoints across builds - don't want to have to set break on ASSERT routine again
Trigger when variable attains a given value
Heavily desired but infeasible (in order of priority)
When the test team sees an assert, generate some form of log or state dump which allows the debugger to fire up a drive into that state again and debug from there.
Change variable values and continue running
Whenever I see this page, I wonder what a debugged Vitenka would be like. My mind works oddly. Sorry. --Jumlian
Pretty badly defraggled, I should think. --Vitenka