JTAG - A tool for finding workarounds for buggy licensed binary blobs, and undocumented hardware, that aren't meant to be buggy in the first place ... Or reverse engineering. :P
You spotted it. JTAG is about as standard as finger prints. Everybody has them but they are all different. I'm quite happy to do with out it on the Prop.
Anyway, on the Prop instead of having serial port hardware we have software UARTS. And so on for other devices.
Ergo, the Prop should not have dedicated JTAG hardware but rather software JTAG.
Now, the original intention of JTAG was as a "boundry" scan mechanism that enables one to set or read any pin on an integrated circuit thus enabling the testing of assembled printed circuit boards. Strangely enough a Props COG can set and read any pin, pins are dedicated to processors as in some multi-core MCUs. So that boundrt scan is covered.
JTAG for software debugging was a later idea and seems a bit of a cludge to me.
JTAG debugging works very well on all the devices I've used it on, including MSP430 and ARM chips. With FPGAs, there are tools using it like Xilinx's Chipscope that offer very powerful hardware/software debugging facilities:
JTAG caused me to waste 60 Euro's on a STM32 Primer dev kit.
The only way to program and debug that thing is via a Windows IDE and a special JTAG driver. Installing the driver is a complicated business and if you get it wrong there is an immensely complicated set of instructions to remove it and start again. Needless to say I got driver installation wrong the first time and then after many hours gave up trying to get the uninstall instructions to work and reinstalled Windows.
At that point I gave up on STM32, and Windows, which I did not want anyway and only installed for this task. And was seriously put off JTAG (again).
Luckily it works better with Linux and some other MCU's that will remain nameless here.
I can use my Rowley development tools to debug code running on STM32 boards, and all my ST boards also work with the ST software. ST uses the Segger JTAG interface, which is quite popular, and supports many devices:
In the end, for the Prop, JTAG would be no more useful than just another download interface. We aren't dealing with licensing of closed source and undocumented hardware.
It's a bit like electric windows: They're nothing to write home about, and they're built wrongly (you can't open/close them without the ignition on), but every salesman sill pushes them as a must have feature.
I once used a debugger just after I left school. It was what taught me how machine code functioned. Great educational tool! And a must-have for reverse engineering.
But once one knows the workings of the hardware and understands ones own source then debuggers are optional and just becomes a preference.
And the few commercial software projects I've worked on have been almost totally my own code. That obviously makes a difference. I never got into a situation where I was trying to solve a problem where the author of the code was bullshitting or that there were so many people on the project that it would be stupid to read everyone's work.
I'm sure it does, and I'm sure you can debug really complex hardware using only a simple logic probe and multimeter rather than an oscilloscope and/or logic analyser.
I'm sure it does, and I'm sure you can debug really complex hardware using only a simple logic probe and multimeter rather than an oscilloscope and/or logic analyser.
Or a read complete ISR on a disk drive, or any other real-time code execution. Better have 'glitch mode' set on that really fast scope!
Not sure how a printf() would work on a disk or tape drive that has nothing to print to, i.e., no screen/terminal. Firmware engineers don't use printf()s, they set breakpoints...
Firmware engineers don't use printf()s, they set breakpoints...
Or let me generalize a bit: Professionals set breakpoints, hobbyists use printf()s. As with any generalization, there are exceptions, of course, but many hobbyists tend to take the minimalist approach.
This is fine, but what often annoys me is that they then poo-poo more sophisticated debugging tools as being unnecessary and a cause of "brain rot". Most modern MCUs have a JTAG or serial wire debug interface, but there's NOTHING forcing anyone to use them. If you are religiously opposed to hardware debugging interfaces, then DON'T USE THEM! But don't try to tell anyone else that they're not necessary.
Or let me generalize a bit: Professionals set breakpoints, hobbyists use printf()s. As with any generalization, there are exceptions, of course, but many hobbyists tend to take the minimalist approach.
Yes, that is a generalization that may not be accurate. I know a lot of professional software developers that shun debuggers, GUI's and IDE's, and I know a lot of professionals that can't seem to function without them. This is the case with hobbyists as well. I think most of the honnyists that use the Stamp and Prop use the IDE. If a debugger was available, I suspect they would use that as well.
Software developers don't work with hardware. Firmware engineers do. That's a major the distinction IMO.
Myself and all the firmware engineers I know have never used a printf() in a deeply embedded environment. They always use an emulator/ice/jtag to debug. They have to.
Edit: I work with software engineers too, and some seem to fall into both camps you describe. Maybe it's just the mindset/style of the individual?
I work with software engineers too, and some seem to fall into both camps you describe. Maybe it's just the mindset/style of the individual?
Even with purely software systems, the efficacy of using printf()s depends on how sensitive the system is to timing and other similar things. In these types of systems, adding a few printf()s throw off the timing enough that the system behaves completely differently and now you either don't see the issue you're trying to debug, or it makes it worse.
In other cases, adding printf()s will change the addresses code and data will fall in memory and change the behavior of the system.
I will only use this kind of invasive debugging technique when I don't have any other choice (which, fortunately, is rarely.)
It is just a preference thing. I wasn't the first one poo-pooing btw.
It's not a lot different to the effort required to setup the equivalent breakpoints. I did all my servo ISR debugging, including proving a machine build fault, with printf()'s. Ok, so the reporting can't be in-line but it wasn't a big deal to share the capture memory.
Comments
You spotted it. JTAG is about as standard as finger prints. Everybody has them but they are all different. I'm quite happy to do with out it on the Prop.
Anyway, on the Prop instead of having serial port hardware we have software UARTS. And so on for other devices.
Ergo, the Prop should not have dedicated JTAG hardware but rather software JTAG.
Now, the original intention of JTAG was as a "boundry" scan mechanism that enables one to set or read any pin on an integrated circuit thus enabling the testing of assembled printed circuit boards. Strangely enough a Props COG can set and read any pin, pins are dedicated to processors as in some multi-core MCUs. So that boundrt scan is covered.
JTAG for software debugging was a later idea and seems a bit of a cludge to me.
http://www.xilinx.com/tools/cspro.htm
JTAG caused me to waste 60 Euro's on a STM32 Primer dev kit.
The only way to program and debug that thing is via a Windows IDE and a special JTAG driver. Installing the driver is a complicated business and if you get it wrong there is an immensely complicated set of instructions to remove it and start again. Needless to say I got driver installation wrong the first time and then after many hours gave up trying to get the uninstall instructions to work and reinstalled Windows.
At that point I gave up on STM32, and Windows, which I did not want anyway and only installed for this task. And was seriously put off JTAG (again).
Luckily it works better with Linux and some other MCU's that will remain nameless here.
http://www.segger.com/jlink.html
I've never had any problems with JTAG on Windows.
But once one knows the workings of the hardware and understands ones own source then debuggers are optional and just becomes a preference.
As for what chip types I have programmed? Not a lot, a few uCs ( Mostly 8-bitters and all UART programmed), 3 CPUs, only one FPGA (pre-dating JTAG).
Mostly as hobby. My jobs over the years have rarely involved development and even rarer software development.
If no one needs debugging hardware on the Propeller, why are so many debuggers implemented in software?
I'm sure it does, and I'm sure you can debug really complex hardware using only a simple logic probe and multimeter rather than an oscilloscope and/or logic analyser.
Or a read complete ISR on a disk drive, or any other real-time code execution. Better have 'glitch mode' set on that really fast scope!
Not sure how a printf() would work on a disk or tape drive that has nothing to print to, i.e., no screen/terminal. Firmware engineers don't use printf()s, they set breakpoints...
And, aside from asking for help with this specific chip, I will no longer comment on comparisons to RISC/CISC/DSP processors. Apples and oranges...
Or let me generalize a bit: Professionals set breakpoints, hobbyists use printf()s. As with any generalization, there are exceptions, of course, but many hobbyists tend to take the minimalist approach.
This is fine, but what often annoys me is that they then poo-poo more sophisticated debugging tools as being unnecessary and a cause of "brain rot". Most modern MCUs have a JTAG or serial wire debug interface, but there's NOTHING forcing anyone to use them. If you are religiously opposed to hardware debugging interfaces, then DON'T USE THEM! But don't try to tell anyone else that they're not necessary.
Myself and all the firmware engineers I know have never used a printf() in a deeply embedded environment. They always use an emulator/ice/jtag to debug. They have to.
Edit: I work with software engineers too, and some seem to fall into both camps you describe. Maybe it's just the mindset/style of the individual?
Even with purely software systems, the efficacy of using printf()s depends on how sensitive the system is to timing and other similar things. In these types of systems, adding a few printf()s throw off the timing enough that the system behaves completely differently and now you either don't see the issue you're trying to debug, or it makes it worse.
In other cases, adding printf()s will change the addresses code and data will fall in memory and change the behavior of the system.
I will only use this kind of invasive debugging technique when I don't have any other choice (which, fortunately, is rarely.)
It's not a lot different to the effort required to setup the equivalent breakpoints. I did all my servo ISR debugging, including proving a machine build fault, with printf()'s. Ok, so the reporting can't be in-line but it wasn't a big deal to share the capture memory.