JTAG ICE Clone for ATMEGA32

41 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,
I'm porting the Upgrade.ebn file to use an ATMEGA32.

Obviously it isn't an easy task. But anyways, I'm thinking that the only major differences between the 16 and 32 are the interrupt locations and bootloader locations.

I've disassembled a hex file which has both the bootloader and JTAG interface (upgrade.ebn) software on it.

I've also redirected the interrupt vectors. I've also positioned the bootloader start to 0x3800. For the ATMEGA16, I think it is normally positioned at 0x1C00. For the jmps can calls which point to the ATMEGA16 bootloader locations, I've redirected to the corresponding ATMEGA32's locations.

It however still does not want to work. There seem to be some jmps and calls to locations which have no data. Eg. there is a jump to 0x1E00 which I assume could be the start of the bootloader for the ATMEGA16...

I've run out of ideas on how to get this working on the ATMEGA32. Any ideas?

I know that jporter has ported the JTAG ICE firmware to the butterfly. But I'm not sure how I can implement it for the ATMEGA32.

http://avrfreaks.net/index.php?module=FreaksAcademy&func=viewItem&item_id=568&item_type=project

Any help would be appreciated!

Anyhows, I've uploaded the miniice.hex file as well as the disassembled code. If anyone wants to have a look.

Attachment(s): 

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

Julie Porter (jporter) on here did this exercise once already - porting the code to a 169 (I think it was?). You may want to contact her for advice on exactly what needs to be changed to port the binary.

Cliff

EDIT: see -

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=219583

 

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

The code I ported Which is several revisions back uses jump tables after the interrupt vector. If you search through the disassembled code you will see some ijmps. You are correct about the bootloader call. That is a major problems with most of the clones, an incorrect bootloader address which prevents firmware updates.

Look up how ijmp works by loading data into the Z register then jumping to that address. So what comes after the interrupt vectors is data, not code. This is the jump table which contains some data other than the jump itself. Since the code indirectly jumps, when you look at the disassembly you are disassembling data.

If the input instruction is subtracted from a has value of differences you only need to subtract the data byte in the from the prior byte read into the input ring. So if you have the command codes 'M' and X to find the index in the table, subtract 'M'-X and then search for this difference. Other parameters in the jump table are used to set the depth of the C stack frame for the passing of arguments to the function. Calculate the right hash and your commands are one table entry apart. This is why reverse compiling is a major undertaking. Be glad this is Harvard architecture. With von Nueman, It is common for the data to be self modifying.

The mega32 has twice the flash, which may affect some of the jump table offsets. With the butterfly, It is still a "mega16" underneath the extra I/O ports.

The main contention in porting was the change of the SRAM start from 0x60 to 0x100. I did that with a search and replace on the ldx/stx access instructions.

The other watch point is the ADC code that monitors vtarget. The ice wants to go into safe mode when the two target device lines are not at the expected state. One line is digital the other monitors the target voltage.

The ICEBUT remains more of a novelty with the limited device support. There is still the use as a teaching aid in a Butterfly to Butterfly environment. A way of evaluating what an ICE can do. I did this before the dragon came out so that pretty much did in the need for a simple ICE clone.

Never delved into the TAP controller most of which is documented in the device data sheet. Perhaps you can figure out a way to extend the devices supported.

While this was a fun exercise and I learned a few things about programming AVR (especially the use of the ADC.) I went with a dragon and then a JTAG ICE MKII for my day to day work as I am using mega88 and tiny chips.

-julie

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

Hi there, thanks for your reply.

Julie, looking at the data/const tables in your hex file show that these instructions are the same as those in mine. When you decode the
".db" lines, they actually just represent the normal JTAG ICE code.

eg. .db " ............................" can be disassembled to be...

subi r20,k61
sbci r21,kE2
sbci ...........

breq L000A

I'm still having some trouble with the port.

Is it possible to adjust OSCCAL to obtain a 7.373MHz clock without the use of the crystal? I don't see why not.

Despite getting scrambled data from the JTAG ICE clone, I don't think it is to do with the clock speed since the bootloader commands are working fine with both 'UBBRL' registers set to 0x17, 19.2kBaud with a 7.373MHz clock.

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

Hi John;

Trust me those .db "instructions" are data. Put this post in a disassembler and it will look like code. The data code thing is why reverse coding is an art and not automated. Many systems intentionally mix code and data to make the reverse even more difficult. You should have been around in the early apple II days. Self modifying code was the norm, with traps for the would be student who wanted to study it by reversing.

