I think it worked after I rebuilt the the hex file.

when I hit programmed I get

Getting isp parameter .. SD=0x06 Ok OK
Reading flash input file .. OK
Setting mode and device parameters .. OK
Entering programming mode OK
Eraseing device ... OK!
programming flash .. OK
reading flash OK
Flash contents is equal to file OK
Leaving programming mode OK


So I think it programmed the chip I am going to stick a led in and see if it blinks.

Anyway could you explain what the avr simulator changed that made it work?
Or was it just the fact I was at to many Hertz while programming.

 

Also can we go thru some of the stuff on the fuse and lockbits tabs. just so I know these tabs. Because most of the other tabs are pretty straight forward to understand.

I also noticed that eeprom verify doesn't work it says address 0x0000 is 0xFF should be 0x0C. <--gives a warning pop box . Maybe it is something that was screwed up n fuse or lockbits.
Say's lockbits is 0xFF

But both the eeprom and flash program button gives the same status messages.

 

I think it worked after I rebuilt the the hex file.

when I hit programmed I get

Getting isp parameter .. SD=0x06 Ok OK
Reading flash input file .. OK
Setting mode and device parameters .. OK
Entering programming mode OK
Eraseing device ... OK!
programming flash .. OK
reading flash OK
Flash contents is equal to file OK
Leaving programming mode OK


So I think it programmed the chip I am going to stick a led in and see if it blinks.

Anyway could you explain what the avr simulator changed that made it work?
Or was it just the fact I was at to many Hertz while programming.

So glad to hear you are on your way to unleashing the AVR on your favorite fun projects.

As for an explanation into what exactly made the difference I cannot say for sure. You may want to get back with the guys in AVRFREAK to let them know what you did to get your programmer to work.

When using a solderless bread board it is a good practice to use several bypass capacitors on the power supply lines to keep power supply noise to a minimum. The good thing about solderless breadboards is that if your circuit works in the noisy environment of the solderless breadboard, it is bound to work well when you solder it onto a more permanent breadboard.

You can try to set your speed back up to a higher speed but you may encounter failures at higher speeds.

Just to let you know, you should be aware that when using the internal RC oscillator, you can get into a problem if you accidentally select an external crystal or system clock source. The atmega32 will act like it is dead but it is just unable to talk to the programmer to put it back into the internal clock mode. One way to get things back to working is to connect a crystal to the atmega32 long enough to reset the fuse that selects the internal RC oscillator.

Please feel free to post here with any problems that may arise in your projects.

hgmjr

 

Also can we go thru some of the stuff on the fuse and lockbits tabs. just so I know these tabs. Because most of the other tabs are pretty straight forward to understand.

I also noticed that eeprom verify doesn't work it says address 0x0000 is 0xFF should be 0x0C. <--gives a warning pop box . Maybe it is something that was screwed up n fuse or lockbits.
Say's lockbits is 0xFF

But both the eeprom and flash program button gives the same status messages.

As for settings on the "FUSE" tab, there really should not be anything checked except for the SPIEN checkbox with the little red question mark in it. That is normal.

SUT_CKSEL should be set for the internal RC oscillator clock speed that you wish to use. Brown-out should be disabled for now. You can read up in the datasheet for the ATMEGA32 to find out more about what that does.

What boxes are checked on your FUSE page at the moment?

hgmjr

 

Correct me if I am wrong but if I stick a LED in pin 40 to ground shouldn't I get the led flashing?

I stuck anode of led into pin 40 and cathod to ground

#include <stdio.h>
#include <AVR\io.h>
void delay(void)
{
    unsigned int i;
    unsigned char j;
    for (j=0; j<10; j++)
    {
         for ( i=0 ; i < 65000 ; i= i + 1 ) ;
    }
}
int main()
{
   DDRA=0x01;
   while (1)
   {
      PORTA = 0x01;
      delay();      
      PORTA = 0x00;
      delay();
   }
return 0 ;
}

 

Correct me if I am wrong but if I stick a LED in pin 40 to ground shouldn't I get the led flashing?

I stuck anode of led into pin 40 and cathod to ground

#include <stdio.h>
#include <AVR\io.h>
void delay(void)
{
    unsigned int i;
    unsigned char j;
    for (j=0; j<10; j++)
    {
         for ( i=0 ; i < 65000 ; i= i + 1 ) ;
    }
}
int main()
{
   DDRA=0x01;
   while (1)
   {
      PORTA = 0x01;
      delay();      
      PORTA = 0x00;
      delay();
   }
return 0 ;
}

