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.
Wednesday, January 18, 2012
Tuesday, January 17, 2012
Parallax 7345 RV Power Converter (SMPS)
See Also:
Parallax 7345 Repair Tips
A friend had a Parrallax 7345 power converter for a RV that didn't work. We know what happened, It's designed for 120VAC only and somehow got hooked up to 240VAC. So it released some of it's magic smoke. (and probably made a big BANG noise I imagine)
Basic Info:
It was pretty easy to locate the fault, as there was black stuff all over one spot. (Note: I'd already removed the heatsink from the bridge rectifier in the first picture and cleaned to bottom a bit when I took the second picture)
I looked it over good. It seems a MOV (metal oxide varistor) is missing (vaporized in fact), but that wouldn't prevent it from working, it just shorts the ac line together when they reach a certain voltage, with it gone it should power up, unless something else is broken. Sure enough the line filter next to it had melted a wire clean off, I didn't see it at first because the MOV had left a bunch of residue that hid it.
The other black spot on the circuit board (far left) is under the output resistors, they work fine, but must run a bit hot under prolonged load.
I bridged the broken wire on the filter, sheilded my face and plugged it in. It powered up nicely, made a moderately loud buzzing noise (no load), so I unplugged it and connected it to a 12V battery. Absolutely quiet now, but putting an amp or so into my battery. The battery is connected to an inverter I use for emergency power, so I plugged a toaster in and it jumped right to 45A. I ran a couple toaster cycles then let it fully charge my battery and all seems well.
The Repair:
I couldn't find an exact replacement for the filter, so I had to make a few mods to the board for the one I found. I had to guess on the MOV, I used a 175V MOV (datasheet said 150VAC max) I still have no idea what size would have been right, I even spent a couple hours trying to find how to choose the voltage and still didn't come up with an answer.
But a new MOV and line filter later it's back in service. The good news it the MOV did it's job, protecting all the electronics after it, it should have had a fuse in the AC line and the MOV and line filter may have survived. There was some minor damage to the traces around the line filter and MOV, but nothing too bad. The owner was instructed "Don't hook it to 240 again!", but I think he already knew that.
The other side of the board, nothing wrong here, just in case you want to see it:
Parallax 7345 Repair Tips
A friend had a Parrallax 7345 power converter for a RV that didn't work. We know what happened, It's designed for 120VAC only and somehow got hooked up to 240VAC. So it released some of it's magic smoke. (and probably made a big BANG noise I imagine)
Basic Info:
- The big heatsinks may have 300VDC+- on them, Be careful! (obviously if it's on the heatsinks, it could be anywhere, like those 2 big caps) It doesn't just go away if it's not plugged it either.
- 45A@13.8VDC (7300 series 45A)
- 120VAC input
- Despite the fancy "converter" name it's just a big Switch Mode Power Supply (SMPS)
- Schematics are not available (Parrallax has on their page "We do not give schematics to anyone perod", or something to that effect), as with most things in the RV universe, they are expensive to replace and don't expect any help repairing them.
It was pretty easy to locate the fault, as there was black stuff all over one spot. (Note: I'd already removed the heatsink from the bridge rectifier in the first picture and cleaned to bottom a bit when I took the second picture)
I looked it over good. It seems a MOV (metal oxide varistor) is missing (vaporized in fact), but that wouldn't prevent it from working, it just shorts the ac line together when they reach a certain voltage, with it gone it should power up, unless something else is broken. Sure enough the line filter next to it had melted a wire clean off, I didn't see it at first because the MOV had left a bunch of residue that hid it.
The other black spot on the circuit board (far left) is under the output resistors, they work fine, but must run a bit hot under prolonged load.
I couldn't find an exact replacement for the filter, so I had to make a few mods to the board for the one I found. I had to guess on the MOV, I used a 175V MOV (datasheet said 150VAC max) I still have no idea what size would have been right, I even spent a couple hours trying to find how to choose the voltage and still didn't come up with an answer.
But a new MOV and line filter later it's back in service. The good news it the MOV did it's job, protecting all the electronics after it, it should have had a fuse in the AC line and the MOV and line filter may have survived. There was some minor damage to the traces around the line filter and MOV, but nothing too bad. The owner was instructed "Don't hook it to 240 again!", but I think he already knew that.
The other side of the board, nothing wrong here, just in case you want to see it:
Update:
I picked up a broken 55A version of this unit. As far as I can tell it's exactly the same board. I'm going to do a post and probably a video of diagnosing and repairing it, but that may be a while.
I was going to post the correct value of the MOV, but it doesn't have one. The MOV footprint is not populated. I have the numbers off the filter, but google hasn't helped my find anything about it, so it may be a wild goose chase. In case it helps someone:
Filter:
06847475-000 843TC6
AXM EIA-17-0315-1A
Labels:
7345,
broken,
Converter,
Diagnosis,
Electronics,
fix,
Magic Somke,
MOV,
Parrallax,
repair,
RV,
SMPS
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
Monday, December 26, 2011
Laptop on a wall
What do you do when you get a laptop with a broken screen? I priced a screen and it cost half a new laptop.
I've been using my laptop as a desktop for several years now and the biggest problem I've run into is the amount of space it takes up on my desk. I could shove it in a drawer or something, but then I can't turn it on...
A while back my father broke the screen on his laptop, after pricing a new screen he bought a new laptop, and the old one was buried in a closet. I've been pondering what to do with it ever since, it seemed a waste to just throw it out.
I finally decided to mod the power switch so it would be outside the case, then I could shove it somewhere and still turn it on and off, unfortunately it won't power on when the lid is closed.
I've always liked "naked" electronics. All the components, right there for anyone to see, no silly plastic designed to look good, covering up an amazing array of traces, chips, caps, etc. So I tore it down, mounted it to the wall and hooked it up. I'm thinking about a plexiglass cover and some sort of frame to hide the wires eventually. I think it's cool, and I now have half my desk back.
I've been using my laptop as a desktop for several years now and the biggest problem I've run into is the amount of space it takes up on my desk. I could shove it in a drawer or something, but then I can't turn it on...
A while back my father broke the screen on his laptop, after pricing a new screen he bought a new laptop, and the old one was buried in a closet. I've been pondering what to do with it ever since, it seemed a waste to just throw it out.
I finally decided to mod the power switch so it would be outside the case, then I could shove it somewhere and still turn it on and off, unfortunately it won't power on when the lid is closed.
I've always liked "naked" electronics. All the components, right there for anyone to see, no silly plastic designed to look good, covering up an amazing array of traces, chips, caps, etc. So I tore it down, mounted it to the wall and hooked it up. I'm thinking about a plexiglass cover and some sort of frame to hide the wires eventually. I think it's cool, and I now have half my desk back.
RobertShaw HV SP715A furnace ignition module
House call today, a furnace wasn't heating, seems this usually happens on a bitter cold weekend, that's a holiday, and usually after any store that might have be open earlier is closed. Today's wasn't quite that bad, but I have to say it. Anyway, here's the run down from the phone conversation:
Sorry about the quality, cell phone in basement, at least I took a picture of it.
The Robertshaw sp715a control box:
You can't really see them in the picture, but 2 of the solder joints on the big black relay that controls the main burner were cracked. I had to run to a store to buy a soldering iron (a $6 firestarter), but it was quicker than driving home to solder them. I resoldered and reassembled the furnace. They've got heat and didn't have to buy a $100 module (or wait in a cold house until I could get one either).
Steve
- Pilot was lit
- Thermostat was calling for heat
- Breakers were on
- Main burner wasn't coming on
Sorry about the quality, cell phone in basement, at least I took a picture of it.
The Robertshaw sp715a control box:
- Turns on the pilot gas
- Jumps a spark until it senses a flame
- Turns on the main burner
You can't really see them in the picture, but 2 of the solder joints on the big black relay that controls the main burner were cracked. I had to run to a store to buy a soldering iron (a $6 firestarter), but it was quicker than driving home to solder them. I resoldered and reassembled the furnace. They've got heat and didn't have to buy a $100 module (or wait in a cold house until I could get one either).
Steve
UPDATE: A Few Links
Labels:
broken,
Electronics,
fix,
furnace,
main burner,
no heat,
pilot,
repair,
Robertshaw,
solder,
sp715a
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)


