Hello there,

I'm trying to program an Atmega325 with an usbasp ISP programmer. Problem is, my MCU is getting VERY hot only after a few seconds connected. I've searched for possible short, but found nothing.

I was wondering if there was a typical mistake that might explain it. (Or, even if I doubt it, perhaps it's usual for it to become hot?)

Here are the pins connected:

Connected to 5V: -AVCC -AREF -VCC (2)

Connected to ground: -GND (3)

And the usual communication pins: -Mosi -Miso -Sck -!reset

Also, I already soldered a 14.75MHz crystal on the xtal1 and xtal2 pins. Can this interfere with the programmer?

Oh, and on the 10 pin IDC connector, only the last GND seems to work.

Thanks in advance!

Frozenlock

It almost sounds as if you accidentally wired the ISP backward. The photos you show would represent a top side looking down view of the socket the programmer would plug into. If it were wired backward, that could explain it heating up.

Sometimes the pin 1 position is labled on the board for the programmer. For instance, on my parallel programmer (ISP Plug on the board on the top right) you can see pin 1 of the port is labeled. Your USBASP may be labeld as well.

Also, while I'm not familiar with your specific USBASP programmer, some of those devices provide power from the USB for programming, some require external power, and some have a jumper to select between external or USB power. Make sure if yours is providing power from the USB that you do not supply it separate power on board. If you do supply power on board you should disable the USB power.

Rick

When i started with my usbasp i was confused when i was getting 5v on the wrong pin. Turns out i was looking at it from the bottom not the top after putting the ribbon cable on. Use your multimeter to check if this is the problem as Rick_S suspects.

It was EXACTLY that!

Thanks guys!

Now I want to hide in a dark corner... wiring backward, sheesh...

Backward wiring is easy to do. Trust me when I say, it will probably happen again.

For instance this happened to me. The other day I purchased a capacitance meter kit. I assembled it, and it worked great. However, I noticed that the power jack was a bit crooked. So what do I do? I fire up the soldering iron and while the 12vDC wall wart is STILL PLUGGED INTO THE JACK, I proceed to melt the solder holding the jack so I can straighten it. Guess what... As I'm melting the solder the barrel of the iron shorted the 12V to a pin on the 7 segment led display... a pin that was directly tied to a leg on the micro-controller. It damaged the micro-controller. Talk about wanting to hide in a dark corner...

So don't feel bad... :D BTW, Does your micro-controller still work?? At least mine mostly did. The output on that leg would go high but it wouldn't pull to ground. This caused one of the digits on the display to be so dim you could hardly read it. I bridged a resistor from ground to that pin and that " fixed " it. At least it didn't fry it completely.

Soldering while the components are still wired, that's... brave! ;-)

I suppose my MCU still works, eXtreme Burner is able to communicate with it. I can read the memory, which is of course blank.

Now I want to load the NK foodloader in it to be able to use the serial pins. I plan on using the .hex in the bootloader folder. Would that work?

And the fuses, can I just set them as the "fuses_mike.txt"?

Is the chip a 325 or a 328P? I don't know if the NK foodloader will work on a 325 without modification.

It's a 325.

I know they have versions of their modified foodloader bootloader for the 168 and 328p. I'm not exactly sure ( I haven't really looked into it ) what they changed between their version and the original foodloader. You may be able to modify the foodloader code yourself and re-compile it for the 325. You could ask Mike or Humberto to see if you can find out what they change.

Good luck,

Rick

Ok, I've checked what was the footloader. It's a little serial bootloader made for the atmel AVR mcu.
Foodloader

By tweaking most of the files, I added the atmega325 to the list of supported devices. I also discovered that I have an atmega325P and not an atmega325/V. I have absolutely no idea what the differences might be. The datasheets are horribly similar.

So, now that my file is compiled, I have a shiny new hex file ready to be uploaded. As I said earlier, I use the software eXtreme Burner to talk to my mcu. It says that my hex file is too big for the atmega325P. It seems to be the case, as the file is 2.84kb on the drive. Yet, the cmd window said it was 1018b when it compiled it. Furthermore, the original foodloader.hex in the bootloader folder is also around 3kb, so I suspect the file to be the correct size, and my application to be flawed.

Next step will be to try it using AVRdude.

Frozenlock

Wait a minute... the bootloader is supposed to be loaded in the flash memory! I have 32kb, Way more than necessary!

Anyway, I really have to try it with AVRdude.

I'll keep you informed.

The 325P is a version of the chip that has a low current power save mode and draws only 40 nA in power down mode. See the snippets below.

From 325/V Datasheet:

• Ultra-Low Power Consumption
    – Active Mode:
       1 MHz, 1.8V: 350 μA
       32 kHz, 1.8V: 20 μA (including Oscillator)
    – Power-down Mode:
       100 nA at 1.8V

From 325P Datasheet:

 • Ultra-Low Power Consumption
    – Active Mode:
      420 μA at 1 MHz, 1.8V
    – Power-down Mode:
      40 nA at 1.8V
    – Power-save Mode:
      750 nA at 1.8V

I believe that is the major difference between the P versions of the processor Vs. the /V version.

Rick

One other thing, don't forget to set your fuses properly for a bootloader. Read the fuse section of the datasheet of the 168 and the 325 - they may be different. Then based on the fuse setting requirements, set the appropriate fuses for the bootloader in your 325 prior to flashing.

Thanks for the info Rick!

I also discovered that the bootloader address is different in 325/V and 325P, which explain why I had the message "hex too large for microcontroller". Once this minor error rectified, it loaded easily in the mcu.

I did set my fuses with the help of this online calculator.

Now I'll switch to the nerdkits' communicator. Wish me luck! :-P

Frozenlock

I have no idea which pin is supposed to tell the mcu if it's in programming mode or in run mode. It's pin 14 on the nerdkits' mcu. Perhaps it's location is determined in the foodloader.c. I'll take a look...

Found it in the config.mk.

It worked! I loaded a program in my MCU using the nerdkits' communicator. Now I can take over the world! Muahahahaha!

Unfortunately I think I erased my bootloader in the same process, as it only worked once. I will check my fuses setting more closely.

Frozenlock--

yes, only the NK foodloader cares about pin-14. Most other ISP Programmers pull pin-1 low instead for it-- it depends on the ISP.

As for connecting backwards, may I direct your attention to the humble diode. I always put a diode in now. I've never burned anything up yet-- but I came really close to doing it. And I immediately went and put a diode in before going further.

BM