Question on debug / system facility
78rpm
Posts: 264
in Propeller 2
Does the facility currently exist, or is it planned for, to provide a more detailed hardware debug assist for notifying developers of malfunctioning software? I think this is particularly applicable to new mcu users and specifically for the educational aspect of Parallax's endeavours. The debug output could be directed to a serial terminal by software monitor, or to any pin to drive a led.
Extra registers will be required per cog, below or above hub space, to permit monitor software to report. One word or long per cog, these could be implemented as bits written on the fault occurring, they are assembled into word or longs on a per cog basis. The read resets all the bits. All of the per cog bits are ORed together, all of those bits are ORed together for an error indicator, it could even trigger an interrupt event somewhere.
Additionally if the error indicator is set, two longs of OUT pin masks, to be ORed with the OUTA and OUTB if desired by the user.
To the user, all will be read only except the pin masks which are R/W.
These hardware fault detects are applicable in cog, lut and hub exec modes:
These two are for lut only
Extra registers will be required per cog, below or above hub space, to permit monitor software to report. One word or long per cog, these could be implemented as bits written on the fault occurring, they are assembled into word or longs on a per cog basis. The read resets all the bits. All of the per cog bits are ORed together, all of those bits are ORed together for an error indicator, it could even trigger an interrupt event somewhere.
Additionally if the error indicator is set, two longs of OUT pin masks, to be ORed with the OUTA and OUTB if desired by the user.
To the user, all will be read only except the pin masks which are R/W.
These hardware fault detects are applicable in cog, lut and hub exec modes:
PC - (cog) hits special registers address
PC - (lut) hits past top of lut address $400
PC - (hub) hits top of ram
Address - location of non-existent memory
< $0 - indexed memory access effectively < $0
Init - init performed for loading but no exec has been invoked
Halt - halted by instruction - desired by user
PC - (lut) hits past top of lut address $400
PC - (hub) hits top of ram
Address - location of non-existent memory
< $0 - indexed memory access effectively < $0
Init - init performed for loading but no exec has been invoked
Halt - halted by instruction - desired by user
These two are for lut only
Read glitch
Write glitch
Write glitch
Comments
There is no dedicated debug hardware.
And there are multiple schools of thought on that too. Having some JTAG thing that just dumps it all out is kind of expensive in silicon. That school wants a log of everything to be analyzed later on.
Well, the other school is authoring test cases, coding for them to factor out as much of the trouble as possible, and measuring to understand where other trouble may lie. A lot can be done on a multi-core chip and a scope. Because there are independent cores, one can also use one to look at the behavior of another, or compartmentalize things in ways that prevent faults in the first place.
You can use a monitor and data dumps, if you want. Or, single step it with a clock, or measure, or test...
Almost - there is no background debug but there is a fast serial link and a breakpoint and single step interrupts.
That means a tiny debug stub will be able to single step and memory dump at high speed.
PC side SW can be full screen SFR & memory map, it is only sw
A more interesting question is, what is needed for that high speed link ?
Another P2 could manage part of the transport, but lacks HS USB, so a FT232H or FT2232H may be needed for the USB bridge, maybe with a P2 for highest performance debug.
Or maybe a P1 and FT245, as used in FPGA boards is 'good enough' ?
However it goes, what we do have now will do quite a bit beyond a monitor type level of functionaity.
Have you ever found any non-trivial bug in a real-time, embedded, multi-core micro-controller/micro-processor application with any kind of debugger or in circuit emulator?
My experience of such things is that a debugger or ICE does it's best to hide or confuse the issue at hand.
There is a reason why we have the term "Heisenbug".
Now, you may be used to using things like GDB. At the end of the day that is just a debug monitor that talks back to some host so you can match up code addresses with lines of source code.
In short, I think most bugs can be found by understanding your language and program. The hard bugs evade debuggers and in-circuit emulators. That's when the ability to light up a LED from any COG is invaluable. Get the scope and logic analyser on there.
Of course a Prop COG can be a logic analyser for any other Prop COG.
I use a debugger all the time, and find MOST bugs with it. Yes there are bugs that the debugger doesn't help with, but they are few comparatively.
Throwing in your limiting specifics of "real-time, embedded, multi-core micro-controller/micro-processor" is just silly. Yes there are bugs that a debugger won't help with in this specific case, but there are a great deal of bugs that it will help with.
On P1, I use PASD quite often for debugging PASM. I often wish there was something better. I am really glad that Chip has added some debugger friendly features to P2, it's going to make developing on it much better.
There are ship loads of bugs that relate to Peripherals, and gaps in documentation, that can only be found by running code on a real device, with good inspection.
There are also simpler program flow bugs that can be found on a simulator, but these days, low cost eval boards and modest Debug Sw make a great simulator.
Yup, and in a recent post Chip has been fine-tuning that Debug support for the next release..
Using this little lot?...
...Yes.