burning the bootloader!

I'm trying to burn the gen7 bootloader to an atmega644, using an arduino as ISP. After many hours of searching and trying, i managed to get a bootloader onto another Arduino, with the programmer attached to the ICSP connector. However, hooking the same setup to my gen7 board, switching board in Arduino IDE and trying to burn the bootloader it says that the device ID is 0x000000. Avrdude from the command line gives the same result, and if i don't set the baud rate manually to 19200 i get a sync error.

It seems that communication is working, but for some reason the device id is not correctly reported. Any clues to why that might happen?

I would check the connection between the ICSP and the atmega, if the wrong signature is being returned than it's likely that communication *isn't* working. The device signature is the first thing sent to the programmer from the chip being programmed, so if it's all zeroes you can't assume that anything's working properly just yet.

Is the ATmega on the Gen7 powered up? You need 5V Standby to get it running (yellow LED lighted).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for the answers! I took the sync errors at baud rates != 19200 as an indication that the wiring is fine...correct? Oh, i forgot to mention i'm running the latest stable Arduino release 1.0.3 on Ubuntu 12.10.

When i connect an ATX power supply, the green on/off led lights up but dies out after a second or two, the yellow standby led lights up and stays on.

That doesn't mean the wiring is fine...it means the programmer thinks it has a connection in some cases and not others, but until you get some kind of meaningful response from the chip you can't assume the connections are fine. The power up sequence you're describing sounds a little suspect, those green LEDs shouldn't come on at all until the PSU is brought out of standby. I'd suggest checking the voltage levels at VCC and GND on the atmega as a start, then verifying that the other signals are getting to the right places. I'm assuming you don't have a scope? That'd make things a lot easier,but you could probably make do with a multimeter if the programmer is clocked low enough. RST will be the easiest, make sure it's pulled low during programming and goes high otherwise. SCK should hover around 2.5 volts during programming, MISO and MOSI should at the very least show some small voltage fluctuations and not just sit at 0 or 5V.

I think at least one of my problems is with the programmer, right now its "not responding" at all (non-reproducible, a few days ago it definitely worked since i managed to burn a bootloader to a blank m328). Guess the best place to get that sorted out is the Arduino forums, so i'll post a thread there. I do have a scope (an old beauty found at a second hand store, it has vacuum tubes in it! ), and the SCK line stays low, should be a square wave i guess.

The circuit passed all tests before i inserted the CPU, but the green power led blinks for a second when i attach an ATX supply, even though it's turned off. You think that indicates another problem or is it no worries?

Edit: i should've mentioned that i've tried programming the CPU both with and without the ATX power attached, with same response from avrdude. However, when the only power was from the Arduino, the green power-led stayed off.

Edited 1 time(s). Last edit at 02/28/2013 01:32PM by nastybyte.

Quote

the green power led blinks for a second when i attach an ATX supply

Happens here, too, from time to time. It takes a moment until the PS_ON pin is pulled high.

Quote

with and without the ATX power attached

You definitely want the CPU to be powered up. Can be measured between pin 19 and 20.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

ATX power is on, the yellow led is on but there is 0 V between pins 19 & 20. Does this indicate a defective chip? Also, is it good or bad to connect the GND and +5V lines on the ICSP when the target board is independently powered?

At least i think my programmer is working correctly, just verified using another arduino.

Quote

the yellow led is on but there is 0 V between pins 19 & 20. Does this indicate a defective chip?

No. The chip isn't responsible for supplying its self. The PSU is.

I was wrong with the pin numbering. The chip is supplied with the two center pins in the lower row, which are number 10 and 11. The pins which are also connected to C14.

Quote

Also, is it good or bad to connect the GND and +5V lines on the ICSP when the target board is independently powered?

A common GND connection is mandatory or your signal voltages float arbitrarily.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Ah, got a little worried there - 10 & 11 are GND & +5V. A common GND is good, i thought as much, but +5V? I think i read somewhere that one should not interconnect different power supplies like that..

