avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Good news: STK500v2 and JTAG ICE mkII code committed t


From: Colin O'Flynn
Subject: Re: [avrdude-dev] Good news: STK500v2 and JTAG ICE mkII code committed to CVS
Date: Wed, 11 May 2005 18:57:46 -0400
User-agent: KMail/1.7.1

Hey,

Alright, sounds great!

When you say "MKII Programming Code" does that mean programming with the JTAG 
interface, the DebugWire interface, or both?

Warm Regards,

 -Colin


On Tuesday 10 May 2005 15:36, Joerg Wunsch wrote:
> Hi *,
>
> I just committed a bunch of new code to CVS.
>
> Originally, I intented to do this within a few commits, but when
> reviewing the diff, I noticed both implementations already collided
> into too many places, so dissecting them into two commits would have
> been a tedious work (as a lot of conflicts had to be repaired
> afterwards when preparing the second commit).
>
> The first part of this commit is the import of Erik Walthinsen's
> STK500v2 protocol implementation (finally).  Brian sent it to me, and
> I did only some minimal cleanup on it (see commit message below).  The
> code still causes a couple of compilation warnings (to be cleaned up
> later), but I could test it against an STK500v2 here, and it does work
> well.  It causes one run-time warning on my version of the STK500v2
> I've got access to:
>
> avrdude: stk500v2_getsync(): can't communicate with device: resp=0x01
>
> I verified Erik's code behaves as the STK500v2 specs say, so it's
> obviously the STK500v2 returning a different response code here.
> Everything else works fine though, so I suspect a problem with the
> documentation.  Someone else might want to report that to Atmel.
>
>
> The second part of the commit implements JTAG ICE mkII programming
> support for avrdude.  Yes, that (in)famous new JTAG ICE that used to
> be unsupported by any opensource tools by now. ;-)  I've suddenly got
> access to such a device, and the one who gave it to me was really
> eager to see Linux/Unix support for it (so they can drop Windows out
> of their toolchain).  After a bit of consideration, I've chosen
> avrdude as the platform to use for the implementation.  First, I know
> avrdude quite a bit already, being an occasional contributor to it
> back since the days when it was Brian's privately maintained avrprog
> baby.  Second, after Russell Shaw's statement that he's considering to
> add direct JTAG ICE support to GDB (he's already done mkI, and
> currently exploring mkII) it became apparent that this would
> eventually obviate the need for avarice completely, but we'd then need
> some other tool to support software downloading through the JTAG ICE.
> Finally, the already done STK500v2 support, together with the somewhat
> similar protocols between both, made me start to work on avrdude.
>
> The result is now what I'd call alpha to beta quality.  ``It works for
> me.'', basically. ;-) See below, the OCDEN fuse should not be written
> that frequently as it is now, and few other minor things need a bit of
> polishing.  I wish I knew why the MCU doesn't start again after
> signing off, but I'm going to track that with Atmel (I hope).  During
> the course of that work, I got quite a bit of contacts with Atmel
> Norway, as the JTAG ICE mkII protocol document appears to be, well,
> somewhat inaccurate in many respects.  They've already updated the
> document in the web once, but there are still more errors in it, and
> quite a number of things remain unexplained (like the need to have the
> OCDEN fuse programmed when you want to access MTYPE_EEPROM or
> MTYPE_SPM memory).
>
> That doesn't mean I wouldn't consider avarice at all, but avrdude was
> the first thing to do it.
>
> I've also got a patch from Bernd Walter still in the pipeline that
> increases the write blocksize for ser_posix.c, in order to speed up
> the communication by lowering the syscall overhead.  That's going to
> be committed later on.
>
>
> Please folks, give all that a try, both those of you who've got access
> to an STK500v2 and/or to a JTAG ICE mkII, as well as everyone else to
> see I didn't break anything.  Please do also look at the doc changes
> to see if this all makes sense to you.
>
>
> ------------ Original CVS commit message: -----------------
> Mega-commit to bring in both, the STK500v2 support from Erik
> Walthinsen, as well as JTAG ICE mkII support (by me).
>
> Erik's submission has been cleaned up a little bit, mostly to add his
> name and the current year to the copyright of the new file, remove
> trailing white space before importing the files, and fix the minor
> syntax errors in his avrdude.conf.in additions (missing semicolons).
>
> The JTAG ICE mkII support should be considered alpha to beta quality
> at this point.  Few things are still to be done, like defering the
> hfuse (OCDEN) tweaks until they are really required.  Also, for
> reasons not yet known, the target MCU doesn't start to run after
> signing off from the ICE, it needs a power-cycle first (at least on my
> STK500).
>
> Note that for the JTAG ICE, I did change a few things in the internal
> API.  Notably I made the serial receive timeout configurable by the
> backends via an exported variable (done in both the Posix and the
> Win32 implementation), and I made the serial_recv() function return a
> -1 instead of bailing out with exit(1) upon encountering a receive
> timeout (currently only done in the Posix implementation).  Both
> measures together allow me to receive a datastreem from the ICE at 115
> kbps on a somewhat lossy PCI multi-UART card that occasionally drops a
> character.  The JTAG ICE mkII protocol has enough of safety layers to
> allow recovering from these events, but the previous code wasn't
> prepared for any kind of recovery.  The Win32 change for this still
> has to be done, and the traditional drivers need to be converted to
> exit(1) upon encountering a timeout (as they're now getting a -1
> returned they didn't see before in that case).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]