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. ;-)
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
avarice-user mailing list
avarice-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avarice-user
