JTAG ICE Clone for ATMEGA32

Last post
41 posts / 0 new
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

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

hehe, whats an aussie doin on these forums?
Nice to meet you.

Yes I did stumble across your website while goolging for ideas.

The motivation behind me doing this was because:
1. ATMEGA16's are more expensive in NZ
2. Why buy ATMEGA16's when u can get ATMEGA32 where 32's have more memory.

I have uploaded another version of the hex file since Studio 4.12.640 forces the JTAG ICE unit to be updated to the latest version. (Version 4.13 however does not force?? Strange that...) Anyways, both firmware versions (0x7F and 0x80) for the m32 are available.

Attached is also the schematic. No external xtal is required. All files have been tested with the m32 and correctly work. But theres always an exception!

Fuses:
2048 bytes Bootloader size
Reset Vector = Bootloader reset vector.
8MHz internal clock.

I think that's it.

1 limitation. To upgrade, the user must place jumper 1 to ensure that the Input Pin (D4) is pulled low. The user must then cycle power to boot into the bootloader, and from there AVR-Prog is used to upload the .hex.

dl8dtl: I don't think they intentionally mixed and washed the code. It's just that some of the code uses directives. When passed through a disassembler, this comes out at executable code - which it is not.

Julie's done what I reckon WAS the impossible. kudos to you JP. More specifically,

Quote:
Jporter: 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.

CoronaFire: Yes please DO direct your friend here, i've acually done an update since....

And yes, who needs that stupid-hard-2-get 7.3xtal pricier than the uP itself?

Nice work on adding your additions to the bootloader. However porting the JTAG ICE firmware isn't as simple as porting only the bootloader.

Differences in bootloader sections (which are referenced by the firmware) and interrupt vectors are different between the m16 and m32.

So you really do need to do some disassembling to get the firmware working on the m32.

Attachment(s): 

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

Upgrades:
Upload these via the supplied bootloader. The bootloader supplied MUST be used as this configures the bootloader calibrates teh oscillator to 7.37MHz so you dont need an external xtal.

Attachment(s): 

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

hi, yeah I realized from your earlier posts that changing the bootloader isn't enough, which makes sense.
I like your osccal stuff, that's a neat idea. My only question with it is what does it calibrate from, ie how sure is it that it's accurate enough to maintain the usart speed?
What I meant when I posted my bootloader was to propose you could try a combination of my bootloader and your jtag code. If you put my bootloader on, and then use that to load your jtag file, then my bootloader will patch the usart setting part of your jtag code to use my usart speed stuff instead, and then you can use a cheap xtal (or a usb chip like me ;) and be certain of the usart speed. This was you'd get an isp programmer too :)

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

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

Quote:
The bootloader supplied MUST be used as this configures the bootloader calibrates teh oscillator to 7.37MHz so you dont need an external xtal.

I like the idea of not having external crystal. But internal RC oscillator is not as stable as crystal. When the temperature changes it lose calibration and you can not properly send data through RS232. In such situation you never know where is the problem: in JTAG or in your circuit? For development it is better to have robust JTAG with more elements them JTAG you can not trust. ;-)

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

dl8dtl wrote:
> 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).

Hi Jörg;

I would agree with that observation. Mostly I was mentioning this for the benefit of the OP.

I still think the JTAG ICE was planned to be more open like some of the other tools, then a new manager came in and made to look good protecting the company from something or other.

I learned some really useful tricks by looking at the optimized compiler code. I prefer to code AVR in assembly for the most part. Not having an IAR compiler I would not be at all surprised if that was the source compiler. I did not find the code to difficult to understand, Perhaps as I am more at home in assembly.

There are a few places where it loads something into a register then trashes the register without use. The AVR instruction set is so close to C that I can write some pretty tight code.

I do find it amusing that the Tiny25 has so much flash and SRAM. What I do not like about the compiler code is that it uses LDS/STS to access SRAM. These things are a huge code space and performance hit. Not good when working with MIDI and timing is critical.

