(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. ;-) ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ avarice-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/avarice-user
