Dumping firmware/software...and/or reflashing??

bag06a:
With that said, do you have any book suggestions to read on this topic?

Unfortunately, no. This was the last book I read on embedded programming... http://www.amazon.com/Practical-UML-Statecharts-Second-Edition/dp/0750687061 Everything I learned about AVR processors I learned from the Arduino website, Atmel datasheets, and the internet at large.

I believe the question of "which book" has been discussed a few times on the forum. I suggest spending some time with Google...
https://www.google.com/search?q=book+site%3Aarduino.cc%2Fforum

Microconrollers/chips in general and definitely ones that cover the topics of what each pin is (such as MISO and MOSI and CLK and SCK and what not).

This is a fairly good description of SPI...

Essentially, the programmer sends four byte programming commands, over the SPI bus, to the target, which executes those commands.

Through a little bit of reading I know that MISO is Master In Slave Out and MOSI is Master Out Slave In ... CLK is clock I believe.

Correct.

(which MOSI usually connects to a MISO right?)

No. The pins are always from the perspective of the master. Master Out Slave In (MOSI) out of the master is still Master Out Slave (MOSI) in into the slave.

In the case of in-system serial programming the master is the programmer (LcSoft USBasp programmer) and the slave is the target (ATtiny84).

I want to learn more about this stuff so suggestions would be great :slight_smile:

My suggestion is to get your hands dirty. Nearly anything with an AVR processor and a USB connection can act as a programmer (Uno, ATmega328 on a breadboard, LcSoft USBasp) and test targets are fairly cheap...

Add this to the Arduino IDE...
http://code.google.com/p/arduino-tiny/

And you are ready to go!

Every now and then I really wish I wouldnt have left school for Computer Science after 2 years haha. But I guess it is what it is ya know?

I ordered a few ATTiny44 chips since I don't want to test on the phenom board just yet. Once those chips arrive, I'll try the steps you recommend. I tried the steps on the ATTiny20 chips (with different pin positions based on the datasheet), however, no matter what I tried I could not get the AVRISPmkII Programmer to read or write to the chip.

Well....I tried programming a brand new ATtiny44 with several different programmers including the Atmel AVRISP mkII using AVR Studio 6, USBasp using avrdude, and an arduino Uno with Arduino IDE. I tried first with the Atmel mkII since it was Atmel branded and the chips were Atmel, I figured I would go the Atmel route all the way. No matter what I tried, I could not get the programmer to read or write program data. I was able to get it to read the target voltage, and the LED on the mkII went from red to green when I connected the pins according to their documentation, but nothing.

Next, I tried the USBasp with avrdude. With this, I kept getting the error "avrdude: warning: cannot set sck period. please check for usbasp firmware update." I didn't get far with this solution. I could do more research to try and figure out what's wrong, but instead I moved on to the Arduino as an ISP.

The Arduino Uno as an ISP did something. I can't say what exactly, but once I configured the Arduino to be an ISP (uploaded the ArduinoISP sketch and changed some settings in the IDE), I was able to deploy to my test ATTiny44. To test my deployment, however, I hooked up an LED to one of the pins and got nothing (I deployed the blink sketch). I changed the blink program to turn multiple pins on and off just in case I got the wrong one on the board. Still nothing. At this point, I gave up and decided to try the Atmel mkII approach again, thinking that since Arduino worked a little, maybe I'd have better luck this time.

I don't know what the Arduino did, but when I got back into the AVR Studio 6 IDE, I could read and write to the chip. At least that's what the tool said it was doing. I was able to read Lock, Memory, and Fuse information. I was even able to "deploy" a simple application (similar to Blink) to the chip....at least the deployment didn't fail. The program was still not working (no LEDs were being lit). It's like the program is not making it to the chip.

I checked the LED, and it is working, and I made sure I had the polarity proper when putting it in the circuit.

I'm not sure what I may be doing wrong, I'll try some more combinations tomorrow.

Any ideas why the Atmel route would not recognize the chip until Arduino wrote something to it? How do I initialize virgin chips?

mikedehaan:
Any ideas why the Atmel route would not recognize the chip until Arduino wrote something to it?

Purely coincidence.

How do I initialize virgin chips?

