2
\$\begingroup\$

I wrote a very simple sample code into my atmega8 via avrstudio here it is:

#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 1000000UL
#endif

int main(void)
{
    DDRC = 0xff;
    while (1)
    {
        PORTC = 0xff;
    }
    return (0);
}

I am expecting all the Pins of PORTC give a high(aka 5v) voltage to make the LED kept on(all the time), but the result is all the Pins of PORTC are given a 160Hz square wave with the high voltage about 25%.

enter image description here

For the record the fuse bit was set as:[ Low: E1 High: 99 ] and no crystal.

So what will be the problem?

EDIT

The output of avrdude with which I upload the HEX to the chip:

avrdude.exe: set SCK frequency to 32000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9307
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 32000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: reading input file "C:\Users\ximing\Documents\Atmel Studio\6.2\GccBoardProject1\GccBoardProject1\Debug\GccBoardProject1.hex"
avrdude.exe: writing flash (68 bytes):

Writing | ################################################## | 100% 0.10s

avrdude.exe: 68 bytes of flash written
avrdude.exe: verifying flash memory against C:\Users\ximing\Documents\Atmel Studio\6.2\GccBoardProject1\GccBoardProject1\Debug\GccBoardProject1.hex:
avrdude.exe: load data flash data from input file C:\Users\ximing\Documents\Atmel Studio\6.2\GccBoardProject1\GccBoardProject1\Debug\GccBoardProject1.hex:
avrdude.exe: input file C:\Users\ximing\Documents\Atmel Studio\6.2\GccBoardProject1\GccBoardProject1\Debug\GccBoardProject1.hex contains 68 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.07s

avrdude.exe: verifying ...
avrdude.exe: 68 bytes of flash verified

avrdude.exe: safemode: Fuses OK (H:FF, E:99, L:E1)

avrdude.exe done.  Thank you.
\$\endgroup\$
5
  • \$\begingroup\$ Was there any problem with the programming? \$\endgroup\$ May 18, 2015 at 15:46
  • \$\begingroup\$ @BattleHamster Thanks for notice, but things seems work just fine to me, I post the output of the avrdude in EDIT section, check it out. \$\endgroup\$ May 18, 2015 at 15:50
  • 1
    \$\begingroup\$ Do Avr chips have a watchdog that needs to be disabled, like msp430 chips do? I think the chip is reseting, placing the pins in the default input high z before running your code, then rinse repeat \$\endgroup\$
    – Passerby
    May 18, 2015 at 15:58
  • 1
    \$\begingroup\$ Also think it may be the watchdog. The high-fuses set to 0x99 will have the watchdog enabled so I guess it is resetting... \$\endgroup\$
    – og1L
    May 18, 2015 at 16:03
  • \$\begingroup\$ @Passerby Yes! I disable the watchdog and now things worked as expect! thanks, you should post your advice as a answer if not bothering too much :D \$\endgroup\$ May 18, 2015 at 16:17

1 Answer 1

3
\$\begingroup\$

As confirmed in the comments, the AVR had a watchdog timer that needs to be pet or put to sleep. Without this, the watchdog will dutifully do is job, and reset the microcontroller once the timer elapses. This results in the AVR setting it's pins to their default state, which is most often high Z input state. This explains the on and off toggling of the pins that OP saw.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.