I tried connecting the scope to the XTAL pins and had expected to see something wave-like or just two lines if it's too fast, but there's only one line - direct current, no oscillation? Measuring with a voltmeter gives something like 1.4 & 2.6 volts between each XTAL pin and ground. Is this eh..expected behaviour?

The capacitance of the probe can stop the crystal from oscillating unless you have a very high impedence probe, and measuring the crystal pins with a voltmeter definitely won't work. Of course, unless you changed the fuses already, the atmega ships running off the internal oscillator and doesn't use the external crystal at all. Did you verify that all the signals from the programmer are actually getting to the atmega pins? One flaky solder joint is all it takes.

Quote

I think i read somewhere that one should not interconnect different power supplies like that..

That's true. However, my programmer runs off 5V from USB but doesn't forward this to the serial line side. It requires an additional 5V supply from the ICSP connector.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I've checked the resistance between each ICSP terminal and the respective pin on the atmega, each is <1 ohm. I also looked at what happened on the pins when running avrdude with the scope:

!RESET: high, goes low for a noticeable period when avrdude is executed.
SCK: low, but i can see some signal blinking shortly after avrdude is executed.
MISO/MOSI: i think i saw something flashing here too, but it was very fast.

I tried some different baud rates, both with and without the -B 5 option, and all gives the "not in sync" error except 19200 baud which gives the device id 0x000000.

What would you do in my situation, order another atmega, buy or build another programmer, or is there anything else you can think of that i can do to narrow the problem down? This is the only thing that is keeping me from finishing my reprap, and i'm thinking it would be nice to be able to start printing parts for another one.

Your signals are pretty much like expected. Reset acts as a chip select pin while programming.

As a scope owner you're apparently a bit more into electronics than average, so a dedicated ICSP programmer would be a worthwhile investment. A Pololu PGM03A serves me well for several hundred uploads onto almost as many ATmegas now and can do standard serial comminucations, too (you can swap between programming and and communicating without swapping any connectors).

Another option would be to get a preprogrammed ATmega. Bootloaders are usually programmed once in a lifetime, only. Make sure you get one for the right frequency (16 vs. 20 MHz). Sanguinololu and Gen7 shops should have them.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Yeah, what he said...it's probably a good idea to get a proper programmer, they're only a few bucks on ebay. I'm not familiar with how the arduino based programmer interfaces with avrdude and I don't believe it even respects the -B 5 parameter, but I do know a real programmer won't return a device signature of 0x000000...it'll say there was a connection error.

If you want to keep hacking at it in the meantime, maybe setup a breadboard with just the atmega hooked up to the programmer and 5V, as in http://arduino.cc/en/Tutorial/ArduinoISP, and see if you can get it to play nice? Other than that, one of the most common problems with a new chip is that it's not running fast enough to communicate with the default programmer settings, which -B 5 should alleviate in avrdude. Or even go all out and try -B 100 or something crazy (if -B works at all with your sketch) *shrug*

OK, sounds and seems the ArduinoISP programmer doesen't work very well! I finally managed to burn the bootloader using a parallel programmer and a really old computer with a real honest to god parallel port. Programming on the gen7 board did not work (timeout like no connection) but when i had it on a breadboard with a 4 MHz crystal i found, avrdude was finally happy.

Now i'm trying to do a serial connection to the atmega. I have a USB to TTL converter i got with the gen7 kit from e-motion tech, i connect the GND, RxD TxD pins to the respective pins on the gen7 serial header, connect ATX power, start Arduino GUI as root, select serial port+board and try to upload the test sketch (not forgetting to press reset just before compiling is done) but "programmer is not responding". I'm not even using a programmer anymore, this is just a serial connection?

Also tried writing the test sketch with Arduino IDE:s "upload using programmer" option from the old computer with the parallel port just as i managed to burn the bootloader, but for some reason avrdude gets the wrong device id again when it's used by the GUI. Works fine from command line, though.

