I've been trying my hand at etching pcb's lately. As a result I needed to burn a bootloader on a Atmega 328 and I didn't put a ISP header on my target board. I really need to get in the habit of doing that. Usually I just stick it in my dragon, connect it up with a bunch of jumpers and burn it.
A while back I saw someone had made a whole set of boards for this purpose. You just plugged in the board and never get a wire crossed again! I made a brief search for them but couldn't find anything useful (schematic, pcb layouts, etc). So I made my own. So far I have made the ISP for the 168/328. Sometime I will make the HVPP for these and both for the 644/1284.
You may notice that I have a mix of male and female headers. When I got my dragon I put mostly female headers on (excluding JTAG and ISP) so I could use normal jumpers rather than special female ones. I still think it was a good idea, but most people use all male headers, so the board could use all females.
I only put the used headers for ease of use and cost control. For soldering I put all the headers in place on the dragon then added the board. It keeps everything perfectly aligned.
Etch-resist was a laser printer transfer, cupric chloride etch solution. I'll do a post on that whole process later.
I intended to attach the KiCAD Schematic and PCB file here, but I can't see how to do that (might not be possible), so I posted it over on TryThisTv.com
Showing posts with label bootloader. Show all posts
Showing posts with label bootloader. Show all posts
Tuesday, October 16, 2012
Wednesday, January 18, 2012
Fixed a dead 1284p
The Problem:
Through the 1284p saga I ended up with a 1284p that I couldn't burn the bootloader to. It was working (sprinter running, random serial errors and restarts though) then the next day it quit. Later, when I tried to burn the correct fuse bit and bootloader I received a Device Signature = 0x000000.
Unless something had corrupted it, it had the Ext Crystal Osc. setting. I figured the fuse problem out after this chip died. I came to the conclusion that either something was messed up with the fuses or the micro was completely dead. I wanted to build a Fusebit Doctor, but didn't have the time to start another project at this point, so I bought a 644p and shelved the 1284p.
The Solution, or "I Had a Lucky Break!":
I kept thinking about the dead micro, it was really bugging me. Finally I decided to try it with a crystal oscillator instead of the resonator to see if that was it. I found a 16mhz crystal in my spare parts box and replaced the resonator on my breadboard with it, couldn't find 22pf caps, and the caps I found didn't work with it.
I still managed to burned a bootloader on it with just a 16mhz crystal, no caps. Now it seems fine again with the resonator and the new fuse settings, go figure.
Through the 1284p saga I ended up with a 1284p that I couldn't burn the bootloader to. It was working (sprinter running, random serial errors and restarts though) then the next day it quit. Later, when I tried to burn the correct fuse bit and bootloader I received a Device Signature = 0x000000.
Unless something had corrupted it, it had the Ext Crystal Osc. setting. I figured the fuse problem out after this chip died. I came to the conclusion that either something was messed up with the fuses or the micro was completely dead. I wanted to build a Fusebit Doctor, but didn't have the time to start another project at this point, so I bought a 644p and shelved the 1284p.
The Solution, or "I Had a Lucky Break!":
I kept thinking about the dead micro, it was really bugging me. Finally I decided to try it with a crystal oscillator instead of the resonator to see if that was it. I found a 16mhz crystal in my spare parts box and replaced the resonator on my breadboard with it, couldn't find 22pf caps, and the caps I found didn't work with it.
I still managed to burned a bootloader on it with just a 16mhz crystal, no caps. Now it seems fine again with the resonator and the new fuse settings, go figure.
Monday, January 16, 2012
ArduinoISP
If you read Part 2 of my Sanguinololu Build you saw my arduino ISP (in Circuit Programmer) built on a breadboard to burn bootloaders my 1284p's. It worked really good, but I had to be really careful not to bump any wires loose or pull them out accidentally.
Some day I may buy a proper ISP, but until then it would be nice to have something that would work on the rather rare occasion I actually need one. So I decided to make something more permanent but not require a dedicated Arduino either.
The Project:
- Connect an Arduino to any 6 pin AVRISP header
- Include status LED's
- Be completely removable (mounted on headers)
Seems to work so far, Tried it on my other arduino, not really extensive testing, but seems to work.I'd like to make a couple pcb's for various chips with the 6 pin ISP header on them, but that's all for now.
UPDATE:
Just built a second one, decided to move the ground from the power side to the io pin side, that allows selection of 5v or 3.3v on the VCC wire. or you can leave it disconnected if your target is self powered.
Labels:
arduino,
ArduinoISP,
atmega,
bootloader,
Dead Bug,
Electronics,
ISP
Tuesday, December 27, 2011
Sanguinololu 1.3a - Part 3:Not Out of The Woods Yet
See Also:
Part 1 - Build
Part 2 - Trouble in Paradise
After the events of the last 2 parts I thought the Sanguinololu was finally working properly. But that would have been too easy, right? (I wouldn't have called it easy.) Of course not, something's still not right. Now I could upload and download firmware fine, and they seem to work. Except...
I used http://www.engbedded.com/fusecalc/ to calculate new fuse settings
I burned Mighty 1284p bootloader with new fuse settings (changed in boards.txt):
Low 0xD6
High 0xDC
Ext 0xFD
I ran the controller connected to usb (no motors or external power) for over 3500 lines of g-code without error. Previously it would error some where between when it connected (before the build even started) and definitely before 200 lines of g-code.
I hooked up my motors and ran another build. I haven't built a frame yet, I've got other projects to finish first, but it ran the motors for a full build (11222 lines, the sample build-benchmart.stl), so we'll call it good for now.
From what I have been able to find the fuse settings for the Sanguino and Mighty 1284p are just plain wrong for the Sanguinololu. They are for a external crystal oscillator. Apparently the full sweep oscillator setting is required for a resonator. The above settings seem very stable so far.
UPDTATE: I just got a 644p to play with, I haven't had a lot of time for testing yet, but it seems stable on both the default settings (ext crystal osc) and my modified fuse settings. I think almost everyone uses the 644p and this may be the reason I haven't found anyone else with this problem. I'm inclined to believe that my setting (full swing osc - ceramic resonator) is correct for both micros, but the 644p doesn't mind the wrong setting nearly as much as the 1284p. I've still got more tests to run on it, so I'll update as I go.
Part 1 - Build
Part 2 - Trouble in Paradise
After the events of the last 2 parts I thought the Sanguinololu was finally working properly. But that would have been too easy, right? (I wouldn't have called it easy.) Of course not, something's still not right. Now I could upload and download firmware fine, and they seem to work. Except...
- Both boards seem to reset or reboot at random.
- One board gets a lot of serial errors, I resoldered the FTDI chip several times. I'm convinced my soldering is OK.
- I noticed that touching my scope's 10x probe to the resonator pins produced serial errors and seemed to crash the 1284p some times
I used http://www.engbedded.com/fusecalc/ to calculate new fuse settings
I burned Mighty 1284p bootloader with new fuse settings (changed in boards.txt):
Low 0xD6
High 0xDC
Ext 0xFD
I ran the controller connected to usb (no motors or external power) for over 3500 lines of g-code without error. Previously it would error some where between when it connected (before the build even started) and definitely before 200 lines of g-code.
I hooked up my motors and ran another build. I haven't built a frame yet, I've got other projects to finish first, but it ran the motors for a full build (11222 lines, the sample build-benchmart.stl), so we'll call it good for now.
UPDTATE: I just got a 644p to play with, I haven't had a lot of time for testing yet, but it seems stable on both the default settings (ext crystal osc) and my modified fuse settings. I think almost everyone uses the 644p and this may be the reason I haven't found anyone else with this problem. I'm inclined to believe that my setting (full swing osc - ceramic resonator) is correct for both micros, but the 644p doesn't mind the wrong setting nearly as much as the 1284p. I've still got more tests to run on it, so I'll update as I go.
Labels:
1.3a,
1284p,
644p,
atmega,
bootloader,
checksum mismatch,
crash,
Electronics,
error,
fix,
ftdi,
fuse,
Mighty 1284p,
Reprap,
Sanguinololu,
serial
Wednesday, December 14, 2011
Sanguinololu 1.3a - Part 2: Trouble in Paradise
See Also:
Part 1 - Build
Part 3 - Not Out of the Woods Yet
Part 2 of my RepRap build. As noted in part 1 I had some trouble right off the bat.
NOTE: Part 3 include additional information concerning the bootloader and fuse settings. I highly recommend you read it before burning your bootloader
FTDI
According to the Sanguinololu wiki page, you should test the FTDI chip after installing the USB port and related components. all you have to do is:
1. Plug the board into your computer.
2. Install the driver software.
3. Connect to the COM port with something like Putty
4. Short the RX0 and TX0 pins together (use a piece of wire or something, it needs to work for about 1 second, don't worry about soldering it or anything.)
5. Type stuff on your keyboard, it should show up when the pins are shorted, and stop when disconnected.
6. If this worked your FTDI chip is operating properly.
UPDATE: The "arduino.h" error can be corrected by creating "INSTALL_LOCATION/Arduino-1.0/hardware/Sanguino/cores/arduino/Arduino.h" and putting "<#include WProgram.h>"
I reburned the bootloader with the 8mhz and 16mhz options (the 644p option errored as not the right chip, so the arduino isp was communicating), neither worked, I changed the
"atmega1284.build.f_cpu=16000000L" to "atmega1284.build.f_cpu=8000000L" (as it was
originally), commented the last 3 lines out (as they were originally), nothing worked.
Finally, when I was thinking I had bricked the chip I found a different bootloader for the 1284, the Mighty 1284p. I burned the bootloader, popped the chip back in the Sanguinololu, and uploaded the blink code. It Worked! I had a square wave on the scope and everything!
Unfortunately Mighty 1284p is only compatible with arduino 1.0. Using the Sanguino 1284p 16mhz setting in 0018 couldn't upload sprinter. I changed the settings in the Sanguinololu boards.txt to match the Mighty 1284p and Sprinter uploaded fine.
I don't know if the Sanguino bootloader would have worked with 0023, I'm assuming it's something with my setup. The 644p is compatible with 0018, as is Sprinter, if I had known the trouble it would be to get Sprinter on the 1284p I'd have bought 644p's. But it's done, and I'm happy.
Steve
UPDATE
I decided I hadn't given the Sanguino bootloader a fair chance, it was for 0023 and I didn't use that.
I downloaded Arduino 0023, decompressed the Sanguino files into the hardware directory. Same thing, had to do both of the above hacks to get it to write the bootloader, which it again completed successfully. Exactly the same problem too, unable to upload Sprinter (or blink) to it.
I put the Mighty 1284p bootloader back on and uploaded Sprinter fine. Is something different about my chips? My ISP? Who knows? I sure don't.
Steve
Part 1 - Build
Part 3 - Not Out of the Woods Yet
Part 2 of my RepRap build. As noted in part 1 I had some trouble right off the bat.
NOTE: Part 3 include additional information concerning the bootloader and fuse settings. I highly recommend you read it before burning your bootloader
FTDI
According to the Sanguinololu wiki page, you should test the FTDI chip after installing the USB port and related components. all you have to do is:
1. Plug the board into your computer.
2. Install the driver software.
3. Connect to the COM port with something like Putty
4. Short the RX0 and TX0 pins together (use a piece of wire or something, it needs to work for about 1 second, don't worry about soldering it or anything.)
5. Type stuff on your keyboard, it should show up when the pins are shorted, and stop when disconnected.
6. If this worked your FTDI chip is operating properly.
Of course this did not happen for me. The first board my brain wasn't fully engaged and I forgot to add flux, then tried to solder it with an iron, even though I had a hot air reflow station just sitting there. Stupid! I managed to bend a couple pins slightly up, just enough that they wouldn't connect.
So after a half hour of fixing it all looked good, but the computer didn't recognize anything attached. I went over the pins one at a time with a soldering iron with a really fine tip, just putting a little down pressure on each one. Now the computer recognized it, loaded up putty and the loopback worked fine.
The second board I did with the hot air and a good dose of flux. It looked beautiful compared to my first attempt, like a factory placed chip. It was immediately recognized by the computer, but the loopback didn't work. I took it off, ran a blob of solder across the pads to wet them, removed the excess, and replaced the chip on the board. Then it worked fine.
Bootloader
The wiki said the ATMEGA1284p was a drop in replacement for the 644p. I checked the specs, for a dollar or so more I'd go for the 1284p. Now, I'm not quite sure what they mean by "drop in compatible", it does indeed fit in the slot and it does indeed work with the board. After 5 hours of hacking. The first problem was the bootloader. I downloaded the 0023 version from here (the options were 0018, which doesn't support the 1284p and 0023 which does). I had arduino version 0022 and that didn't work. I downloaded 1.0, that seemed to. I burned the bootloader with the Arduino ISP as noted in the wiki. At some point I changed the last 3 line of hardware / Sanguino / boards.txt to:
atmega1284.build.mcu=atmega1284p
atmega1284.build.f_cpu=16000000L
atmega1284.build.core=arduino
It seemed to burn fine, no errors.
Using an Arduino to Flash the bootloader onto a 1284p
I put the chip in the Sanguinololu plugged it in and loaded the Sprinter firmware into arduino 1.0 (despite it claiming to not work with 1.0) Surprise! it errored out on the compile, couldn't find "arduino.h". Also wouldn't compile with 0022 (don't remember the exact error), but claimed to be compatible with 0018, so I downloaded that.
UPDATE: The "arduino.h" error can be corrected by creating "INSTALL_LOCATION/Arduino-1.0/hardware/Sanguino/cores/arduino/Arduino.h" and putting "<#include WProgram.h>" in it. I didn't figure this out, but I lost the reference. (Semi off-topic note: replace " Sanguino" with " Arduino" for other boards - uno, duemilanove, etc.)
It compiled fine with 0018, I copied the Sanguino files from the hardware folder of 1.0 over and tryed to upload it to the board. Nope, 0018 has no idea what a 1284p is. I finally managed to get the following fron 1.0's hardware/tools/avr/etc/avrdude.conf:
It goes right above:
#------------------------------------------------------------
# ATmega1284P
#------------------------------------------------------------
# similar to ATmega164p
part
id = "m1284p";
desc = "ATMEGA1284P";
has_jtag = yes;
stk500_devcode = 0x82; # no STK500v1 support, use the ATmega16 one
avr910_devcode = 0x74;
signature = 0x1e 0x97 0x05;
pagel = 0xd7;
bs2 = 0xa0;
chip_erase_delay = 9000;
pgm_enable = "1 0 1 0 1 1 0 0 0 1 0 1 0 0 1 1",
"x x x x x x x x x x x x x x x x";
chip_erase = "1 0 1 0 1 1 0 0 1 0 0 x x x x x",
"x x x x x x x x x x x x x x x x";
timeout = 200;
stabdelay = 100;
cmdexedelay = 25;
synchloops = 32;
bytedelay = 0;
pollindex = 3;
pollvalue = 0x53;
predelay = 1;
postdelay = 1;
pollmethod = 1;
pp_controlstack =
0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F,
0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F,
0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B,
0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02;
hventerstabdelay = 100;
progmodedelay = 0;
latchcycles = 6;
togglevtg = 1;
poweroffdelay = 15;
resetdelayms = 1;
resetdelayus = 0;
hvleavestabdelay = 15;
chiperasepulsewidth = 0;
chiperasepolltimeout = 10;
programfusepulsewidth = 0;
programfusepolltimeout = 5;
programlockpulsewidth = 0;
programlockpolltimeout = 5;
idr = 0x31;
spmcr = 0x57;
allowfullpagebitstream = no;
memory "eeprom"
paged = no; /* leave this "no" */
page_size = 8; /* for parallel programming */
size = 4096;
min_write_delay = 9000;
max_write_delay = 9000;
readback_p1 = 0xff;
readback_p2 = 0xff;
read = " 1 0 1 0 0 0 0 0",
" 0 0 x x a11 a10 a9 a8",
" a7 a6 a5 a4 a3 a2 a1 a0",
" o o o o o o o o";
write = " 1 1 0 0 0 0 0 0",
" 0 0 x x a11 a10 a9 a8",
" a7 a6 a5 a4 a3 a2 a1 a0",
" i i i i i i i i";
loadpage_lo = " 1 1 0 0 0 0 0 1",
" 0 0 0 0 0 0 0 0",
" 0 0 0 0 0 a2 a1 a0",
" i i i i i i i i";
writepage = " 1 1 0 0 0 0 1 0",
" 0 0 x x a11 a10 a9 a8",
" a7 a6 a5 a4 a3 0 0 0",
" x x x x x x x x";
mode = 0x41;
delay = 10;
blocksize = 128;
readsize = 256;
;
memory "flash"
paged = yes;
size = 131072;
page_size = 256;
num_pages = 512;
min_write_delay = 4500;
max_write_delay = 4500;
readback_p1 = 0xff;
readback_p2 = 0xff;
read_lo = " 0 0 1 0 0 0 0 0",
"a15 a14 a13 a12 a11 a10 a9 a8",
" a7 a6 a5 a4 a3 a2 a1 a0",
" o o o o o o o o";
read_hi = " 0 0 1 0 1 0 0 0",
"a15 a14 a13 a12 a11 a10 a9 a8",
" a7 a6 a5 a4 a3 a2 a1 a0",
" o o o o o o o o";
loadpage_lo = " 0 1 0 0 0 0 0 0",
" 0 0 x x x x x x",
" x a6 a5 a4 a3 a2 a1 a0",
" i i i i i i i i";
loadpage_hi = " 0 1 0 0 1 0 0 0",
" 0 0 x x x x x x",
" x a6 a5 a4 a3 a2 a1 a0",
" i i i i i i i i";
writepage = " 0 1 0 0 1 1 0 0",
"a15 a14 a13 a12 a11 a10 a9 a8",
" a7 x x x x x x x",
" x x x x x x x x";
mode = 0x41;
delay = 10;
blocksize = 256;
readsize = 256;
;
memory "lock"
size = 1;
read = "0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0",
"x x x x x x x x x x o o o o o o";
write = "1 0 1 0 1 1 0 0 1 1 1 x x x x x",
"x x x x x x x x 1 1 i i i i i i";
min_write_delay = 9000;
max_write_delay = 9000;
;
memory "lfuse"
size = 1;
read = "0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0",
"x x x x x x x x o o o o o o o o";
write = "1 0 1 0 1 1 0 0 1 0 1 0 0 0 0 0",
"x x x x x x x x i i i i i i i i";
min_write_delay = 9000;
max_write_delay = 9000;
;
memory "hfuse"
size = 1;
read = "0 1 0 1 1 0 0 0 0 0 0 0 1 0 0 0",
"x x x x x x x x o o o o o o o o";
write = "1 0 1 0 1 1 0 0 1 0 1 0 1 0 0 0",
"x x x x x x x x i i i i i i i i";
min_write_delay = 9000;
max_write_delay = 9000;
;
memory "efuse"
size = 1;
read = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0",
"x x x x x x x x o o o o o o o o";
write = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0",
"x x x x x x x x 1 1 1 1 1 i i i";
min_write_delay = 9000;
max_write_delay = 9000;
;
memory "signature"
size = 3;
read = "0 0 1 1 0 0 0 0 x x x x x x x x",
"x x x x x x a1 a0 o o o o o o o o";
;
memory "calibration"
size = 1;
read = "0 0 1 1 1 0 0 0 0 0 0 x x x x x",
"0 0 0 0 0 0 0 0 o o o o o o o o";
;
;
#------------------------------------------------------------Now I get a
# ATmega162
#------------------------------------------------------------
avrdude: stk500_getsync(): not in sync: resp=0x00 avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51Which basically means "something is wrong". It can't connect to the chip at all. I fought with this for a while, and it just wouldn't connect. Even 1.0 refused, not even the "blink" sample code.
I reburned the bootloader with the 8mhz and 16mhz options (the 644p option errored as not the right chip, so the arduino isp was communicating), neither worked, I changed the
"atmega1284.build.f_cpu=16000000L" to "atmega1284.build.f_cpu=8000000L" (as it was
originally), commented the last 3 lines out (as they were originally), nothing worked.
Finally, when I was thinking I had bricked the chip I found a different bootloader for the 1284, the Mighty 1284p. I burned the bootloader, popped the chip back in the Sanguinololu, and uploaded the blink code. It Worked! I had a square wave on the scope and everything!
Unfortunately Mighty 1284p is only compatible with arduino 1.0. Using the Sanguino 1284p 16mhz setting in 0018 couldn't upload sprinter. I changed the settings in the Sanguinololu boards.txt to match the Mighty 1284p and Sprinter uploaded fine.
I don't know if the Sanguino bootloader would have worked with 0023, I'm assuming it's something with my setup. The 644p is compatible with 0018, as is Sprinter, if I had known the trouble it would be to get Sprinter on the 1284p I'd have bought 644p's. But it's done, and I'm happy.
Steve
UPDATE
I decided I hadn't given the Sanguino bootloader a fair chance, it was for 0023 and I didn't use that.
I downloaded Arduino 0023, decompressed the Sanguino files into the hardware directory. Same thing, had to do both of the above hacks to get it to write the bootloader, which it again completed successfully. Exactly the same problem too, unable to upload Sprinter (or blink) to it.
I put the Mighty 1284p bootloader back on and uploaded Sprinter fine. Is something different about my chips? My ISP? Who knows? I sure don't.
Steve
Labels:
1.3a,
1284p,
arduino,
atmega1284p,
bootloader,
error,
ftdi,
Mighty 1284p,
Reprap,
resp=0x00,
Sanguinololu,
Sprinter
Subscribe to:
Posts (Atom)