On the other side, I am glad to learn the ijmp instruction. I never liked making case statments with cmp/brne trees. Hard to maintain. With ijmp and a Table in flash, no more fussing about with editing labels. A few shifts and loads then off to the function.

-julie

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

I have had some feedback regarding the circuit.

1. Targets lower than 4.0V do not work/ are not detected by the programmer.
&
2. The ISP Pins do not work/What are they use for.

----
After some testing I found too that I had some trouble getting it to debug devices running off a low voltage. However I have come up with a working solution.

Try the following:

Create a voltage divider to halve the voltage coming from the 4 JTAG voltage lines. I have used 10k resistors, and these seem to work fine.

With this modified setup I can debug targets in the range of 2.7V to 5.1 Volts (i have not tried targets > 5.1V but I think they should work).

You need to create this voltage divider to act as a (albeit 1 way) level shifter.

As for the ISP Pins, they are used to upgrade the firmware of the JTAG ATMEGA32L device. It uses the SP12 setup and if you connect the ISP pins to the corresponding Parallel port pins, you should be able to re-flash the ATMEGA32L using AVRDUDE or SP12. Look at the SP12 pin connects.

I hope these answer your questions.

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

Oh btw, if you are using this setup, be sure not to use long lines for the JTAG lines. JTAG frequencies in AVR studio can be quite high, and using an oscilloscope, I found that the time periods were in the order of nano seconds.

So if long lines are use, they'll have high inductance which act as chokes at that high frequency.

If you are not sure, use a 1.2k (high side) and 2.2kohm resistor (low side) as the voltage divider.

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

Hello John,
please help me.

I have programmed your bootloader in a ATmega32 MC.
Then I used the schematic above to connect all pins. Only the RX/TX-pins I have connected via USB->serial adapter IC (FT232 from FTDI)

When I try to connect the bootloader with AVRprog I get an Error.
"No supported board found! AVRprog version 1.40"

With The Bootloader from CoronaFire (www.floppyspongeonline.com) I have no problem to connect and programm. So I think the RX/TX pins are connected right, USB->serial adapter is working and AVRprog is installed right.

Then I used a serial-port sniffer. To see if your bootloader respond on the messages send by AVRprog.

AVRprog sends:
(as ASCII chars with "\27;" = the char with the dezimal value 27)
\27;\27;\27;\27;S\27;\27;\27;\27;S\27;\27;\27;\27;S\27;\27;\27;\27;\27;\27;[AVR-Tools-upgr]\27;\27;\27;\27;\27;\27;\27;[AVR-Tools-upgr]\27;

And your bootloader responds:
(here as Hex values)
xFE x38 x38 xF8 xFE x38 xF8 xFE xF8 xFE x38 x38 xF8 xFE xF8 xFE xF8 xFE xF8 xFE xF8 xFE x78 xFF x98 x98 x38 xF8 xFE x38 xFE xF8 xFE x38 xF8 xFE x38 x98 x98 xF8 xFE x98 xF8

(and here is the same output as dezimal values)
254 248 254 248 254 248 254 056 248 254 248 254 056 248 254 248 254 056 248 254 056 152 152 152 152 152 152 152 152 254 248 254 056 248 254 248 254 152 152 248 254 152 248

Do you know what is going wrong. The bootloader from CoronaFire respond on the first "S" from AVRprog with "AVRBOOT".

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

Yes, to enter bootloader mode, you need to have PD4 pulled down to ground.
Better yet, just upload Version80.hex and move PD4 to high (Jumper position change).

It should be ready for JTAG'ing.

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

Quote:
Upgrades:
Upload these via the supplied bootloader. The bootloader supplied MUST be used as this configures the bootloader calibrates teh oscillator to 7.37MHz so you dont need an external xtal.

