Debugger Disappointments

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi! In case anyone at Amtel is monitoring, I'd like to offer a few suggestions for improving the behavior of the debug/simulate features integrated into AStudio6.

I've just gotten the "class project" boards for an introductory microcomputer class I help present back from the assembly house, and have been using an Atmel JTAGICE3 pod to bring them up and install Atmel's DFU bootloader image in them (the boards use ATxmega32A4U chips, which, astonishingly, don't come with pre-loaded bootloaders). I also wanted to use the debugger to give the students a picture of what our first crude programming example was doing inside the chip. Mostly, all this worked quite well, but I also quickly encountered some annoying obstacles, made all the more frustrating because I know they'd be simple to remove.

First (and least annoying) is the pervasive tendency of the tools (debugger, simulator, and, now that I think of it, the FLIP programming tool) to demand that the user specify what is automatically detectable: the target chip type. The automatic detectability IS exploited, but only to immediately slap the wrist of the user if they've mis-identified the part they're using. Since all the parts have electronically readable signatures, it's pretty exasperating to have the debugger insist on my telling IT what it's connected to, and then (if I've mis-clicked on the list of eighty or ninety potential types) saying, "oh, no it's not, stupid! It's an ATx.....". And yes, I know that the "automatic detectability" can't be as positive in the case of the simulator-based debugger. But even there, the simulator's supposed to have an information-rich object file to look at; there ought to be a way to slip in some hint like, "this object expects to run on an ATxxx....".

(Related) The current implementation of the DFU bootloader and companion FLIP application seems to require separate "device driver installation" steps for each different AVR chip type one might use FLIP to program, and neither I nor any of our students have the administrator privilege required to authorize FLIP to speak to a new type of AVR. Fortunately, we only use one AVR type, so the pre-class tool installation can include configuring FLIP, but this is still a *stupid* restriction of the tool. What in the name of honey-glazed sardines should the OS care, at the device-driver level, what specific AVR is running the DFU class-implementing firmware that has presented itself on a USB socket? Is the DFU class a standard, or is it not? I better stop in mid-fume, in case the stupidity is inescapably mandated by the DFU spec or something..

Getting back on-theme with this post's title, I was kind of disappointed by how much fiddling was necessary to make the debugger show how signals output on one of the Xmega's I/O ports correlated with those on another port. AStudio6 has only one "I/O view", which can be set to display only one port's signals at a time, so I had to keep switching that window between the two ports of interest. The old AStudio 4 debug/simulate interface would let you expand all the I/O ports at once if you wanted, which worked much better for this portion of the class. I understand (though it came as something of a shock) that the Xmegas' I/O ports have far more controlling/setup registers than the previous parts, so even displaying the details of just one of them uses up the window. But the environment really should let you have multiple separately detachable windows for displaying I/O stuff. Just as you can have separate "memory inspection" windows, you ought to be able to have separate I/O inspection windows: at least four of them.

But the most disappointing thing of all was the way that the debugger is held captive to the firmware-building functions of AStudio. A hardware debug pod has the in - cred - i - bly useful capacity to reach into the very soul of a chip it's designed for and attached to, make any of its I/O pins wiggle, report where its program counter is, what instructions it sees there, and so on, without absolutely requiring any particular object file. I had expected to be able to plug the JTAGICE3 into the completely-blank ATxmega32A4U chips, and use the interactive I/O control windows to flip port pins on&off as a quick-and-dirty way to verify the function of the new boards, but found that the only way to even START the debugger seems to be to have a just-built project of some kind to unleash it on. Okay, it wasn't too hard to build a trivial (empty "main() { }" ) project just so I could "start debug"ging on it, and use the JTAGICE3 features to start flipping bits. But another aspect of the overly tight coupling between the built project and the debugger is the refusal of the debugger to follow execution into addresses outside the currently-built application. Atmel has graciously supplied me with a customized DFU bootloader (using a different pin for its application-vs-bootloader startup switching), but neither of their two offerings so far have functioned properly, and I thought to try using the debugger to see if I could figure out how they had gotten the "test one bit and branch to either of two places" operation garbled. But even though implemented in hardware, the debugger took one look at the "BOOTRST"-fuse-imposed restart location, and went into catatonia. Sure, it wouldn't have C sourcecode to point to, but it should be perfectly capable of opening the "disassembly" window.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

AStudio6 has only one "I/O view", which can be set to display only one port's signals at a time

I thought that until Stefan corrected me the other day. You can show the signals of more than one SFR in the lower pane if you Ctrl-click to multiple select them. I don't think I would have stumbled across that little piece of magic in a 1,000 years if Stefan hadn't told me. Now you know - spread the word. (the manual chooses to say nothing about this!).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I frequently work on boards that have different processors and the automatic detectability of the processor type has saved me, many times, from loading what I think is the correct code, into the incorrect board that is actually connected to the programmer (and visa versa).

If you only ever use one processor type then yes, it does look like a bizarre and superfluous arrangement.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps it should be configurable? Offer the best of both worlds ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:
I frequently work on boards that have different processors and the automatic detectability of the processor type has saved me, many times, from loading what I think is the correct code, into the incorrect board that is actually connected to the programmer (and visa versa).

If you only ever use one processor type then yes, it does look like a bizarre and superfluous arrangement.

To flog the dead horse a bit more, so what? You loaded the incorrect code, so you used up an extra 1/10000th of the lifetime of the FLASH. Load the correct code next time and move on.

I'm all for having the tools automatically recognize what's what; in fact, that's why I think it's stupid to make the human do the selecting. In your situation, when you ask the programmer to load xyz.elf, which contains the equivalent of "TargetMCU == ATmega128" or somesuch, then the programmer should certainly say something like, "Uh, bub, are you SURE you want to stick xyz.elf into your ATXmega64? Looks like it's sposeta go into an ATmega128".

Similarly for a debugger. When it starts up, if it's got real hardware to look at, it should configure the settings for the chip that's there. If you, the operator, start to wonder what happened to Timer number twelve, maybe that would clue you into noticing that you've attached the debugger to an ATTiny instead of your ATXPentium.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

AStudio6 has only one "I/O view", which can be set to display only one port's signals at a time

I thought that until Stefan corrected me the other day. You can show the signals of more than one SFR in the lower pane if you Ctrl-click to multiple select them. I don't think I would have stumbled across that little piece of magic in a 1,000 years if Stefan hadn't told me. Now you know - spread the word. (the manual chooses to say nothing about this!).
Well, I'm suitably surprised; it does behave like that! And, if you mouse over the lines, the tooltips DO say which IO port they're displaying information for (they otherwise blend together). I'll remember that; thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
To flog the dead horse a bit more, so what? You loaded the incorrect code, so you used up an extra 1/10000th of the lifetime of the FLASH. Load the correct code next time and move on.
Well on a breadboard with only a chip on it, that may be true. But if your chip is connected to a H-bridge for example and loaded with the wrong code, you might drive the high and the low sides altogether, resulting in a short-circuit that can destroy your pcb (which would take time and money to get a new one). So this feature is not a bad one in my opinion. As Cliff said, an option box could be the answer.

Have a nice day,
Kraal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An issue I have and have raised with Atmel is that to re-compile you have to end your debug session, which is fine. But it does not give you the option to keep the chip in a reset condition. It might seem trivial, but try debugging a system controlling a big machine moving tons of parts with hydraulics,its much nicer if it just sits quitely doing nothing.

Dont let me even start with the useless 'top of the range' AvrOne which offers nothing more that some of the simple cheap debuggers. Not even a timer to see how long / how many cycles a function takes. An absolute waste of space and money

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

from my experience the system always resets. so what do you mean by a reset condition ? as far as the avrone goes I agree as I have one here and haven't used it as what is the advantage ? A sub $100 debugger does the same job. Is there any atmel debugger that provides trace ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

A sub $100 debugger does the same job. Is there any atmel debugger that provides trace ?


ICE50 (etc) though a bit long in the tooth these days (I have one in a box in the loft!). Rather than "JTAG sniffers" these things really were ICE's in the true meaning of the word. They fully emulated the mega8 or whatever and replaced a real one in circuit (which is why trace was easily possible).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

that's what I thought. I guess we will not see a trace function in the near future with the atmel tools ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

so what do you mean by a reset condition

An example - you run your code an see that there is bug causing something to happen in the real world that could cause damage. While you fix this bug you would just like the real AVR to be held in a reset condition. Currently the debugger simply disconnects from it and lets it restart - not a good idea if things are going badly wrong. So there should be an option that causes the debugger to keep it in a reset / non running condidtion - like it does when it hits a breakpoint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Avrone contains an FPGA which is most likely capable of emulating most of the AVR's - but because the debug functionality seems to be only what A6 can deliver, it does not eveen appear that the FPGA is reqired

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would definitely expect the board to reset on a recompile as who knows what changes will be made to the code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes but even if the FPGA emulated an AVR (which of the 303 models would that be?) it wouldn't help as a true ICE has a pin for every pin on the target AVR. So if you are emulating a 28 pin using a real ICE you lift the 28 pin from the target board, you connnect the 28 emulated pins from the ICE in their place then the ICE "pretends" to be be the replaced CPU.

How is this going to work for 100/144 pin devices?

It's true I've used ICEs in the past that emulated up 64 pin QFP debvices and the target board had a QFP socket into which either a real chip or the ICE could be plugged but for Atmel to produce an ICE with headers for all package types that they use and an FPGA emulation of all 303 different AVRs that are currently active would be a huge undertaking.

In the absence of that it can only be done with a JTAG sniffer (which is what Dragon, JTAGICE, JTAGICEmkII, JTAGICE3, AVR One! really are) by them running one opcode, then stopping and taking PC details, then run the next and so on, buffering where the PC has been.

Cortex M0+ have a nice on silicon "micro trace buffer" facility. You reserve an area of the SRAM. As the CPU fetches opcodes it logs PC values to the buffer. When code execution is stopped the debugger extracts the buffer and can then produce an annotated history of where the PC has been.

Sadly no AVRs (and not even SAM D20) have this feature though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

guess it all comes down to cheap debug tools which is great. I remember years ago I purchased a 68hc05 debug system for about $1100. ran using an ide on dos. oh what fun. hopefully atmel can give us some trace one of these days

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are other ways to do it...
Run the AVR in the FPGA - Atmel can create an FPGA core file for each model. This will do all the actual debugging. It will just have no I/O to your board apart from Jtag/PDI.
Load a special program into the real AVR which controls the inputs and outputs and communicates with the FPGA AVR via Jtag/PDI. Even if this caused the system to run slower than the real Avr's max speed, it would be far more useful than the current system.
At the moment you cant even do data breakpoints or counts on program breakpoints without writing your own debug code.
If Atmel cant / dont want to do this kind of thing then why dont they just make the PDI debugging codes open? Then perhaps the AVR comunity could do it themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
At the moment you cant even do data breakpoints or counts on program breakpoints without writing your own debug code.

The JTAGed AVRs do have primitive (hw) data memory breakpoints (all except 0x00-0x1F locations) and (hw+sw) program counter breakpoints. There are no program memory breakpoints (no lpm, no spm) but program counter breakpoints only. However none supports countdown.

Quote:
Even if this caused the system to run slower than the real Avr's max speed, it would be far more useful than the current system.

I do not think so.

No RSTDISBL, no fun!