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, Jorg .-.-. --... ...-- -.. . 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