No need. AVR processors come from the factory ready-to-run at 1 MHz. The Flash memory is filled with 0xFFFF which is an illegal opcode. Illegal opcodes are executed as NOPs (details here... http://support.atmel.com/bin/customer.exe?=&action=viewKbEntry&id=227 ). Apply power and the processor starts executing code that does nothing.

In other words, all you have to do to "initialize" the processor is upload a program.

The Arduino Uno as an ISP did something. I can't say what exactly, but once I configured the Arduino to be an ISP (uploaded the ArduinoISP sketch and changed some settings in the IDE),

Which settings?

I was able to deploy to my test ATTiny44. To test my deployment, however, I hooked up an LED to one of the pins and got nothing (I deployed the blink sketch). I changed the blink program to turn multiple pins on and off just in case I got the wrong one on the board. Still nothing.

What board was selected when you uploaded?

Ah Ha! Success! I had the circuit correct, but the arduino code wrong ::facepalm::

I hooked up the Arduino as an ISP and deployed a new version of blink and it worked. The Arduino API refers to pins differently than I would have expected, but with a small modification to the blink program, I was able to have the chip tell me which pin had which number. For example, Pin 3 is actually Pin 9 for the Arduino API. So I think my first version of blink was trying to tell the GND pin to blink (or something just as stupid).

There was a parameter in the heartbeat() method of ArduinoISP that needed to change. The instructions on one site said to change the delay(40) call to delay(20).

I selected the ATtiny44 board which is only available after downloading the ATtiny addons for Arduino. For anyone interested, I followed these turotials:

http://hlt.media.mit.edu/?p=1695

http://hlt.media.mit.edu/?p=1706

Here's my modified version of Blink. It will cycle through all the pins on the ATtiny44 and blink the number of times indicating which pin it is:

void setup() {                
  for (int i = 0; i < 12; i++) {
    pinMode(i, OUTPUT);
  }
}

void blinkPin(int pin) {
  
  for (int x = 0; x <= pin; x++) {
    digitalWrite(pin, HIGH);
    delay(20);
    digitalWrite(pin, LOW);
    delay(20);
  }
  delay(50);
}

void loop() {
  for (int i = 0; i < 12; i++) {
    blinkPin(i);
  }
}

One problem I still have is, the delay method seems to be running slow. I tried a delay of about 100 (which should be 100ms or 0.1 seconds) which resulted in about a 1 second delay. In the Atmel AVR Studio, you can set the F_CPU value to indicate to delay how fast your clock is. Is there something similar in Arduino that might be causing my delay method to run slow?

Thank you so much for your help by the way. I sincerely appreciate it.

mikedehaan:
I hooked up the Arduino as an ISP and deployed a new version of blink and it worked.

Excellent.

The Arduino API refers to pins differently than I would have expected,

Should be top-left to top-right in a U-shape around the processor. That's how the pins on the Uno (ATmega328 based boards) are numbered.

One problem I still have is, the delay method seems to be running slow.

The program is compiled for 8 MHz and the processor is configured to run at 1 MHz. I suggest using this core...
http://code.google.com/p/arduino-tiny/

I added two ATtiny44 entries for you. Use this download...
http://code.google.com/p/arduino-tiny/downloads/detail?name=arduino-tiny-0100-0013.zip

Start with the ATtiny44 @ 1 MHz (internal oscillator; BOD disabled) board entry. After re-uploading, your program should blink correctly (±10%).

When you are comfortable everything is working correctly, select ATtiny44 @ 8 MHz (internal oscillator; BOD disabled) then execute Tools / Burn Bootloader. That will change the fuses (reconfigure the processor) to run at 8 MHz. Even though the processor is running 8x faster, after re-uploading, your program should still blink correctly (±10%).

Running at 1 MHz is a great choice for battery power. Running at 8 MHz is a great choice if you need the extra horsepower.

Thank you so much for your help by the way. I sincerely appreciate it.

You are welcome.

Just to confirm the chip, I was able to hookup (briefly) to the Paintball gun circuit and the device id matches the id of a brand new ATtiny44A from Atmel.

Phenom Device ID: 0x1E9207
ATtiny44A Device ID: 0x1E9207

Helpful tip: It is possible to download a binary version of the program from the Paintball gun. You may want to do this early in your project so you have a backup.

Great news about the processor. That will make your development effort go much more smoothly.

You guys are geniuses ha.

Sorry if I haven't contributed much (anything) this project Mike. You clearly have a greater understanding of all this, but I will certainly be learning.

Helpful tip: It is possible to download a binary version of the program from the Paintball gun. You may want to do this early in your project so you have a backup.

Great news about the processor. That will make your development effort go much more smoothly.

How would you go about doing this and how would you end up using it in the long run?

I tried to read the flash from the device to backup the program, however the data that came out (no errors reported) was essentially blank. I did notice that there's a lock bit set "PROG_VER_DISABLED", but I have no idea what that means. I can't seem to find a definition of these lock bits anywhere. I'm guessing this is why I cannot backup the chip?

I really don't want to lose the original program, so I make have to solder the chip off the board (:astonished:). Once my new program is working I won't need to solder anymore boards, but until I know I have a working program, I need to keep the original safe.

I think I found a description of the lock bit in the Atmel datasheet:

Further programming and verification of the Flash and EEPROM
is disabled in High-voltage and Serial Programming mode. The
Fuse bits are locked in both Serial and High-voltage
Programming mode.(1) debugWire is disabled.

Well...I've bit the bullet so to speak. I've desoldered the original chip and soldered it to an SOIC-to-DIP adapter, and soldered a shiny new ATtiny44 to the phenom board. I've also built a test bed around the original chip with LED's and resistors and have correctly identified the trigger (actually uses 2 pins), solenoid, red LED, green LED, and push button.

I would also like to figure out how to use debugWire so I would only have to worry about 3 pins (Vcc, GND, debugWire) rather than the regular 6 (Vcc, GND, RESET, SCK, MISO, MOSI). I know I have to set a fuse to use it, but I'm not sure what else may be involved (if it will work with my Atmel mkII).

At this point, it's only a matter of writing the appropriate software to drive the new chip in the phenom board.

Mike, has anyone told you that you're amazing??? If not, you're amazing haha. What is your "test bed" currently doing? And how did you got about confirming the trigger uses two pins?

lol...thanks, though I wouldn't have anything if it weren't for the excellent assistence from Coding Badly.

Here's a quick video of my test bed. Check it out:

Does the red LED maybe have anything to do with the programming mode (setting denounce time and other features??)

I agree, coding badly has been extremely valuable in this project. If I could I'd by him a drink (if he drinks....otherwise a root beer ....I personally would take ge root beer ha)

Great video demonstration btw.

mikedehaan:
I tried to read the flash from the device to backup the program, however the data that came out (no errors reported) was essentially blank. I did notice that there's a lock bit set "PROG_VER_DISABLED", but I have no idea what that means. I can't seem to find a definition of these lock bits anywhere. I'm guessing this is why I cannot backup the chip?

Oh bugger! I completely forgot about the lock-bits. You will not be able to make a backup. Sorry about that.

mikedehaan:
I would also like to figure out how to use debugWire so I would only have to worry about 3 pins (Vcc, GND, debugWire) rather than the regular 6 (Vcc, GND, RESET, SCK, MISO, MOSI). I know I have to set a fuse to use it, but I'm not sure what else may be involved (if it will work with my Atmel mkII).

Like TPI this is not the best place for debugWire help. In my case, I have no idea how to get debugWire working.

The core I mentioned in Reply #36 includes Tiny Debug Serial. It's similar to Serial available on a normal Arduino. I also have something better (but still similar to Serial) available. If you're interested send me a Personal Message with your email address.

lol...thanks, though I wouldn't have anything if it weren't for the excellent assistence from Coding Badly. ... I agree, coding badly has been extremely valuable in this project. If I could I'd by him a drink (if he drinks....otherwise a root beer ....I personally would take ge root beer ha)

My pleasure. And, yes, I do occasionally enjoy a beer. However, I will never ever refuse a...

https://www.google.com/search?q=dr+pepper+cane+sugar&tbm=shop

Don't let anyone try to fool you. With cane sugar is the only way to make Dr. Pepper!

In case I did not mention it earlier: The ATtiny84 is a drop-in replacement for the ATtiny44 with double the memory. If your new trigger code won't fit you can easily upgrade to a "bigger" processor.