As Andreas Løhre wrote:

> I tried the latest trunk with an ATmega2560 this weekend without success,
> using the latest firmware from S6 patch 2.

First, thanks for testing!

> What devices and jtag firmware version are you doing your development on ?

The JTAGICE3 firmware is 2.12 (decimal; Atmel Studio would call that
"2.d").  My current target board uses an ATmega128RFA1 (since I just
had that board around).  My previous primary test board used an
ATmega1284P but that one started to fail reprogramming some day, so
it's now in kind of a read-only state.

I've also done some tests on a board using an ATxmega16D4, but have
not re-tested that one lately.

Operating systems tested include FreeBSD 8.x, Linux 2.6.38 (Ubuntu
11), Linux 2.6.18 (CetOS 5), plus some quick "does it work at all?"
test on OS X and FreeBSD 6.x.  The latter machine cannot operate the
JTAGICE3 though as it's only got USB 1.1 hardware; my main reason for
testing it was to see there are no regressions for older systems
introduced by the USB thread handling.  (FreeBSD < 8.x doesn't use the
libusb20 code path but the libusb-0.1 code as all other systems do.)

> I will post the complete debug output later tonight when I get home; It
> seemed to alternate between failing with an buffer overflow error and usb
> connection errors.

The normal debugging output basically assumes the USB communication works.
If it doesn't, it might be necessary to stuff some fprintf(stderr, ...)
statements around into the various USB threads.

I know the current implementation still has a race condition which I'm
going to fix, but it should not trigger very quickly: each message
from the USB reader threads (for the JTAGICE3, there are two of them)
is preceded by a message length word so the consumer knows how many
bytes to expect.  However, if events arrive at a high rate (e.g. the
device repeatedly going into/out of sleep), the information from both,
the event and the normal reader thread could get mixed up.  I'm going
to fix that by using atomic write operations which write both, the
message length and actual message data within a single write() call.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

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

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
avarice-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/avarice-user

Reply via email to