Hi John! I could not use your bootloader32.hex with internal 8MHZ Crystal, Its not responding to 'S' in Hyperterminal. But if I use 7.2 MHZ crystal and I use IsoJtagISP_2.5_m32_7.3728MHz.hex of CoronaFire it is responding to 'S' & "JTAG" is also working properly. But what is my problem is exactly is I get this message sometimes when I start Debugging

"Error loading object file D:\Projects\AVR Series\ATmega32\TemperatureDisplay\default\TemperatureDisplay.elf"
"Coordinator: Error when writing memory contents to the debug platform.
Coordinator: Error loading object file."

and also in between single stepping through avr-studio "debug command could not be executed" message is comming.
my guess is that this may be due to because i`ve used
7.2MHZ crystal instead of 7.3728MHZ & unfortunatly i could`nt get it & i like to try your internal 8MHZ bootloader32.hex. Please help me.

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

You've only loaded the bootloader.hex, you need to open up AVRprog in AVRstudio and load the JTAGICE.hex's.

As for the debug error, it looks like a communications error. Make sure the frequencies and baud rates are good and that the cable lengths are short.

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

Quote:
You've only loaded the bootloader.hex, you need to open up AVRprog in AVRstudio and load the JTAGICE.hex's.

As for the debug error, it looks like a communications error. Make sure the frequencies and baud rates are good and that the cable lengths are short.

I think you did`nt understand my problem "John". The "bootloader32.hex" whatever you have given for working with internal 8Mhz is not working properly (not responding for 'S' in hyperterminal). But if I use 7.2 MHZ crystal and I use IsoJtagISP_2.5_m32_7.3728MHz.hex of CoronaFire it is responding to 'S'. so please help me!

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

krishna.velu wrote:
Quote:
...

But if I use 7.2 MHZ crystal and I use IsoJtagISP_2.5_m32_7.3728MHz.hex of CoronaFire it is responding to 'S'. so please help me!

I suspect that the boot loader is expecting to use the internal oscillator. I to not think that an 8MHz external can be calibrated to 7.3728MHz. Studio is pretty finicky as to the baud rate. I have no experience with the *nix command line tools. There may not be a baud rate divisor, which can generate the correct rate at 8MHz.

Also note that the divisor is hard coded in two places. One is in the boot loader. This copies the hex file to a location in memory. (Most clones have this set to the wrong address.) Inside the *.hex is a function which sets the baud from a table. Only the 7.3728MHz values are defined.

My patch for the Butterfly, patched this function to use the soft calibration of the internal oscillator.

-julie

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

Quote:
I suspect that the boot loader is expecting to use the internal oscillator.

I`m using internal 8MHZ crystal only. so wahatever code written for calibrating 8MHZ to 7.3728 it should work, but its not! can some one explain me what exactly have been done in that code!

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

Are you using the correct Baud Rate when communicating to the Bootloader?

Once the bootloader is up, load up the JTAG ICE hex files using the AVRBoot program.

Also make sure that the PD4 is I think pulled low. You need to set it to low in order for the AVR to enter the bootloader on power up.

To run the actual program set the PD4 back to high.

Cheers,

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

where i can found source code and full shcematic for jtag ice clone for atmega32 (works well, tested)

anybody can help me??

every night i try to open http://www.floppyspongeonline.com/automation/isojtagisp/isojtagisp.php
and that site was not redirecting correctly

anybody can help me??

thank you

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

For me that floppysponge link successfully redirects to:

http://www.alelec.net/isojtagisp/isojtagisp.php

 

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

really?? 4 hours ago i still can't enter that site. ok i'll try.

thanks clawson

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

can u help me with the pcb layout for jtag ice clone using atmega32
and wht steps shud i follow?
thanx

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

I love Digital
and you who involved in it!

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

ali dehbidi
can u kindly tel me tht wht changs shud i make to use atmega32 instead of atmega16
i wn2 use mega32 for this project

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

take a look at both data sheets if the sfr add and interrupt add are the same you can use it safly.
if it's hard for you to figure it out just try burnning my code to mega32 and see if it works?
it does not harm any thing.and as i have written the stk500 firmeware you can change the mcu in make file and recompile the project!

