Do you have an other programmer ?
If you use a cheap USBasp programmer, you need a cable from 10-pin to 6-pin.

What if you try to let Arduino to programma the bootloader again, this will also set the fuses.

But in the end, it is probably broken....

I don't have another programmer, but the one I have is working just great with other chips and boards I have. I have asked Arduino and avr-dude personally to try again, and it fails always on fuse verification, just like AVRStudio. I've also tried AVRStudio 4 as well.

Have you tried a "chip erase"?
Have you inadvertently set lock-bit LB2?

I have tried "chip erase", several times. I've also double checked the lock bits, they are all three set to "unlock" according to AVR Studio.

I'm guessing I did something to fry the '328. I'll just order up a new one and go from there.

[[UPDATE]]

Krodal,

Thanks for the response.

I'll try pulling and reseating the chip tomorrow…I do have the version with the DIP package, so that's possible. Sadly, I don't have a spare chip to pop in there to verify that it's not some other bit of hardware. I can try touching up the joints on the caps just to be sure.

Don

[UPDATE] Tried reseating the chip, no love

Hello all,

I had wanted to repurpose my Arduino Uno for another project using Atmel Studio 6 beta. However, I'm running into some problems. I was able to write the fuse bits once with my AVR ISP mkII, but now cannot change them further. No, I didn't disable the SPI fuse, and the lock bits are all set to NO_LOCK. I also can't upload any firmware. I've tried writing the fuses with AVR Studio 6, and using the Arduino IDE bootloader burner, no luck. I can read and verify the various memories, settings, fuses, and whatnot just fine.

FWIW, the fuses are stuck at:
Extended: 0xFF
High: 0xDF
Low: 0xFF

Any idea what might be going on, and how I might unbrick my Arduino Uno?

As the subject-line says, I can't compile sketches using the Ethernet library in Arduino 1.0 for a custom board, whose hardware definition is in ~/Documents/Arduino/hardware/OpenLCB
I get the following errors:

Code:

/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=at90can128 -DF_CPU=16000000L -DARDUINO=100 -I/Users/dgoodman/Documents/Arduino/hardware/OpenLCB/cores/OpenLCB -I/Users/dgoodman/Documents/Arduino/hardware/OpenLCB/variants/OpenLCB -I/Applications/Arduino.app/Contents/Resources/Java/libraries/SPI -I/Applications/Arduino.app/Contents/Resources/Java/libraries/Ethernet /var/folders/+Z/+ZVggXdSHbW9VypYQpUaIE+++TI/-Tmp-/build1183822088658838250.tmp/WebServer.cpp -o/var/folders/+Z/+ZVggXdSHbW9VypYQpUaIE+++TI/-Tmp-/build1183822088658838250.tmp/WebServer.cpp.o
/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=at90can128 -DF_CPU=16000000L -DARDUINO=100 -I/Users/dgoodman/Documents/Arduino/hardware/OpenLCB/cores/OpenLCB -I/Users/dgoodman/Documents/Arduino/hardware/OpenLCB/variants/OpenLCB -I/Applications/Arduino.app/Contents/Resources/Java/libraries/SPI -I/Applications/Arduino.app/Contents/Resources/Java/libraries/Ethernet -I/Applications/Arduino.app/Contents/Resources/Java/libraries/SPI/utility /Applications/Arduino.app/Contents/Resources/Java/libraries/SPI/SPI.cpp -o/var/folders/+Z/+ZVggXdSHbW9VypYQpUaIE+++TI/-Tmp-/build1183822088658838250.tmp/SPI/SPI.cpp.o
/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=at90can128 -DF_CPU=16000000L -DARDUINO=100 -I/Users/dgoodman/Documents/Arduino/hardware/OpenLCB/cores/OpenLCB -I/Users/dgoodman/Documents/Arduino/hardware/OpenLCB/variants/OpenLCB -I/Applications/Arduino.app/Contents/Resources/Java/libraries/SPI -I/Applications/Arduino.app/Contents/Resources/Java/libraries/Ethernet -I/Applications/Arduino.app/Contents/Resources/Java/libraries/Ethernet/utility /Applications/Arduino.app/Contents/Resources/Java/libraries/Ethernet/Dhcp.cpp -o/var/folders/+Z/+ZVggXdSHbW9VypYQpUaIE+++TI/-Tmp-/build1183822088658838250.tmp/Ethernet/Dhcp.cpp.o
In file included from /Applications/Arduino.app/Contents/Resources/Java/libraries/Ethernet/Dhcp.cpp:4:
/Applications/Arduino.app/Contents/Resources/Java/libraries/Ethernet/utility/w5100.h:100: error: expected unqualified-id before numeric constant

