Hi, all. I’m attempting to work through the tutorials and ran into a problem at the very end of tutorial 2 - actually making blink.hex go.
I’ve set things up (at least as far as I can tell), the same as in the tutorial. When I type ‘make program’, it does :
C:\micro\blink>make program
Creating load file for EEPROM: blink_1MHz.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex blink_1MHz.elf blink_1MHz.eep
c:\WinAVR-20070525\bin\avr-objcopy.exe: there are no sections to be copied!
c:\WinAVR-20070525\bin\avr-objcopy.exe: --change-section-lma .eeprom=0x00000000
never used
make: [blink_1MHz.eep] Error 1 (ignored)
avrdude -p atmega168 -P lpt1 -c stk200 -U flash:w:blink_1MHz.hex
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "blink_1MHz.hex"
avrdude: input file blink_1MHz.hex auto detected as Intel Hex
avrdude: writing flash (178 bytes):
Writing | ################################################## | 100% 0.06s
avrdude: 178 bytes of flash written
avrdude: verifying flash memory against blink_1MHz.hex:
avrdude: load data flash data from input file blink_1MHz.hex:
avrdude: input file blink_1MHz.hex auto detected as Intel Hex
avrdude: input file blink_1MHz.hex contains 178 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.06s
avrdude: verifying ...
avrdude: 178 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
C:\micro\blink>make program
Creating load file for EEPROM: blink_1MHz.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex blink_1MHz.elf blink_1MHz.eep
c:\WinAVR-20070525\bin\avr-objcopy.exe: there are no sections to be copied!
c:\WinAVR-20070525\bin\avr-objcopy.exe: --change-section-lma .eeprom=0x00000000
never used
make: [blink_1MHz.eep] Error 1 (ignored)
avrdude -p atmega168 -P lpt1 -c stk200 -U flash:w:blink_1MHz.hex
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "blink_1MHz.hex"
avrdude: input file blink_1MHz.hex auto detected as Intel Hex
avrdude: writing flash (178 bytes):
Writing | ################################################## | 100% 0.08s
avrdude: 178 bytes of flash written
avrdude: verifying flash memory against blink_1MHz.hex:
avrdude: load data flash data from input file blink_1MHz.hex:
avrdude: input file blink_1MHz.hex auto detected as Intel Hex
avrdude: input file blink_1MHz.hex contains 178 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.05s
avrdude: verifying ...
avrdude: 178 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
That looks successful to me. However, I get no blinky led, no matter which IO port I put it on. If I take the tail of the LED and put it to 5V, it lights nicely, so it is wired right, with the resistor, going to ground.
The chip just sits there. I’d suspect it was a reset button problem, since the tutorial warned about that, but if I look with my multimeter at pin 1, I see 5V there, which is, I believe, what it is supposed to be - tied high, right?
I’m running outta things to check. Any advice for a newbie at this?
What tutorial are you using? I was also going to ask what hardware but I can see a reference to the STK200 in your post. Without more information, I would suggest probing the I/O pin that is connected to the LED. If all you have is a DVM you should see the pin change voltages if the blink frequency is fairly low.
dharper:
What tutorial are you using? I was also going to ask what hardware but I can see a reference to the STK200 in your post. Without more information, I would suggest probing the I/O pin that is connected to the LED. If all you have is a DVM you should see the pin change voltages if the blink frequency is fairly low.
I’m using the parallel port programmer that Sparkfun sells in their kit for those tutorials, along with an ATMEGA168
I tried probing the IO pins and all I see is ‘low’ - not zero, but nearly zero voltage. It is as if the processor is powered but isn’t doing anything at all.
Is there any way to find out what it is executing or what, if anything, it is doing? Dump internal state or something? I’m not a microprocessor guy, I’m a programmer
Looking through the code, this is about as simple a program as you can get; it toggles just about every I/O pin at a 1 Hz rate. The output from programming the device indicates that the internal flash contents read back match the file that was programmed. The three things you always check right off the bat when things are not working are:
Is the input voltage good and hooked up correctly? (you indicate it is).
Is reset being asserted? (you indicate it is not).
Does the processor have the proper clock?
The last item is starting to look interesting. Did you compile the program to create your own HEX file or did you program the included HEX file? The AVR can use either an internal or external clock source which is determined by the setting of the fuses. I notice the Makefile has the clock set for 8 MHz but the project parts (if you bought them from Sparkfun) look like they include a 16 MHz crystal.
Also, what AVR are you using? The Makefile says ATMega8 but the parts list says ATMega168.
As for your other question, for those AVR devices that support on chip debug (through either JTAG or DebugWire) you can do hardware debug. However, it doesn’t sound like you have that capability yet.
The input is a filtered, regulated 5 V (well, 4.97V according to my multimeter, but that’s close enough, I believe)
reset isn’t being asserted, as I understand it - that is, the pin is tied high currently and only pulled low when I press a button on the breadboard. I’ve tested this with the multimeter - it is 5V at pin 1 by default, dropping to nearly 0 when I press the button
Ah. Now this might be a question. While the kit comes with a 16mhz crystal, it doesn’t get introduced till Tutorial 3. Until then, we’re using the internal oscillator. Could the chip be confused about timing source? I set that via fuse bits, don’t I? How do I sort out what fuse bits I need to set to get it to use the internal clock?
I’m using an ATMega168 - the partslist got upgraded, but the Makefile did not. I have changed the Makefile to indicate ATMega168 - before I did that, it complained that the chip signatures didn’t match, which makes sense.
I did a ‘make all’, which rebuilt the HEX file. then ‘make program’ which runs avrdude to upload it to the chip. Both of those operations seemed to succeed.
Actually, I didn’t need to ask which AVR you were using - it was right there in the listing. Every AVR has a unique signature built in. By checking the Mega8 and Mega168 datasheets I was able to figure out that it was the 168. However, here’s the rub - the file name is “blink_1MHz.c”. The default internal clock for the Mega8 (the way fuses are set for a new device) is 1 MHz. However, the default internal clock for the Mega168 is 8 MHz. I know nothing about AVRDUDE and am trying to track down the manual. Google says that we can use it to read the fuses; once I figure out how, reading the fuses will tell us more about how the clock is set up.
dharper:
The default internal clock for the Mega8 (the way fuses are set for a new device) is 1 MHz. However, the default internal clock for the Mega168 is 8 MHz. I know nothing about AVRDUDE and am trying to track down the manual. Google says that we can use it to read the fuses; once I figure out how, reading the fuses will tell us more about how the clock is set up.
Cool, thank you very much. I’m at work right now, so won’t be able to try anything you come up with till tonight in any case, but I appreciate all the help.
Huh. How odd. I just went home, turned it on… and it worked. Pretty flashing LED. I’m not sure if it was heat or if something wasn’t seated correctly or what… but it is working consistently now.
Little bit more playing and I think I have the answer - the atmega168 fits very poorly into the breadboard. I don’t know (lack of experience) if that is because this breadboard isn’t good or if I really ought to be using a socket or what… Gotta find some good solution, because working on this with a flaky connection is gonna suck!
If it happens again it would be interesting to see if any of the PORTB or PORTD pins are toggling; if they are then it’s the AVCC problem. Since it’s intermittent that rules out fuse settings or anything internal to the AVR. Since there are two ground pins (I assume you have them both hooked up) it would take both of them open at the same time to stop things. An intermittent on the reset pin shouldn’t be a problem - that would simply remove your ability to do a reset. I’m guessing the problem is one of the two VCC pins. But that’s just a guess.