Did you put a current limiting resistor in series with the LED?

hgmjr

 

No, should I do a 100 ohm?

But pin 40 is the correct pin anode goes to 40 cathode goes to ground ?

Do I need to un plug all the connections made be the programmer?

And most important how much volts and current are suppose to come out of the pins?

I am going to measure it with my multimeter right now.

 

You should probably go with something between 200 and 300 ohms. 100 ohms may be a bit too low in value.

You should be able to keep the programmer connected all the time if you like. Make sure to observe the precaution of the series 100 ohms between any of the programming signal pins and any loads they happen to be connected to.

Pin 40 is the one that your program is toggling. Change your program and try another output if you can't get PA0 to work.

hgmjr

 

When I unplug the programmer from the usb and plug it back in. My red Led stay's on but when I unplug the programmer it turns of.

seems that the led is dropping .5 volts across it when it is on.
How much are the pins suppose to output (i.e what is the voltage range for the pins )
is it still suppost to be somewhere between 4.5 to 5.5 volts ?

 

The ATMEGA32 io pin should not be connected directly to the LED with its cathode to ground. You should have a series current limiting resistor between the ATMEGA32's output and the LED's anode. You are correct to connect the cathode to ground.

hgmjr

 

Rlimit >= (Vcc - VfLED) / DesiredCurrent

So for example, if your Vcc = 5v, your LED's forward voltage is 2.1v, and you want 15mA current:

Rlimit >= (5v - 2.1v) / 15mA = 2.9 / 0.015 = 193.333... Ohms.
193.333... Ohms is not a standard resistor value. Here is a table: http://www.logwell.com/tech/components/resistor_values.html
Looking at the light green columns (E24), you'll see 200 Ohms is a standard value.

Check your AVR's datasheet to ensure that it can source or sink the desired current.

 

Ok I put a 220 ohm resistor between the PA0 and Leds anode.
But the led is all ways on I even re programed the chip to
use this delay

for (j=0; j<10; j++)
{
for ( i=0 ; i < 65 ; i= i + 1 ) ;
}

but it is still always on?

And the wierd think is when I unplug the programmer the led goes out?
The chip should be working with just the battery and itself.

But right now I am leaving the programmer connected because I am eventually going to but something useful on it.

Any reason why this is not going to work ?

 

As a quick experiment, comment out the statement in your main routine where you set the PA0 high. Recompile and then download the program and make sure that the LED stays off. Then you can try just commenting out the statement that sets PA0 low and make sure that the LED illuminates.

That is the beauty of having in circuit programming. Such an experiment 10 years ago would have involved erasing an eprom then reprogramming the eprom. It might take 15 minutes or more. Now you can do the experiment in less than a minute.

hgmjr

 

OK , I will try that.
But I am curious to know why when I unplug the programmer the led goes out. The power and grounds are still connected to the chip as well as
reset pin to VCC with a 10kohm resistor in the middle.

I will get back to you after I try it .

 

Yes when I comment out
PORTA = 0x01;
I get the led off and when I comment out PORTA = 0x00; I get the led on.

So it must be something with the delay being to long or short or some logic error in delay that I don't see.

But another thing that is bugging me is why the programmer has to be connected to the usb to have the led on regardless of the commenting in or out.

Because in theory I should be able to disconnect the wires of the programmer and the chip should run the program without the programmer.
However I am not ready to pull out all the pins to verify this and be wrong for some reason. Plus this was just a dummy test program to see if it would work.
It doesn't fully work at least for the flashing of the leds.

I don't know wtf. ahhhhhhhhhhhhhhhhhhhh

Anyway I will probably make a permanent board for programming the chips using a chip 40 pin socket solder onto a permanant board. That is after I can figure out the bugs in this stuff.

 

You may need to carefully check your wiring. It sounds like a wiring issue is involved.

hgmjr

 

Is their any difference in programming the chips program to flash or eeprom.
Because if size is not an issue which one is better and why?

 

The flash memory is intended to be used for program code. The eeprom memory is intended as a place to store data that you want to remain unchanged when the device is powered down. Writing to eeprom takes in the neighborhood of 10 milliseconds. That makes it more suited for storing values that do not change very often. Eeprom memory also has a finite number of writes that can be made to any one location. I think the limit on the number of writes is 10,000. It can still be written to after 10,000 writes but the data retention is not insured at that point.

hgmjr

 

Ok , but either way if I write my program to flash or eeprom it should run after I reset it?

 

Nope. The AVR will not execute programs out of eeprom space. The executable code must run out of flash memory.

hgmjr