Debugging Hardware in Prop2?

Damien Allen

A question to parallax, will there be any specific hardware in the prop2 to facilitate debugging similar to the PIC? These along with a few other features may increase market penetration because it enables the prop to set itself apart from competitors as it·would have·all the basic features of a modern micro such as a debug interface and on-board flash etc and then it can leave the pack behind with its multiple cores and video hardware.

I know something similar could be constructed by using a cog and some PC software, but why waste a cog? what if your program/application required all the cogs on the prop2?

What are others thought?

Sorry for starting yet another prop2 discussion but I don't recall it being mentioned elsewhere.

Just my 2 pence worth...

Damien

Mike Green

Damien,
If you read the very long thread on the Prop II, you'll see that on-board flash is not do-able. It's simply not physically compatible with the manufacturing processes needed for a chip of this size and complexity and cost goals.

Regarding special on-chip hardware for debugging ... It would have to be very very simple, yet powerful to justify its inclusion. There'll be plenty of memory (256K) and plenty of cogs (16) to devote some of those resources to debugging. Again, how much memory and how many cogs would you give up to provide the chip area for dedicated debugging hardware when some potentially general purpose hardware can do the same task? It's not free.

hippy

Some sort of debugging hardware in each Cog would be useful. Intrusive methods of debugging work ( adding code to dump data ) and so too does LMM interpretation of the Cog code itself but none are as nice or as easy to use as non-intrusive background debugging would be.

To prevent code theft, each Cog would have to enable debugging itself and I visualise it setting the hub address of where control, status and 512 longs of data dumped from cog would be ( hard-wired by the code in the Cog or passed in via PAR ). That would just be two extra instruction overhead, the cleverness all being in the debugging code written in Spin.

Just being able to single-step and get back the current Cog's data would be a good start. Being able to set breakpoints ( an extra 'hidden bit' making the Cog Ram 33-bits ? ) would allow full-speed execution until breakpoint. One or more 'breakpoint address match' registers could work but not quite so wonderful.

I find debugging an errant Cog incredibly hard and none of the existing tools have worked well for me. I've ended up doing what I've described above by coding the debugging interface in the Cog ( eating up desperately needed Cog memory ) and then putting calls to that throughout the code. That doesn't always help when wanting to single step to see where or why code execution is going some place unexpected. It's a long laborious task of adding a debugging call, moving it forward.

There's got to be a better way.