I had no trouble making the ICEBUTT work with Gorgios calibration routines on the butterfly. Studio sends the 'raw' calibration byte as per the mega 163 rather than the 'code' byte documented that is returned on a query in the the protocol. This happens every time you change the page in the AVR Studio programmer from the advanced pane to the pane with the voltage readings. Since the voltages are wonked anyway, the trick is to leave the pane on advanced. Switching to the program of fuse panes does not seem to do the baud reset. The user can always use the baud popup to force the baud back after a reset. I think this was that I did not go with the 19.2kBaud, but opted to use the 9600 baud required by AVRISP. The Br@y's term was a real help as I recall. If it works in the boot it will work in the main code. Studio as I recall does require the initial handshake to happen at the lower baud. It will up it if it wants to.

Personally I see no need to work with the clones anymore. They made sense in a pre-dragon world. These days with USB I forget about all the issues with baud and clocks. I managed to get the tools I needed by offering to do a project for the cost of the tools and I keep the tools. With the current promotions on the bundles, it is not worth it as time to work with ICE clones.

Making a Butterfly into an ICE, was more of a desire to do something useful with a Butterfly. I can not see any practical reason to make a clone out of a mega32. The only reason might be to extend the TAP controller, It took me a few weeks to figure out the front end of the MKI. I figure it would take a few months to work out the TAP controller and the Studio XML files. Not worth it when for a few hundred one can get real tools. And work on practical projects, that never seem to find a market. Still I give advice I do not take as I prefer the Everest approach myself.

-julie

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

That last post did the trick! I was missing some vital information.

Here is the JTAG ICE hex file in its final format to be loaded onto an ATMEGA32.

Attachment(s): 

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

Btw a quick question Julie, how did you know what and where those .db data bytes went?

like, which blocks to set as consts?

JT

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

Johntiler wrote:
Btw a quick question Julie, how did you know what and where those .db data bytes went?

like, which blocks to set as consts?

JT

Hi John;

I read the ASM manual to see what an ijmp did. From that I worked backwards in the code to see what locations were referenced and how the Z register got loaded. This gives the start of the table and the code to work out the hash from the input.

-julie

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

> Many systems intentionally mix code and data to make
> the reverse even more difficult.

I don't think that's the case here. To me, the code looked like
pretty standard IAR-compiled C code (which of course, *is* not
easy to understand due to all the compiler optimizations).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

I might have come a bit late, but you don't need to have it running at 7.3***MHz, it's quite easy to change the firmware to allow other crystal frequencies, as I did for my isojtagisp.
Have a look at my project if you're interested: http://www.floppyspongeonline.com/automation/isojtagisp/isojtagisp.php
although I went an interesting route of getting my bootloader to patch the jtag firmware on the fly as it's updated, so I can still easily put new firmware on. All that's needed for different frequencies is to change the usart prescaler to suit the crystal at each frequency. basically my patch includes a new subroutine that has a lookup table, so that for whatever the prescaler was it has the new value and uses that instead. The on-the-fly patch replaces the line 'out ubrrl,register' and 'out ubrrh,register' with a rcall to my sub. It's worked great for a few different versions of the jtag firmware.

I've actually recently been talking to someone trying to flash my firmware onto an m32 because that's all they had lying around....I guess it's not going to work for them. Thanks for this, I'll put them onto this page for a more relevant hex file....I wonder if my patcher will work on it, I spose it should.

edit: just to confirm - my patching allows the programmer to switch speeds like avr studio expects it to, I can switch to any of the panes I want - except for one issue when I'm using a crystal speed that can't handle the 115200 bit rate, and then switching to 115200 kills it.

Electronics Design and other funky stuff -
alelec Engineering
http://www.alelec.net

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

feel free to try my firmware for yourself, I've got a copy of it here for the original 7.3--MHz crystal on m32, or get the source from my web page and pick your own crystal. This file has the bootloader and everything in the right memory locations for m32, but that's the only change I made from m16.
My bootloader is protected in that it'll update the jtag firmware from a hex like yours and just not write the stuff that's overlapping itself. I haven't tried it myself as I don't have an m32 around, but if you want to be able to program isp stuff as well go for it.

Attachment(s): 

Electronics Design and other funky stuff -
alelec Engineering
http://www.alelec.net

Pages