The code in hardware/OpenLCB/cores/OpenLCB is a fresh copy of all the files in Arduino.app/Contents/Resources/Java/hardware/arduino/cores/arduino/

Sketches using Ethernet compile just fine for the Uno or any other built-in hardware supported boards. The only relevant software differences between the Uno and my boards is in boards.txt, and variants/.../pins_arduino.h

(The reason the core files are alike is to try to get the sketch to compile; there are, of course, some significant differences in the hardware that should be reflected in the core files, but I'll go back and add those changes back in once I see why the Ethernet library is causing me problems.)

You don't need to spend a dime to prove or disprove whether it will work for yourself. You can do it entirely on paper. Take the specs of your LEDs and the specs of the LED Intruder and see if it will handle the loads you proposed. Of course, you should do this kind of analysis before buying ANY product or component.

I think the LED Intruder is a great product. But it just doesn't appear to fit your original requirements. Or maybe you can change your requirements to fit the LED Intruder. Only you can make that kind of trade-off decision because you know the project and we don't.

My intent is not to "poo poo" you.  I am just suggesting that you do the calculations before getting excited about anything.

I think there is some ambiguity in the OP's requirements. If the intent is to run 10 LEDs off of one output channel, well, that's not gonna happen. That would fry the LED Intruder pretty quick (been there, done that). If the intent is simply to control LEDs in banks of 10, that's not a problem. The OP could wire one set of 10 LEDs to one LED Intruder, 1 per channel, using one LED Intruder per bank of 10. Using the formula on page 11 of the manual, 10 LEDs drawing 20mA @ 12V will consume 2750mW of power, well below the 3958mW hard limit. (16LEDs, however, is too many. Just FYI). This of course assumes that the OP has soldered the heat pad underneath the chip to the PCB. If the heat pad hasn't been soldered down, the hard limit will be a good bit less; if the OP breadboards with a DIP package, the hard limit is less yet, and 10 LEDs may be too much at 12V.

In which case, perhaps the OP ought to reconsider the 12V power supply, and go for something lower. A 5V supply would probably be just fine for this application.

Don (creator of the LED Intruder)

Service mode is, unfortunately, another can of worms. Need sensitive current-detection hardware. A different project altogether. But on my plate!

THat's no good! I'll have a look a bit later to see what's changed.

You can't program an address in ops mode, in general. I don't know if that's in the NMRA specs or not, but my Digitrax Zephyr won't do it either. So that, at least, is not a bug But the other things are. Do you think there is a pattern to what's getting programmed?

That explains alot, with the booster hooked up to pin 11 it's working perfectly!

Excellent! Glad to hear it! I'll merge the branches later today.

The Mega has a different pinout for the internal timers, which necessitates using a different pin for the signal output. I clearly need to better document this fact!

Do let me know if any other issues crop up, or if there's a feature you'd like to see added, and keep us abreast of the fun things you do with CmdrArduino!

I've been watching this thread with interest - nice work on this library

Thank you! I hope to have an OpenLCB library to augment it by the NMRA West convention, to make a complete Arduino-based command station.

Oh, that line should have had square brackets:

Serial.print(current_packet[j],HEX);

That's debugging code from back when I suspected the problem you were experiencing was Mega-specific. Just comment all those Serial.print lines out.

Finally, on the Mega, the DCC signal is output on digital pin 11, not pin 9.

Found a few more typos besides; all patched now; MEGA branch updated too.

Apparently I never finished the e-stop code! Fixed.

Think I've fixed it. Found a nasty little bug in DCCPacket::setRepeat() that would prevent it from ever being set to zero! Download the latest version of the "master" branch, and try it out.

While you're at it, would you care to try out the "mega" branch on your Arduino Mega for me?

Interesting. Development was all done on a '168. Don't have a booster at the moment (waiting on the newest batch of LOLbooster PCBs to be fabbed up), so I'm not currently in a position to run the code with a real, live train (and my o'scope sucks at capturing DCC packets), but I will review both the initialization code and the estop code. The initialiation code had been working for me, but it is actually within NMRA spec to elide the layout reset bit; that's optional. So if that works for you, do it for now. The estop code is less well tested, and I have a susupicion that what's happening is in fact related.

Best guess: The estop_queue, which is used primarily for holding estop packets, but is also used by the layout reset code, is not handling packet repeats correctly, looping forever.

Hello! I'm the author of this library; I've heard tell others have had this same problem, but I can't replicate it, mostly because the problem seems to crop up on Arduino Megas, and I don't own one. Are you using a Mega?

Anyway, contact me off list if you need assistance, because I need your help tracking this bug down!

Thanks!