I love Digital
and you who involved in it!

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

i made jtag ice clone using atmega16
now i wn2 debug my atmega32 board using this jtag ice
can u help me wid it
thnx

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

you can select the debuge platform in avrstudio to jtag ice and connect your ice clone to mega32 via tck tms tdi and tdo pins and be sure to enable jtag and ocd debug fuse bits.

I love Digital
and you who involved in it!

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

Hi, I'll try to be as concise as I can be:

I built the PCB from http://aquaticus.info/jtag
Using an Atmega32 (the only micro I have) bc it said in the page above it could be built with an m32.
Checked the PCB 20 times or so, I'm pretty confident that it's ok, but I'll make another one (better) just to be sure.
Tried all firmwares I saw in this thread to no avail.
The serial cable I'm using is a straightforward one (pin 2 mapped to the pin 2 in the other end, same for pin 3 and with pins 6-4 and 7-8 connected in both ends just as the schematic in the aquaticus page shows).

Tried all baudrates when connecting 9600, 19200, 115200 and none of those made a difference.

The crystal I'm using is a 7.3728 MHz one.

The COM port is working ok.

The fuses used to program the m32 are the ones the aquaticus page says ( http://aquaticus.info/jtag-how-build ) so it's lfuse = 0xff and hfuse = 0xd8

Am I doing something wrong ? Is there some advice for me ?

Really tried everything (a week or so by now) and I don't want to say this thing won me :P

Thanks in advance for any reply ...

Carlos

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

Quote:
I don't want to say this thing won me
..like Germany you mean? :wink:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

You don't have to be THAT mean :D

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

Take heart, we lost to Germany 4-0 too..so we are just as good. :lol:

"La mano de dios" was not with Maradonna this time.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I have bootloader32.hex working and it responds @ 19200 with the string AVRBOOT, now I need a way to upload the Version80.hex firmware to the m32 but I don't have any other programmers than a parallel sp12 and an USB usbasp. Is there a way to "upload" the Version80.hex firmware to the m32 without avrprog ?.

Also, what fuses exactly should I use for bootloader32.hex + Version80.hex ?

Also, I have the PCB from aquaticus, should I change this to the schematic provided by Johntiler here ?:

http://www.avrfreaks.net/modules/PNphpBB2/files/jtagicem32_871.jpg

Cheers !

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

Ok, after about 2 weeks of trial and error with 2000 things, I'm glad to say that this is actually working.

My fuses were lfuse = 0xff and hfuse = 0x18 (using always a 7.3728 MHz crystal) but I couldn't program the following fuse bit with AVRProg:

... "Set the lock bits to protect the bootloader from SPM-writes (Boot Loader Protection Mode 2 in STK500-plugin) so that it can not overwrite itself" ...

So I'm not sure if the JTAG will work ok, but at least I get this recognized by AVRStudio. Now I need to build a new PCB and actually try to use it with a target.

I used this schematic (built it first in a protoboard):

http://www.avrfreaks.net/modules/PNphpBB2/files/jtagicem32_871.jpg

AVRProg doesn't work with COM ports greater than COM4, so in my case that was at COM6 with a PCI serial card I needed to change the port name (under the device manager -> properties -> port settings -> advanced). Then it recognizes the micro with the bootloader32.hex file.

As I said above, I had problems when writing the fuse bits with AVRProg but not having trouble to actually write and verify the Version80.hex firmware. Anyone maybe knows why ? I even did this with a 20 cm shielded serial cable, the XTAL with 20 pF capacitors , a 4.7k in the RESET line to VCC, and every other pins that should be connected to VCC or GND (AREF, AVCC, etc).

And even thou I didn't finish to test this, thanks to everyone that made this possible (I'll take care of writing a detailed guide later if everything works ok for others to have a nicer time working on this, also probably a PDF with a nice PCB to etch).

Cheers !