Re: [AVaRICE-user] AVR dragon desynchronizing with GDB

[Joerg W. <j...@ur...>]

As Francois Lorrain wrote:

> That's why I am calling my modification a hack :-) I couldn't even figure
> out how to tell the configure script to look for libusb-1.0 instead of
> libusb.

Have a look into AVRDUDE's configure.ac, I've already done it there.

> For the regular command / response processing, I just used the synchronous
> interface of libusb-1.0. It seemed like an overkill since the AVR Dragon
> just answers to the command and there does not seem to be any unexpected
> answers.

Sorry, that's not the case.

There's something the JTAG ICE calls an "event": it is *not* triggered
by a command synchronously (*), but by the ICE itself.  The obvious
situation where this happens is reaching a breakpoint during normal
program run.  AVaRICE has to wait for this in parallel to waiting for
new input from GDB (since it could as well be the user hitting ^C to
break the program), this happens in jtag2run.cc here:

          int numfds = select(maxfd + 1, &readfds, 0, 0, 0);
          if (numfds < 0)
              throw jtag_exception("GDB/JTAG ICE communications failure");

          if (gdbFileDescriptor != -1 && FD_ISSET(gdbFileDescriptor, &readfds))
            {
                int c = getDebugChar();
                if (c == 3) // interrupt
                  {
                      debugOut("interrupted by GDB\n");
                      gdbInterrupt = true;
                  }
                else
                    debugOut("Unexpected GDB input `%02x'\n", c);
            }

          if (FD_ISSET(jtagBox, &readfds))
            {
                expectEvent(breakpoint, gdbInterrupt);
            }

(*) Actually, some commands do trigger a BREAK event in addition to the
regular response frame.  Actually, that's more a nuisance than helpful.

There are more possible events than just reaching a breakpoint: device
entering/leaving sleep, power cycle, unsolicited reset (external or
watchdog, for example).

> I used the asynchronous interface when the target is running and you need
> to poll for either a GDB interrupt packet or the "Break" packet coming from
> the AVR Dragon.

OK, that's what I meant.  Basically, you just have to know which Unix
filedescriptor to poll for in the select() statement above.
libusb-0.1 didn't allow for this, 1.0 does.  As such, it obviates the
need for a separate thread or process to handle the USB communication.

> One thing which is leftover from the serial interface is the fact that
> avarice will try to resend the command after a timeout if it did not get an
> answer, this is definitely a No-No for USB, repeating the command packet
> does confuse the AVR dragon ...

Well, what do you want to do if the ICE doesn't answer?  Just sit there?

I changed this quite a bit lately, I think it's more robust now.

> Quick question : When you have a Jtag2 interface, is it always connected
> via USB or can you have the JtagIce connected via serial ?

As the JTAGICEmkII does offer an RS-232 connector, we should be able to
handle it.  (The AVR Dragon and JTAGICE3 don't have it anymore.)
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)