MK-II Reverse Engineering

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Just got my JTAG ICE MK-II today, so what else am I going to do then take it apart?

Anyway first off on the protocol, a quick check with Portmon let me figure out that the MK-II protocol is quite different from the JTAG ICE protocol. To communicate with it, you need 19200 baud by default.

Init the MK-II, send:
1B 00 00 01 00 00 00 0E 01 F3 97

Receive back:
1B 00 00 1C 00 00 00 0E 86 01 FF 13 02 00 FF 14 02 00 00 A0 00 00 0A 56 4A 54
41 47 49 43 45 6D 6B 49 49 00 27 28

FF 13 02 00 FF 14 02 = Software revision somehow, reported as 0x0213 0x0214
which corresponds to the 13 02 and 14 02.

My hardware revision is 0x0000, so that could be a few things in the string.

4A 54 41 47 49 43 45 6D 6B 49 49 = JTAGICEmkII in ASCII

So there is some quick'n'dirty information, I might look more into it by
setting up an actual device. This is just for JTAG as well I might add, using
the program button in AVR Studio.

Please add more info when you figure out more!

As far as the hardware goes - there are two siz-pin headers and two ten-pin headers on the board. On mine there was some wierd stuff on the bottom of the board that you had to peel off.

The pin-out, from left to right when looking at the top of the board with the JTAGICE mkII text being the right way around:

First 6-pin

1: Mega128-1, Pin 3, ISP MISO
2: VCC
3: Mega128-1, Pin 11, ISP SCK
4: Mega128-1, Pin 2, ISP MOSI
5: Mega128-1, Pin 20, RESET
6: GND

First 10-pin

1: Mega128-1, Pin 57, JTAG TCK - Also appears shorted to GND
2: GND
3: Mega128-1, Pin 55, JTAG TDO
4: VCC
5: Mega128-1, Pin 56, JTAG TMS
6: Mega128-1, Pin 20, RESET
7: VCC
8: NC
9: Mega128-1, Pin 54, JTAG TDI
10: GND

Second 6-pin

1: Mega128-2, Pin 3, ISP MISO
2: VCC
3: Mega128-2, Pin 11, ISP SCK
4: Mega128-2, Pin 2, ISP MOSI
5: Mega128-2, Pin 20, RESET
6: GND

NOTE: Pins 2 and 4 seem to be shorted together

Second 10-pin

1: Mega128-2, Pin 57, JTAG TCK - Also appears shorted to GND
2: GND
3: Mega128-2, Pin 55, JTAG TDO
4: VCC
5: Mega128-2, Pin 56, JTAG TMS
6: Mega128-2, Pin 20, RESET
7: VCC
8: NC
9: Mega128-2, Pin 54, JTAG TDI
10: GND

"Appears shorted" means that it reads as almost zero ohms, but I assume it is because the circuit is powered off and the protection diodes on the Mega128 inputs or something like that have kicked in.

The six-pin headers connect to the ISP of each Mega128, and the 10-pin headers connect to the JTAG port of each Mega128.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More info:

I put my JTAG ICE on the two JTAG ports, and from Mega128-1:

Extended Fuse: 0xff (11111111)
high fuse: 0xa8 (10101000) OCD Disabled, JTAG enable, SPI programming disable,
low fuse: 0x1f (00011111)

From the Mega128-2:

Extended Fuse: 0x3f (00111111)
high fuse: 0x3f (00111111)
low fuse: 0x3f (00111111)

It would appear JTAG is disabled on this Mega128, as the fuse bytes seem to have a bogus value.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Found more information on the serial protocol, but I need some help.

Data sent to the MK2 looks something like this (for instance to request voltages):

1B 01 00 02 00 00 00 0E 03 06 96 76

The next time it will send (same request)

1B 02 00 02 00 00 00 0E 03 06 91 A0

So the second byte is incremented after every sent message. The last two bytes are some sort of checksume I assume - but what is the code? I tried a few different types of CRC-16 and couldn't get anywhere. Anybody got some ideas?

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which CRC's did you try? (which polynomials)
And (of course) did you check for swapped bytes in the CRC?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why do you need to do this?

What's the problem?

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's no problem. It would be great if some of the open source software tools could support the mkII.

It would be even better if some manager from Atmel Norway or Atmel San Jose saw this and thought: "We can make more money selling chips than selling tools. Let's support our users who want to use our chips. Let's open the protocol of the JTAG ICE mkII and stop making it proprietary!"

But would that be asking too much? :roll:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I've tried http://rcswww.urz.tu-dresden.de/... as well as my own CRC-16 routines (forget the polynomial they've got). But you are better off to assume I've screwed up and start from scratch :p

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
"We can make more money selling chips than selling tools. Let's support our users who want to use our chips. Let's open the protocol of the JTAG ICE mkII and stop making it proprietary!"

I'll bet there are relatively few ICEs sold... in my experience if sales thinks I'll buy lots of chips, they won't let me pay for any tools.... or samples for that matter.

It's probably not common for an industrial customer (volume 10e6) to roll their own JTAG ICE; it's more common for the hobbyist (volume 10 to 1000).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It's probably not common for an industrial customer (volume 10e6) to roll their own JTAG ICE; it's more common for the hobbyist (volume 10 to 1000).

Hobbyist and small users can/do/may become large users at some time in their career, so it's nice to keep them happy. :D :D :D
Of course one does remember the companies that were nice to them in their electronics infancy and may tend to remain LOYAL clients (that's something that has gone out of fashion). OK I know the above is off topic, back on topic, Colin keep on cracking :wink:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

to break the crc, a much better input would be two bitstreams that differ in a single bit in the data part. so instead of the 1B 01 and 1B 02 streams get 1B 02 and 1B 03.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Well first I tried asking Atmel, figure it is worth a shot :wink:

Also here is the bitstreams with just one bit different:

1B 02 00 02 00 00 00 0E 03 06 91 A0
1B 04 00 02 00 00 00 0E 03 06 8E 04
1B 08 00 02 00 00 00 0E 03 06 A1 44

Also I'm not sure how much of the bit-stream is in the checksum - for instance the 1B may or may not be part of the checksum (seems likely it is not). I really don't understand the math too well for the CRC, or at least not enough to crack it.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nope. that's always two bits difference. like 02->04 is bit 1:1->0 and bit 2:0->1. that's why I wrote 02 and 03.
mark

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

OK - finally got it through my skull what you meant, so here is the REAL one-bit difference data :p First and last are one-bit diff, second and last are one-bit diff.

1B 01 00 02 00 00 00 0E 03 06 96 76
1B 02 00 02 00 00 00 0E 03 06 91 A0
1B 03 00 02 00 00 00 0E 03 06 6C ED

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just another note - Atmel would not release any information about the MK-II, even the Checksum.

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I got the CRC parameters :D
initial: 0xFFFF
poly: 0x1021
mode: reflect input, reflect remainder
The CRC is calculated over all bytes(including 0x1B), byte order is MSB, LSB

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

springob wrote:
I think I got the CRC parameters :D
initial: 0xFFFF
poly: 0x1021
mode: reflect input, reflect remainder
The CRC is calculated over all bytes(including 0x1B), byte order is MSB, LSB

Could you explain more about what you mean by reflect input, and reflect remainder?

Also is the final CRC inverted when transmitted?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again,

the crc byte order was incorrect, it's LSB, MSB

Nils

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I use the boost crc library for the calculation. In the document section are some links to other documents describing crc calculation in detail.
The library documentation is available here:

http://www.boost.org/libs/crc/in...

I am using the following code for testing:

  typedef boost::crc_optimal<16, 0x1021, 0xFFFF, 0, true, true>  crc_avr_type;
  uint8_t data_long[] =
  { 0x1B, 0x00, 0x00, 0x1C, 0x00, 0x00, 0x00, 0x0E,
    0x86, 0x01, 0xFF, 0x13, 0x02, 0x00, 0xFF, 0x14,
    0x02, 0x00, 0x00, 0xA0, 0x00, 0x00, 0x0A, 0x56,
    0x4A, 0x54, 0x41, 0x47, 0x49, 0x43, 0x45, 0x6D,
    0x6B, 0x49, 0x49, 0x00, 
    0x27, 0x28 };
  crc_avr.process_block( &data_long[0], &data_long[36] );
  if (crc_avr.checksum()==uint16_t(data_long[37])*0x100+data_long[36])
    std::cout << "checksum OK" << std::endl;

Nils

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice :D :D

Alas I just packaged up my MK-II, as I'm moving around so I don't have it anymore :( Will be a few more weeks before I can pick up this again, but with the CRC calculations figured out the rest should be pretty easy from what I've seen!

Here is what I've go so far though:

Quote:

General Command Syntax

[Sync Byte] [Message Count] [Data] [Checksum]

Sync Byte: 1B

Message Count: Computer increments this every time it sends a message, JTAG responds
with same value that was sent to it.

--------DATA SENT TO JTAG-----------

COMMANDS
00 01 00 00 00 0E 01: Sync

00 01 00 00 00 0E 13: Erase Device
00 01 00 00 00 0E 14: Enter Programming Mode
00 01 00 00 00 0E 15: Leave Programming Mode

--------RESPONSES FROM JTAG---------

00 1C 00 00 00 0E 86 01 FF s1L s1h 00 FF s2L s2H 00 00: Sync response including version info

00 01 00 00 00 0E 80: OK

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

c_oflynn wrote:

Quote:

General Command Syntax

[Sync Byte] [Message Count] [Data] [Checksum]

Sync Byte: 1B

Note that hex 1B is the Escape character.

ESC [Message Count] [Data] [CRC]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just in case anyone is still following this thread -

I have attached a zip file which contains C code for CRC calculation of DebugWire messages. Routine was tested using message captures provided by c_oflynn. CRC values returned are correct.

One less hurdle to overcome.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

springob wrote:
I think I got the CRC parameters :D
initial: 0xFFFF
poly: 0x1021
mode: reflect input, reflect remainder
The CRC is calculated over all bytes(including 0x1B), byte order is MSB, LSB

Try http://www.joegeluso.com/software/articles/ccitt.htm

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This thread is way over my head, but I have to ask about

Quote:
wierd stuff on the bottom of the board that you had to peel off

j.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

j_sorensen wrote:
This thread is way over my head, but I have to ask about

Quote:
wierd stuff on the bottom of the board that you had to peel off

j.

I don't have a MarkII, but I'd guess conformal coating (to keep out moisture). Our board stuffer is using some really thick gunk nowadays--nothing like the spray cans of stuff that we use in-house.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
wierd stuff on the bottom of the board that you had to peel off

This is used to keep solder out of the connector holes during solder reflow.
It allows the user to add connectors without using solder wick first.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So what are the connectors? The 6 pin connectors look pin 4 pin compatible to the STK500 6 pin SPI header.

What's the 10 pin headers for?

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pdvorak wrote:
Quote:
wierd stuff on the bottom of the board that you had to peel off

This is used to keep solder out of the connector holes during solder reflow.
It allows the user to add connectors without using solder wick first.

Peter

You got it right. Except it's likely not for the purpose of letting the user add connectors at a later dat. But rather to allow the pogp pins used during programming and test to align in the hole, instead of potentially skidding off of a solder bump. I sincerely doubt that Atmel want's us to modify, or even access, the board.

sxpilot450 wrote:
So what are the connectors? The 6 pin connectors look pin 4 pin compatible to the STK500 6 pin SPI header.

What's the 10 pin headers for?

Colin posted the pin-out on the first page. One os for ISP and the other is for JTAG, for each of the 2 micros on the board. These are production connectos, and are not likely meant for end-user use.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Glitch! Missed that part.

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
I sincerely doubt that Atmel want's us to modify, or even access, the board.

*remembers the good old days of appnote AVR070*

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much of the protocol has been reverse engineered so far?
Once a significant portion has been discovered, I would be willing to help document what has been found in a format similar to AVR060:
http://www.atmel.com/dyn/resources/prod_documents/doc2524.pdf

That should be a good start toward figuring out how to modify AVaRICE to support the mkII modules (or perhaps fork a new project, AVaRICEII, until it is clear the best way to support both modules from a combined tool).

-- Chris Caudle

--
Chris Caudle

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I've actually started modifying avarice to support the MK-II. It seems pretty easy (so far!), I'm actually making what is basically a seperate avarice with MK-II only support right now, then later will work on switching between the two.

This way I can check the protocol as I reverse-engineer it..

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Purely from an administration point-of-view, it would be best to keep one project, avarice, and modify it to support both devices, probably with a command-line option. Mainly because the avarice project is already set up on SourceForge, has active maintainers, etc. Plus, there's no sense in duplicating communication code by having two seperate projects. That way, when avarice is ported to using strictly win32 calls instead of requiring Cygwin, then it's done for mark I and mark II.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Yeah - I do inteand on doing that, but for now I'm just making a jtagmkio.c file instead of a jtagio.c file, and so forth.It will be a simple matter to make the code switch between JTAG ICE and MK-II I think, for now I'm just making a low-level interface to the MK-II that uses the same high-level calls as the JTAG ICE, so almost no high-level code will be changed.

--Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

c_oflynn wrote:

for now I'm just making a jtagmkio.c file instead of a jtagio.c file, and so forth.

That was exactly the approach I was considering. If the code is already modularized in such a way that you can keep the function calls identical for the new version, it should be straight forward to add an entry to the make file which generates a new executable avariceii that links in jtagmkio.o instead of jtagio.o, etc.
Eventually it would be nice to have a single executable, but as a quick way to get something working, two executables built at the same time from the same source tree would be a good second choice.

I found a USB sniffer program that I can install on my Windows machine. Hopefully the USB connection is just a simple translation of the same commands used on the serial port, which would make it pretty simple to make a USB driver for the mkII. I was searching around a week or two ago for Linux USB information, and it looks like support for USB serial style devices has been added as standard recently, and there is some infrastructure in place for writing user mode top layer drivers, so a driver to support the mkII might not even require any kernel hacking.

-- Chris Caudle

--
Chris Caudle

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Hobbyist and small users can/do/may become large users at some time in their career, so it's nice to keep them happy. :D :D :D
Of course one does remember the companies that were nice to them in their electronics infancy and may tend to remain LOYAL clients (that's something that has gone out of fashion). OK I know the above is off topic, back on topic, Colin keep on cracking :wink:

More to the point, it would be nice to see all the commercial tools that are available working with the JTAGICE MkII, so that we aren't forced to use the dreadful AVRStudio for debugging (I use the IAR tool suite).

But Atmel are known to have a big issue with regard to releasing emulation information; that's why no one but Atmel makes a full ICE for the Mega series parts.

If Atmel staff are reading, rethink your strategy. Increasingly, developers aren't going to use devices for which third party emulation is unavailable (I've decided to drop Atmega parts on my next commercial project for precisely that reason).

Regards,

Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cstocks wrote:

But Atmel are known to have a big issue with regard to releasing emulation information; that's why no one but Atmel makes a full ICE for the Mega series parts.

It wouldn't even be so bad if Atmel never documented the JTAG or DebugWire interface, and were the only vendor making an ICE, if at least the interface between the development machine and ICE were documented. That way you could at least use whatever debugger you wanted with the Atmel ICE.

-- Chris Caudle

--
Chris Caudle

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

c_oflynn wrote:

I've actually started modifying avarice to support the MK-II.

Any updates? Making progress or stalled for now?

-- Chris

--
Chris Caudle

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mostly stalled on account of time right now...

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all

I just got an email from the avr supportpeople at Atmel saying they expect to release the protocol spec in about 6 months.... (about4 months too late, I'd guess)