So, it seems the atmega is working after all, but something's not right with my board. USB-to-TTL converter seems ok too, gives echo on serial monitor with TxD & RxD bridged. Is there a way to check if the crystal is working? Is there any point at all in trying changing the 20 MHz crystal (the part i guess is most likely broken - comments appreciated!) for the 4 MHz one?

Well, maybe this is a stupid question, but did you remember to set the fuses with avrdude? If you didn't, the atmega is still clocked at 1mhz using the internal oscillator and wouldn't work at the expected bitrate with the serial connector. I doubt the 20mhz crystal was the problem initially, cause it wouldn't have even been in use unless you managed to program the fuses before your original problems started.

Only other easily made mistake I can think of is the Rx and Tx pins...you connected Rx to Tx and Tx to Rx, right? Cause connecting it "to the respective pins" makes me wonder

Edited 2 time(s). Last edit at 03/07/2013 08:27PM by Rezer.

Quote

Is there a way to check if the crystal is working?

Yes. Upload a firmware (doesn't matter by which means) which does something visible, like blinking a LED and/or turning on the power supply. SetupTest.ino does this, Arduino IDE saves the .hex file in a buildxxxxx directory inside /tmp when clicking "Verify" in the GUI.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Yeah, i guess that would be very useful to try to find out what's wrong with the board. Just tried writing that .hex file to the chip, avrdude reports no problems but after a reset the chip give no signs of life, neither on the breadboard with 4 MHz crystal nor on the gen7 board. The .hex file should be written to flash (avrdude -U flash:w:whatever.hex), right? I guess that overwrites the bootloader? Is it possible that for some reason the 4 MHz crystal works for programming, but not when the chip is running "on its own"?

One thing, in the sketch it says it will blink the heater led, which is pin #5 on the atmega, but then the HEATER_Pin is assigned a value of 3. Does this reference to a pin number on an (imaginary) arduino board or something, not the bare atmega chip? None of the pins give any output signals, so maybe this is not so important...

Rezer: i set the fuses with the command in the instructions, avrdude reported no problems. And no, i haven't confused Rx/Tx, tried both just to be sure.

Alright, thought it was worth asking. As for the latest problem, if you burned the hex file directly I believe you have to disable the boot reset vector fuse for it to work properly. If that fuse is set it tries to load the bootloader first from 0x7C00, and writing the hex file would have killed the bootloader meaning there's nothing at that memory location. So maybe try changing hfuse from 0xDC to 0xDD... I'm not 100% on whether this is necessary, but it won't hurt anything as long as you set hfuse back when burning the bootloader back on.

Oh, and yes, the pins refer to the "digital pins" on an arduino board, not actual pins on the atmega. You can download an arduino schematic and verify that digital pin 3 on their header routes to pin 5 on the atmega.

Edited 2 time(s). Last edit at 03/08/2013 01:40PM by Rezer.

It's blinking!!!

It must be the clock crystal that's broken - i de-soldered it and replacing with the 4 MHz one, and it works! I also get data on the serial, no readable text but i guess that is to be expected with the wrong clock frequency.

Thank you so much for all the help!! I hope i'll be able to help someone in return!

Hey that's a start...did you match the load capacitors to the crystal, or just use what was specified by the board? As long as you have it out, it might be worth a shot to try some different values on a breadboard to get that thing oscillating.

To be honest, i don't have a clue how to calculate a good value for those capacitors, just plugged it in and it happened to work (i guess that consumed a good deal of luck, hopefully well used). Bought a new 20 MHz crystal and now i can upload firmware from Arduino IDE, and even connect with pronterface. Whee!

For the record, i also had to replace a coil with a plain wire to get the board to work more than very erratically - google and you will find.

Older Gen7 designs had a 100 uH coil, which is too big. 10 uH is better than 100 uH and also better than a plain wire.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY