Re: [AVaRICE-user] [ avarice-Feature Requests-3586529 ] AVaRICE should support ICE3

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

(For those who don't read to the end: this is a request for *your*
contribution as well.)

As SourceForge.net wrote:

> The trace is made with Wireshark 1.8.3 with all empty USB packets
> (Data_len == 0) removed. The full trace is still available.

I've made a first attempt at analyzing the trace(s).  The very first
remarks can be seen in that avrfreaks thread:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=126586#1009972

In short: the ICE3 uses three endpoints.  In addition to the obvious
normal data endpoints, there's a third one apparently used for event
posting from the ICE, as a kind out-of-band signalling.  In that
thread, I've already basically identified the "read memory" command,
and the "read PC" one.  For "read memory", the memory space
identifiers appears to be the same as in the JTAGICEmkII, at least at
the first glance (0x20 is SRAM in debug mode, 0xb0 is Flash in
programming mode, 0xa0 is Flash in debug mode).

I committed an XSL "stylesheet" to the tools/ subdirectory that can be
used to analyze Knut's trace data.  (If anyone cannot run Wireshark to
produce the PDML file, tell me.)  Based on that, I started some more
reverse engineering.  So here are the first results:

0x01 --> 0e 00 00 00 01 10 00
0x82 <-- 0e 00 00 01 80 00
0x01 --> 0e 00 01 00 01 02 00 00 00 04
0x82 <-- 0e 01 00 01 84 01 00 02 0c c9 00 00
...
0x01 --> 0e 00 13 00 12 21 00 b2 01 00 00 00 01 00 00 00
0x82 <-- 0e 13 00 12 84 00 17 00

Everything (of interest) starts with 0x0e.  That resembles the 0x0e
that starts the actual data in the JTAGICEmkII protocol (marked as
"V2" subsequently), except the outer framing (header with length,
trailing CRC) has been omitted.

There is a message serial number (has been in the frame header in V2),
and each response mirrors the serial number of the request.  However,
the request serial number (and the event serial number as well) is
preceded by one byte which is always 0x00, while this byte is left out
in the response.

After this preamble, the actual command follows.  Unlike in V2, the
command byte itself is now either preceded by 0x01, or 0x12.
Apparently, that's some kind of "scope" identifier, where 0x01 relates
to a "generic" scope (like asking for the device name and serial
number), and 0x12 means the command is AVR-related.  So command 01 10
is something different (SIGNON) than 12 10 (which starts the session
with the AVR, and is responded to with the JTAG device ID in JTAG
format, 0x1970503f).

Command 0x02 in generic scope appears to be a GET_PARAM command:

0x01 --> 0e 00 01 00 01 02 00 00 00 04
0x82 <-- 0e 01 00 01 84 01 00 02 0c c9 00 00

0x01 --> 0e 00 01 00 01 02 00 00 00 01
0x82 <-- 0e 01 00 01 84 01 00 00
0x01 --> 0e 00 02 00 01 02 00 00 01 01
0x82 <-- 0e 02 00 01 84 01 02 00
0x01 --> 0e 00 03 00 01 02 00 00 02 01
0x82 <-- 0e 03 00 01 84 01 0c 00
0x01 --> 0e 00 04 00 01 02 00 00 03 02
0x82 <-- 0e 04 00 01 84 01 c9 00 00
0x01 --> 0e 00 05 00 01 02 00 00 05 01
0x82 <-- 0e 05 00 01 84 01 01 00

Similar to V2, positive responses are apparently starting at 0x80, so
0x80 is just "OK", while 0x84 delivers additional data (as in the
response to the GET_PARAM commands).  There appear to be fewer
positive response codes than in V2; the response data for GET_PARAM is
introduced by the same 0x84 code as the response data for a
READ_MEMORY command in the AVR scope.  Again, the response code itself
is preceded by the "scope" ID matching the respective request, either
0x01 or 0x12.

All responses have an additional 0x00 appended, whatever it might
mean.

More things that spring to mind:

0x01 --> 0e 00 0e 00 12 15 00
0x82 <-- 0e 0e 00 12 80 00

Apparently "ENTER_PROGMODE", because after this, flash (and fuse)
programming starts.  Likewise:

0x01 --> 0e 00 c2 01 12 16 00
0x83 <-- 0e 00 42 01 12 40 00 00 00 00 02 08 00
0x82 <-- 0e c2 01 12 80 00

This appears to be LEAVE_PROGMODE (just one higher than the ENTER
command), but triggers an event (endpoint 0x83), in addition to the
regular "OK" response on endpoint 0x82.

0x01 --> 0e 00 14 00 12 20 00 00 00 00 00 00
0x82 <-- 0e 14 00 12 80 00

This is probably the "ERASE_FLASH" command (perhaps including an
address plus range), as it precedes the actual flash write block.

I'd like to invite everyone to try some reverse engineering on the
data of their own, as well as upload trace data obtained from other
targets.  I do hope we'll be able to support the JTAGICE3 some day.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

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