Arduino Forum

Topics => Device Hacking => Topic started by: bag06a on May 11, 2012, 05:01 am

Title: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 11, 2012, 05:01 am
So heres the quick deal (trying to go fast and to the point, laptop going to be dying soon ha). I have a paintball marker (tippmann x7 phenom) and it has some features of the electronic grip that I would like to redo. I know it is possible because I know of one person who is already reflashing (not making a new board or electronics to go inside the grip...but reprogamming it). I want to do it myself because 1. i dont want to pay lol and 2. I think it would be a fun project.

My question is this; How do I do a firmware dump on it so I can look at the code and modify it?? I'm sure that knowing the controller is one step. I am currently working on figuring it out. I THINK it may be an atmel ATtiny20. I see very small writing on the chip that says "atmel" and then some numbers that are very hard to distinguish. To me it looks like "atmel 0928" or something but cant really find anything with those exact numbers. something else that is written very time on it is "20SSO" (or so it looks like). Seems to me that it may be the package possibly but again I am not 10% sure. Also it has written on it (in bigger letters) "T20Ver2", however it is different writing than the others and dont know if it that writing comes directly from atmel or not.

My reasoning for believe that it's a ATtiny20 is that I refined search parameters to the pin count (14) and anything that had "SSO" anywhere in the package type.

Think you guys would be able to lead me in the right direction?
Title: Re: Dumping firmware/software...and/or reflashing
Post by: Coding Badly on May 11, 2012, 09:47 am

The ATtiny20 only supports TPI (Tiny Programming Interface) programming.  Do you have a programmer that supports TPI?

I suggest posting a high quality photograph of the processor.
Title: Re: Dumping firmware/software...and/or reflashing
Post by: bag06a on May 11, 2012, 03:06 pm
I can try and take a picture of it later today, but I cant promise that you will be able to read any of the text on it. I had a hard enough time reading it with a magnifying glass haha (it was only a helping hands magnifying glass though). I'll keep you posted.

In regards to a TPI, no I do not have one. Probably could find a way to make one though hey? Not even 100% sure it is an ATtiny. Come to think of it, if I need a TPI, I remember seeing a video on youtube called "shrinkify your arduino projects" where they guy used an arduino uno (i think) to program a tiny.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 11, 2012, 11:54 pm
Ok I took some pictures of the chip. Sorry if they aren't good enough, they are the best I could get. That pesky T20Ver2 is for the most part in the way of the full model >.<  .
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 12, 2012, 04:23 am
That pesky T20Ver2 is for the most part in the way of the full model >.<  .


Have any whiteout?  Or finger nail polish?  You may be able to rub something into the lettering.  Or you may be able to carefully scrape off the T20Ver2.

Quote
Ok I took some pictures of the chip. Sorry if they aren't good enough, they are the best I could get.


The pictures are good enough.  The T20Ver2 definitely obscures the interesting bit.

I suspect that may not be an AVR processor.  I have dozens of AVR processors.  They are all imprinted with the Atmel logo... (http://www.atmel.com/Images/atmel.png).  None of them have the word "Atmel" in a typical typeface like the chip in your picture.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 12, 2012, 04:43 am
The T20VER2 might be etched onto the plastic, I cant remember. But for curiosity's sake (yours and mine) I will try (very carefully) some fingernail polish :).

If it's not an AVR what might it be??

Could it still be an AVR of sorts and just not have the Atmel logo on it? Maybe as a mass purchasing agreement with Tippmann?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 12, 2012, 05:52 am
If it's not an AVR what might it be??


Atmel makes at least two other microcontroller lines and has a long line of various memory chips.

Quote
Could it still be an AVR of sorts and just not have the Atmel logo on it?


Of course.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 12, 2012, 07:27 am
In short...I'm in the same boat.  After purchasing the tippmann phenom x7 I was a little upset regarding the "safe" features of the firing modes.  Needless to say, I'm heading down the same path, and while this will likely end up more expensive than buy a new board (or potentially a new gun  :smiley-eek:), I'm likely to gain useful knowledge about electronics and microprocessors along the way.  That knowledge is worth the journey.

But enough about me, on to the good stuff....

I decided to dust off my old oscilloscope and probe the pins as the trigger operates.  I figured I would at least be able to spot the power and ground pins and perhaps even the trigger pin.  Here's what I discovered in my tests:


If you hold the board with the reset button and LEDs facing you (solenoid on top), the top of the chip should be on the right (there's a little etched circle in the top left of the chip to inicate "top")

Top down (Left side)
1 - VCC Power (approx 9v)
2 - 0v (Digital in/out set to LOW?)
3 - 5v (Digital in/out set to HIGH?)
4 - 5v seems to reset the board when probed (firing is canceled and LED stays solid)
5 - 5v (Digital in/out set to HIGH?)
6 - solenoid trigger (fires the gun) (+5v when firing 0v otherwise)
7 - 5v (Digital input?)  - switches to 0v when the trigger is held (but not in pulses like #6)  Is this the magnetic trigger relay?

Bottom up (right side)
8 - 0v (Digital in/out set to LOW?)
9 - 0v (Digital in/out set to LOW?)
10 - 5v (Digital in/out set to HIGH?)
11 - Green status LED
12 - Red status LED
13 - 5v (Digital out set to HIGH?)
14 - ground

I can't say for certain that this is the ATtiny20, but I can say that if someone else is able to reprogram the chip without soldering and tippmann burned a T20 into the chip face, chances are we're dealing with an ATtiny20.

Can anyone with more expertise gather any more information from the pin data I've gathered?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 12, 2012, 07:33 am
Also, to help with the original post:

I was also looking for a way to backup the original binary so that if all else failed I could just revert to factory settings.  I do not intend to modify the original code mostly because the best I'll be able to do is download a hex/binary dump of raw data...not source code.

In my quest, I found this link:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1290093229

I couldn't find if it supported the ATtiny20, but since I don't have an in system programmer yet, I couldn't really try.  Could anyone recommend a good ISP for the ATtiny20?

I hope some of this helps.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 12, 2012, 07:43 am
Quote
1 - VCC Power (approx 9v)
ATtiny20


Those two are mutually exclusive...

Quote
20. Electrical Characteristics
20.1 Absolute Maximum Ratings
Maximum Operating Voltage ............................................ 6.0V

Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 12, 2012, 07:51 am
That makes more sense as to what I saw on the scope.  I don't have a multimeter handy to get actual voltage measurements, but I thought it was closer to the 10 than the 5. (I'm not dealing with a very accurate device).

I grounded the oscilloscope on the positive node of the 9v power supply and probed the VCC once again and the voltage difference was negative.  So for certain it's less than 9v (quite possibly 6v).

Once I dig up my multimeter, I'll find out what VCC is exactly.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 12, 2012, 07:57 am

If VCC is 5 volts then...

Quote
Top down (Left side)
1 - VCC Power (approx 9v)
4 - 5v seems to reset the board when probed (firing is canceled and LED stays solid)

Bottom up (right side)
14 - ground


...are a strong indication that it is a 14 pin Atmel processor.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 12, 2012, 08:00 am
Thanks!  That's good news.

Any advice on an in system programmer for the ATtiny20?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 12, 2012, 08:08 am

The only help I can provide is negative.  If it is an ATtiny20 then the link in Reply #8 will not help.  As you can see from Google...

https://www.google.com/search?q=tpi+site%3Aarduino.cc&oq=tpi+site%3Aarduino.cc

...this forum is probably not the best place to ask the question.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 14, 2012, 07:47 pm
So I messages the guy on the forum that he regularly attends (figured it was a long shot but worth a try) and the only hints he gave were that he completely rewrote the software and that the model number of the cHip is printed on the chip :-/
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 14, 2012, 08:26 pm

Try cleaning the top of the chip using a paper towel dipped in rubbing alcohol.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 14, 2012, 08:43 pm

...the only hints he gave were that he completely rewrote the software...


I figured as much.  I've started writing my own software for this as well.  Right now it's a series of blinking LED's in the simulator ;)

Also, I was able to confirm that VCC was 5v. (finally found my multimeter :D)

I figure that since I have the pinouts and a pretty good idea how the platform is supposed to operate (pull trigger => fire gun), I have a good chance in writing something that works.  If you'd like to collaborate on this adventure please send me a private message and I'll give you my email address.

I think we've exhausted the Arduino nature of this topic, so this forum is probably not the best place to proceed.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 14, 2012, 09:26 pm
I think we've exhausted the Arduino nature of this topic, so this forum is probably not the best place to proceed.


That is only possibly true if the processor is an ATtiny20.  SPI programmable ATtiny processors (e.g. ATtiny84) are very popular in the Arduino world.  They can be programmed easily using any Arduino compatible board.  There is even a forum section dedicated to the pursuit... Microcontrollers (http://arduino.cc/forum/index.php/board,67.0.html).
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 14, 2012, 09:39 pm
Yea, I'd like to Collaborate on this adventure. It'd be great learning experience. I'll send you a pm when I get home so I don't have to do it on my phone.

Also, coding badly, data sheet for attiny20 says its ISP. Does that dramatically change things?

http://www.atmel.com/Images/doc8235.pdf
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 14, 2012, 10:21 pm
Also, coding badly, data sheet for attiny20


You've determined that it is an ATtiny20?

Quote
says its ISP. Does that dramatically change things?


ISP = In System Programming.  It's a generic term meaning the processor can be programmed after being installed on a board.  Atmel processors have several flavours of ISP: Serial (the most Arduino friendly), Parallel, debugWIRE, etcetera.

One of those ISP flavours is "TPI".  As far as I can tell, the ATtiny20 only allows TPI programming.  The other flavours are not supported.  TPI programming has been rarely if ever discussed here.

The processor is essentially a stripped down ATmega328.  The folks here have lots of experience with the 328 so I suspect you can get help here regarding low-level hardware questions.  But probably not much help regarding uploading the new software via TPI.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 14, 2012, 10:42 pm
Have not concluded that it is the tiny20. Just checking out the data sheet based on speculation and this discussion so far.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 14, 2012, 10:59 pm

Do you have a way to connect probes / wires to the processor?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 15, 2012, 02:20 am
Connect how? to have a good seat for programming it or just for probing like with a multimeter??

BTW I tried rubbing alcohol and it didn't work. The T20 is pretty much etched in I believe. I did also make a mistake in trying nail polish remover/acetone....big noob mistake ha.it got rid of the shiny part of the casing and now you cant even read the atmel or the 20sso. Chip/board still works, just now the only thing (from me) we have for studying is the pics haha. Lessons learned :)
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 15, 2012, 02:40 am
Connect how? to have a good seat for programming it or just for probing like with a multimeter??


Programming.  But, if you're convinced it's a t20 processor, there is no point in running the experiment I had in mind.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 18, 2012, 05:23 am
I tried to take a picture of my board as well.  I'm actually now thinking that it's a ATTINY44 versus the ATTINY20. 

Update:
I've added another picture so you can see where I think the numbers are.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 18, 2012, 06:07 am

In that top picture it does look like a "44".

If...

• It is an SPI programmable processor (like an ATtiny44)
• You can get some connections to it
• RESET has not been disabled
• SPI programming has not been disabled

...you can determine exactly which processor it is by reading the signature bytes.  With the exception of the physical connections, making the attempt is very unlikely to damage anything.  Just include series resistors; 220 ohms works well.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 18, 2012, 09:57 pm
Good find. I do agree with you on the ATtiny44 branding. You must have had some good lights and a good magnifier or good camera (maybe with macro lens). Your text below T20Ver2 is clearer as well. Instead of 20SSO it looks more like 20SSU. From what I've seen on the Atmel site that number doesn't refer to a specific Package or anything like that, it refers to the ordering code. In the case of the ATTiny44 that ordering code links to one with the package of "SOIC (150mil) 14S1 14". Power supply for this chip is 2.7-5.5V and is 20MHz.

You probably have already seen the information, but at least I feel like i'm contributing lol.

For programming an ATTiny44 checkout this webpage as well http://hlt.media.mit.edu/?p=1695
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 18, 2012, 10:51 pm

Just include series resistors; 220 ohms works well.


Ok, I'm willing to give that a shot.

What do I need to connect?  Do I connect the programmer's Vcc (5v), MOSI, Reset, SCK, MISO, and Gnd to the respective pins on the ATTINY44? You mentioned 220 ohm resistors, where whould I put them?  I see plenty of examples online how to program a chip in isolation, but I can't find anything about programming a chip that's soldered into a production board.  I assumed that's what was meant by In-System Programming, but I can't find any good examples.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 18, 2012, 11:04 pm

How is the target (the ATtiny84) normally powered?  At what voltage?

What else is in the circuit?  Is the total current less than about 350 milliamps?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 18, 2012, 11:21 pm
The target circuit board is powered via a 9v battery, though Vcc for the ATtiny44 is +5v.  The only other noteable part of the board would be the 3055L MOFET which I'm guessing is used to drive the Solenoid.

I would guess that the main draw is the solenoid, so as long as the trigger (which activates the Solenoid) is never fired, I'm pretty sure the draw is under 350mA.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 18, 2012, 11:39 pm

Argh!  Stupid brain!  Pay attention!

Sorry about that.  You had stated earlier that the processor runs at 5V.  Apparently, my brain had gone on walkabout.

What will you be using as a programmer?  An Arduino Uno?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 18, 2012, 11:43 pm
:) No worries.  I'm only pretending to know what I'm talking about.  :smiley-eek:

At the moment, I have a LcSoft USBasp programmer.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 18, 2012, 11:49 pm

Have you used it to program an AVR processor?  Are you familiar with AVRDUDE?

Do you have a link to a schematic for the programmer?  It may already include series resistors.  They are nothing more than a resistor connected between the programmer and the target in series.  There would be three or four resistors and they are very likely the same values.  1K ohms seems to be a popular choice.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 19, 2012, 12:00 am
Speak of the devil..while I was typing my response, the doorbell rang to deliver my Atmel AVRISP mkII.  I don't have the schematic for this one, but I think the schematic of the USBasp is here:

http://www.fischl.de/usbasp/
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 19, 2012, 12:30 am

No for the series resistor question.  I'll assume you're familiar with AVRDUDE and have used the USBASP programmer.


The first phase is to get the target to respond; no programming.  I suggest powering the target using it's normal power source (the 9V battery) (but don't power the target until the end).  I suggest having the programmer schematic accessiable and the ATtiny84 (44 is in the family) datasheet open to the 1. Pin Configurations section while connecting the programmer to the target.  In other words, carefully review my instructions.  With all the power off, connect...

• GND to GND.  From the programmer schematic either pin 8 or pin 10 will work.  This is connected to pin 14 (upper-right corner) on the target.

• VCC is not connected.  Pin 2 on the programmer should not be connected.

• MOSI is connected to MOSI with a series resistor (220 ohms or higher).  Pin 1 on the programmer is connected to a resistor which is then connected to pin 7 on the target (lower-left corner).

• MISO is connected to MISO with a series resistor (220 ohms or higher).  Pin 9 on the programmer is connected to a resistor which is then connected to pin 8 on the target (lower-right corner).

• SCK is connected to SCK with a series resistor (220 ohms or higher).  Pin 7 on the programmer is connected to a resistor which is then connected to pin 9 on the target (lower-right corner just above MISO).

• SS to RESET with a series resistor (220 ohms or higher).  Pin 5 on the programmer is connected to a resistor which is then connected to pin 4 on the target (left side in the middle).


At this point I suggest connecting the programmer to the computer and building up an AVRDUDE command.  AVRDUDE will be able to communicate with the programmer but the programmer will not yet be able to communicate with the target (no power).  Include extra verbose mode (-v -v -v -v) when running AVRDUDE. 

When you are content you have the command you want to run (feel free to ask on the forum for an opinion; I'm sure someone will have one) power the target and then run the command.

If all goes well AVRDUDE will read the signature bytes (it always does this) and then output the signature byte (that's the purpose of extra verbose).  If that works, you are in business!
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 19, 2012, 12:49 am
Wow thats alot of information :-\. I feel extremely ill informed just by reading that and I'm realizing that I have ALOT of learning to do. I still want to partake in this project, however it will be more of a step-by-step learning experience I think.

With that said, do you have any book suggestions to read on this topic? 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). Through a little bit of reading I know that MISO is Master In Slave Out and MOSI is Master Out Slave In (which MOSI  usually connects to a MISO right?) CLK is clock I believe. I want to learn more about this stuff so suggestions would be great :)
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 19, 2012, 01:50 am
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

Quote
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...
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

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

Quote
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.

Quote
(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).

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


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...
http://search.digikey.com/us/en/products/ATTINY84-20PU/ATTINY84-20PU-ND/1245916
http://www.mouser.com/ProductDetail/Atmel/ATTINY84-20PU/?qs=2nyfZ6BV3ohscROPiyTV88GRZOsCDQSKLmyBo24c8Ug%3d
http://www.newark.com/jsp/search/productdetail.jsp?SKU=68T3783&CMP=AFC-GB100000001
http://www.sparkfun.com/products/11232

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

And you are ready to go!
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 19, 2012, 02:21 am
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?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 20, 2012, 02:52 am
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.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 22, 2012, 07:51 am
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?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 22, 2012, 09:19 am
Any ideas why the Atmel route would not recognize the chip until Arduino wrote something to it?


Purely coincidence.

Quote
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.

Quote
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?

Quote
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?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 22, 2012, 08:52 pm
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).


Which settings?


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).


What board was selected when you uploaded?


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:

Code: [Select]

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.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 23, 2012, 03:17 am
I hooked up the Arduino as an ISP and deployed a new version of blink and it worked. 


Excellent.

Quote
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.

Quote
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.

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


You are welcome.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 24, 2012, 06:05 am
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

Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 24, 2012, 07:56 am

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.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 24, 2012, 05:07 pm
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.

Quote
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?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 24, 2012, 05:23 pm

...It is possible to download a binary version of the program from the Paintball gun...


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 (:smiley-eek:).  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.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 24, 2012, 05:42 pm
I think I found a description of the lock bit in the Atmel datasheet:

Quote

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.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 25, 2012, 04:08 am
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.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 25, 2012, 05:04 am
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?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 25, 2012, 05:40 am
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:

http://youtu.be/5TNArp6eyUc
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 25, 2012, 06:05 am
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.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 25, 2012, 08:12 am
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. 
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 25, 2012, 08:19 am
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 (http://arduino.cc/forum/index.php/topic,105400.msg798633.html#msg798633) 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 (http://arduino.cc/forum/index.php?action=pm;sa=send;u=10859) with your email address.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 25, 2012, 08:29 am
Quote
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!
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on May 25, 2012, 08:32 am

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.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 25, 2012, 11:54 pm
Muhahahahaha!!  ]:D

My first version of my new code deployed on the new Attiny44 on the Phenom Board:

http://youtu.be/nh0e4etHXp8

Next, I think I'm going to work on creating a menu system so you can change the firing mode without reprogramming.  At the moment, I've created full auto and three round burst.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 26, 2012, 12:27 am
again, you're incredible lol.

Can I see the code you have so far?

Still plan on sharing this with the world and not shutting me out when its done? ;)

As well what are the things I'll need when I am able to program this on my own?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 26, 2012, 01:47 am

Still plan on sharing this with the world and not shutting me out when its done? ;)


No, now I have it and it's mine!  ]:D  j/k

Of course!  At the moment things are a mess, but you're more than welcome to have a look.  I'm programming in the Atmel AVR studio, but things should transfer easily to Arduino if you choose.  I'll paste the code at the end of this post.


...what are the things I'll need when I am able to program this on my own?


You will need an ISP, software that works with the ISP, some jumper wire, code (and/or binary file from me), and really steady hands.  I bought an AVRISP mkII because I was concerned that I wouldn't get another ISP to work.  On hand, I had a cheap USBasp ISP and an Arduino.  I was able to get both the Arduino and the mkII to work.  No luck with the generic USBasp.

I'll post better instructions once I build a proper forum for it.  Perhaps I'll start a blog on it.

Code: [Select]

#include <avr/io.h>
#define F_CPU 8000000UL
#include <util/delay.h>

#define HIGH 1
#define LOW 0

int BALLS_PER_SECOND;
int ROUND_DELAY; // delay between shots in ms
int DEBOUNCE;  // Debounce in ms

void initialize() {
BALLS_PER_SECOND = 30;
DEBOUNCE = 8;
ROUND_DELAY = (1000 - DEBOUNCE) / BALLS_PER_SECOND;
}

void delay_ms( int ms ){
for (int i = 0; i < ms; i++) {
_delay_ms(1);
}
}

int getPinMask(int pinNumber) {
if (pinNumber == 2) {
return (1 << 0);
} else if (pinNumber == 3) {
return (1 << 1);
} else if (pinNumber == 4) {
return (1 << 3);
} else if (pinNumber == 5) {
return (1 << 2);
} else if (pinNumber == 6) {
return (1 << 7);
} else if (pinNumber == 7) {
return (1 << 6);
} else if (pinNumber == 8) {
return (1 << 5);
} else if (pinNumber == 9) {
return (1 << 4);
} else if (pinNumber == 10) {
return (1 << 3);
} else if (pinNumber == 11) {
return (1 << 2);
} else if (pinNumber == 12) {
return (1 << 1);
} else if (pinNumber == 13) {
return (1 << 0);
}

return 0;
}

void setInputPin(int pinNumber) {
if (pinNumber >= 2 && pinNumber <= 5) {
DDRB &= ~(getPinMask(pinNumber));
} else if (pinNumber >=6 && pinNumber <= 13) {
DDRA &= ~(getPinMask(pinNumber));
}
}

void setOutputPin(int pinNumber) {
if (pinNumber >= 2 && pinNumber <= 5) {
DDRB |= (getPinMask(pinNumber));
} else if (pinNumber >= 6 && pinNumber <= 13) {
DDRA |= (getPinMask(pinNumber));
}
}

void pinOutput(int pinNumber, int state) {
if (pinNumber >= 2 && pinNumber <= 5) {
if (state == HIGH) {
PORTB |= (getPinMask(pinNumber));
} else {
PORTB &= ~(getPinMask(pinNumber));
}
} else if (pinNumber >= 6 && pinNumber <= 13) {
if (state == HIGH) {
PORTA |= (getPinMask(pinNumber));
} else {
PORTA &= ~(getPinMask(pinNumber));
}
}
}

int pinHasInput(int pinNumber) {
if (pinNumber >= 2 && pinNumber <= 5) {
return (PINB & (getPinMask(pinNumber))) <= 0;
} else if (pinNumber >= 6 && pinNumber <= 13) {
return (PINA & (getPinMask(pinNumber))) <= 0;
} else {
return 0;
}
}

void threeRoundBurst() {
for (int i = 0; i < 3; i++) {
pinOutput(6, HIGH);
delay_ms(DEBOUNCE);
pinOutput(6, LOW);

// don't delay on the last round
if (i < 2) {
delay_ms(ROUND_DELAY);
}
}
}

void fullAuto() {
while (pinHasInput(7)) {
pinOutput(6, HIGH);
delay_ms(DEBOUNCE);
pinOutput(6, LOW);
delay_ms(ROUND_DELAY);
}
}

int main (void) {

initialize();

setOutputPin(12);
setOutputPin(11);
setInputPin(7);
setInputPin(5);
setOutputPin(6);
setInputPin(3);

////////////////////////////////////
// Enable pull up on trigger inputs
////////////////////////////////////

// Trigger
pinOutput(5, HIGH);
pinOutput(7, HIGH);

pinOutput(3, HIGH);
pinOutput(13, HIGH);
pinOutput(10, HIGH);
pinOutput(9, LOW);
pinOutput(8, LOW);
pinOutput(12, LOW);

// turn on green LED
pinOutput(11, HIGH);

while(1) {
if (!pinHasInput(7)) {

delay_ms(DEBOUNCE);
while (!pinHasInput(7)) {
// NOOP
}

// Fire!
//threeRoundBurst();
fullAuto();
}
}
return 1;
}
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 27, 2012, 05:55 pm
Ok...The code is a mess (it's been a long time since I've coded in C), but it seems to work.  I want to add one more firing mode, but for now the code supports full-auto, three round burst, and auto-response.  To enter configuration mode, turn off the board, hold the trigger, power on the board and release the trigger after 2 seconds.  The rest of the configuration is very similar to the Tippmann manual.  I'm not allowing Debounce and Dwell to be changed at the moment.

My next task is to setup a blog or other site so I can post some instructions on how to program your own chip.  I'm not sure which programmer you may have, but I'm going to need your help with figuring that part out.  I know I can program the chip with the Atmel AVRISP mkII, but I'd like to find a solution using either the Arduino or another programmer (USBasp) for a lower cost solution.

I've included the latest code and hex dump.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on May 27, 2012, 06:31 pm
Does the tactile button have no function now then? Also They way u described your programming mode it sounds similar to the x7 classic. Do u have classic or phenom?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 27, 2012, 06:47 pm
I have a Phenom X7.   I decided to change the programming around a little because I don't want to have to whip out a special tool to get to programming.  I was planning on using the button for "reset to factory default" (e.g.  on startup, hold the button for 5 seconds to reset the board).

Also, just a warning, I have not tested this latest code on the actual board yet.  I hope to get to that this weekend.  I'm mostly worried about the red LED.  Everything else has already been proven.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on May 27, 2012, 10:03 pm
Hahaha, well...my plans were foiled.  I just tested out the new build in the full system and found that you cannot hold the trigger down and switch from the "F" position to "FA" (to turn on the board).  So I switched the programming to use the pushbutton rather than the trigger to enter programming mode.

Other than that, I made some tweaks to Auto-Response and the new build mostly works.  I say mostly because successBlink is not working for some odd reason.  I'm baffled why it is not working on the board when it does on the testbed, but I'll figure that out later.  successBlink is supposed to blink green + red three times to indicate that your changes have been saved to the EEPROM.

I'm starting a google code project with everything I do.  I expect to put documentation, pictures, videos, etc up there.

http://code.google.com/p/phenomx7-etrigger/

If you'd like to contribute to some of the documentation etc, let me know.  I think all I need is an email address of yours to set you up.

From this point forward, new code and builds will be posted there.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Cainxxx on Jun 06, 2012, 05:03 pm

Hahaha, well...my plans were foiled.  I just tested out the new build in the full system and found that you cannot hold the trigger down and switch from the "F" position to "FA" (to turn on the board).  So I switched the programming to use the pushbutton rather than the trigger to enter programming mode.

Other than that, I made some tweaks to Auto-Response and the new build mostly works.  I say mostly because successBlink is not working for some odd reason.  I'm baffled why it is not working on the board when it does on the testbed, but I'll figure that out later.  successBlink is supposed to blink green + red three times to indicate that your changes have been saved to the EEPROM.

I'm starting a google code project with everything I do.  I expect to put documentation, pictures, videos, etc up there.

http://code.google.com/p/phenomx7-etrigger/

If you'd like to contribute to some of the documentation etc, let me know.  I think all I need is an email address of yours to set you up.

From this point forward, new code and builds will be posted there.


Hello mikedehaan, any news about your firmware?

What things I need to flash my phenom with your firm?

Correct me if I'm wrong:

1) ATTINY44A-PU
http://www.ebay.com/itm/2x-8-bit-Microcontroller-ATTINY44A-PU-/221023275589?pt=LH_DefaultDomain_2&hash=item3376038a45

2) PROGRAMER
http://www.ebay.com/itm/ATtiny24A-SSU-ATtiny24-ATtiny44-ATtiny84-AVR-SOIC14-150-mil-Programming-Adapter-/261012681784?pt=LH_DefaultDomain_0&hash=item3cc5917438

3) Your HEX File

================================

I need desolder the original chip from my board? or exist the posibility to program it directly in the board? Or is read only?

Your work is awesome!

Sorry for my very poor English... (Entiendes español?)



Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 06, 2012, 08:36 pm

Hello mikedehaan, any news about your firmware?


Yes!  I post updates for the firmware at the google project wiki.  A new version was uploaded last night.  Check it out here:

http://code.google.com/p/phenomx7-etrigger/wiki/Home


What things I need to flash my phenom with your firm?

Correct me if I'm wrong:

1) ATTINY44A-PU
http://www.ebay.com/itm/2x-8-bit-Microcontroller-ATTINY44A-PU-/221023275589?pt=LH_DefaultDomain_2&hash=item3376038a45


You do not need to buy a chip (unless you want to develop for the project).  The instructions on the wiki (the link above) will show you how to apply the new firmware directly to the chip inside your eGrip without desoldering.



2) PROGRAMER
http://www.ebay.com/itm/ATtiny24A-SSU-ATtiny24-ATtiny44-ATtiny84-AVR-SOIC14-150-mil-Programming-Adapter-/261012681784?pt=LH_DefaultDomain_0&hash=item3cc5917438


This programmer looks like it will do the job, but it quite a bit more expensive than what you will need.  The programmer I used was:

http://www.amazon.com/SainSmart-Programmer-ATMEL-ATMega-ATTiny/dp/B0051SRZWC/ref=sr_1_1?ie=UTF8&qid=1338268631&sr=8-1

Though you can find cheaper (eBay).  Just make sure it support ISP, is supported by AVRDUDE, and is supported by your Operating System.  It would be nice if it supplies 5v power.


3) Your HEX File


New versions of the program are uploaded to the following link:

https://code.google.com/p/phenomx7-etrigger/downloads/list


I need desolder the original chip from my board? or exist the posibility to program it directly in the board? Or is read only?


No, you do not need to desolder the chip from the board.  You can directly program the chip on the board.  The chip is writable, but must first be erased.  There is no way to backup the existing manufacturer's program, so USE AT YOUR OWN RISK.  There is no turning back once you install this software.

Good luck, and keep asking questions if you have trouble.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Cainxxx on Jun 07, 2012, 12:43 pm

Good luck, and keep asking questions if you have trouble.


Thanks for all replies man!! Last question, is there a way to backup original firmware?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 07, 2012, 04:14 pm

...is there a way to backup original firmware?


Unfortunately, there is no way to backup the original firmware.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Cainxxx on Jun 07, 2012, 06:45 pm
To implement in the future, this are the modes of Xboard Firmware:

Programmable Rate Of Fire-
1 to 30

Programmable Burst-mode-
2 to 8

Safe Burst mode -
Pulling the trigger three times in less than one second results in an X-shot burst on the third trigger pull. Each pull of the trigger in less than one second after this, results in another X-shot burst (X= 2 to 8 ).

Safe Full-Auto mode-
Pulling the trigger three times in less than one second results in full-automatic firing. Holding the trigger down on the third pull sustains this full-auto mode.

Auto-Response mode -
The marker fires on the pull and on the release of the trigger.

Turbo-mode -
Pulling the trigger three times in less than one seconds results in full-automatic firing at rate of 15 BPS. To sustain this rate of fire the trigger must be pulled at least once a second.

Semi-Auto -
This mode is the same as selecting the F firing mode with the selector switch (one pull/release of the trigger fires one time).

Burst mode -
The marker fires an X-shot burst on each trigger pull (X= 2 to 8 ).

Full-Auto mode -
Pulling the trigger results in full-automatic firing. Holding the trigger down on the first pull sustains this full-auto mode.

X mode -
Pulling the trigger results in full-automatic firing. Holding the trigger down on the first pull sustains this full-auto mode. The Rate of fire (ROF) will gradually increase depending on how long the trigger is held (10 to 25bps).

Super Response mode - aka A.D.A.M. mode
The marker fires an X-shot burst on each trigger pull and on the release of the trigger (X= 2 to 8 ).

===========================================

The follow feature is suggested by me:

Abbility to Change RATE OF FIRE (betwen 2 rates, 15 and 25 for example) directly by pressing program button
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 07, 2012, 07:38 pm

Programmable Rate Of Fire-
1 to 30

We currently support a rate of fire between 5 and 40 (as of version 0.3)


Programmable Burst-mode-
2 to 8

We currently support a burst between 2 and 10 (as of version 0.4)


Safe Burst mode -
Pulling the trigger three times in less than one second results in an X-shot burst on the third trigger pull. Each pull of the trigger in less than one second after this, results in another X-shot burst (X= 2 to 8 ).

If more people request "safe" firing modes I will implement them, however, this was the reason behind the whole project (to remove the "safe" feature).


Safe Full-Auto mode-
Pulling the trigger three times in less than one second results in full-automatic firing. Holding the trigger down on the third pull sustains this full-auto mode.

Same as above.


Auto-Response mode -
The marker fires on the pull and on the release of the trigger.

We currently support Auto-Response (as of version 0.3)


Turbo-mode -
Pulling the trigger three times in less than one seconds results in full-automatic firing at rate of 15 BPS. To sustain this rate of fire the trigger must be pulled at least once a second.

Similar functionality can be achieved by increasing your Rate Of Fire setting on Full Auto firing mode.  We do not require pumping the trigger to keep the gun firing.  If more people request this feature, I can implement it.


Semi-Auto -
This mode is the same as selecting the F firing mode with the selector switch (one pull/release of the trigger fires one time).

This is the same functionality as switching the selector switch to the F firing mode and therefore has not been implemented.  If more people request this feature, I will implement it.


Burst mode -
The marker fires an X-shot burst on each trigger pull (X= 2 to 8 ).

We currently support a burst between 2 and 10 (as of version 0.4).  To configure, select three round burst firing mode and adjust the burst size between 2 and 10.


Full-Auto mode -
Pulling the trigger results in full-automatic firing. Holding the trigger down on the first pull sustains this full-auto mode.

We currently support Full Auto (as of version 0.3).


X mode -
Pulling the trigger results in full-automatic firing. Holding the trigger down on the first pull sustains this full-auto mode. The Rate of fire (ROF) will gradually increase depending on how long the trigger is held (10 to 25bps).

We do not currently support full auto ramping.  If more people request this feature I will implement it, however, I have a few design changes I would implement instead.  I did not like the YouTube demo of this feature.


Super Response mode - aka A.D.A.M. mode
The marker fires an X-shot burst on each trigger pull and on the release of the trigger (X= 2 to 8 ).

We do not currently support Auto Response Burst firing mode.  My opinion on this is the trigger would start to feel heavier latency as the gun would be in the middle of firing while you either pull or release the trigger.  It is incredibly easy to fully saturate your gun's mechanical limit of rounds per second with 3 round burst alone.  However, if more people would like this feature, I will implement it.


Abbility to Change RATE OF FIRE (betwen 2 rates, 15 and 25 for example) directly by pressing program button

I definitely like this idea.  I will put this on the list to implement.

Thank you for your ideas!  Keep them coming!
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on Jun 07, 2012, 08:18 pm
The programming via the button is a great idea.

Know whats weird?? I got out my multimeter and put it on the continuity test mode and tried it on all pins (started with the pins you defined as VCC and gnd) and I didn't get any continuity? Shouldnt it be beeping???

Hopefully be getting my blank chips soon also :)
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 07, 2012, 08:41 pm
If you put the negative multimeter lead on the negative battery terminal, and the positive multimeter lead on the GND pin of the chip on the board, I would think the multimeter would show continuity.

I'll try this at home tonight and let you know if it works for me.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on Jun 07, 2012, 08:53 pm
Know whats weird?? I got out my multimeter and put it on the continuity test mode and tried it on all pins (started with the pins you defined as VCC and gnd) and I didn't get any continuity? Shouldnt it be beeping???


Don't do that!  It violates the electrical specifications.  While very unlikely in this case, any time the electrical specifications are violated there is a possibility of damage.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 07, 2012, 08:59 pm
Wow, good catch.  I didn't think of that.  The multimeter is probably sending some voltage through to get from point A to B that might cause damage.  What about measuring Ohm's?  Would that do the same?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on Jun 07, 2012, 09:00 pm

If you put the negative multimeter lead on the negative battery terminal, and the positive multimeter lead on the GND pin of the chip on the board, I would think the multimeter would show continuity.

I'll try this at home tonight and let you know if it works for me.


Confirmed-- Negative terminal to Pin14 worked for continuity.

Coding Badly -- TY for the warning....I certainly dont want to fry my chip :-\. How does it violate specifications? Is it possibly sending to much current and/or voltage through the chip just with the batteries in the multimeter?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on Jun 07, 2012, 09:12 pm
Quote
Absolute Maximum Ratings*
...
Voltage on any Pin except RESET
with respect to Ground ................................-0.5V to VCC + 0.5V

*NOTICE: Stresses beyond those listed under "Absolute Maximum Ratings" may cause permanent damage to the device. This is a stress rating only and functional operation of the device at these or other conditions beyond those indicated in the operational sections of this specification is not implied. Exposure to absolute maximum rating conditions for extended periods may affect device reliability.


VCC with respect to GND is zero.  The continuity and ohm meters very likely operate outside the -0.5 to +0.5 volt range.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 09, 2012, 04:42 pm

Abbility to Change RATE OF FIRE (betwen 2 rates, 15 and 25 for example) directly by pressing program button


The new version 0.6 now supports Presets which will accomplish this.  The new programming allows you to configure 3 complete seperate firing configurations (firing mode, firing rate, and burst size).  To toggle through the presets, you press the tactical button when the gun is on.  The LED will flash green indicating which preset you are in (one flash for preset #1, two flashes for preset #2, and three flashed for preset #3).

Instructions for configuring the presets are on the wiki:
http://code.google.com/p/phenomx7-etrigger/wiki/Home
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Cainxxx on Jun 12, 2012, 05:51 pm


Abbility to Change RATE OF FIRE (betwen 2 rates, 15 and 25 for example) directly by pressing program button


The new version 0.6 now supports Presets which will accomplish this.  The new programming allows you to configure 3 complete seperate firing configurations (firing mode, firing rate, and burst size).  To toggle through the presets, you press the tactical button when the gun is on.  The LED will flash green indicating which preset you are in (one flash for preset #1, two flashes for preset #2, and three flashed for preset #3).

Instructions for configuring the presets are on the wiki:
http://code.google.com/p/phenomx7-etrigger/wiki/Home


Thanks so much man. Give me some time to try this! ;). I need to buy the programer first. Your work is great!
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on Jun 22, 2012, 05:47 am
I successfully programmed my new attiny44 chip tonight using an arduino as an ISP. I will try and put something up on the wiki tomorrow! I'm super excited!
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Coding Badly on Jun 22, 2012, 05:57 am

Congratulations!
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Laggard on Jun 29, 2012, 04:45 am
Hello! I am very impressed by your work here and have ordered some cheap programmer to attempt some of this myself.  :)

My programming skills are sub-par and I may not be as able as willing to contribute, though, fair warning.  :smiley-roll-blue: I wondered about two things primarily, to start things out. One, is it reasonable to buy a new chip and experiment with that one, using your code as the starting point? By doing this I will keep a spare chip and sleep at night ;) Two, I also have an X7 classic I'd like to experiment with, how much of the code would conceivably need to be rewritten to suit the classic's trigger system and solenoid?

Keep up the good work!
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 29, 2012, 05:10 am
Excellent!  Welcome aboard!

I do not have any experience with the x7 classic.  I would not recommend using this software on the x7 classic eGrip.  I'm not sure if it uses the same chip as the Phenom, so the programming here may be useless.  If you can, please take a picture of the board (as detailed as possible - all sides of the board) and we might be able to figure out if it will work.  Is your board from Tippmann, APE, or another manufacturer?

If it does use the same chip, you can buy new chips to test with at several vendors (digikey, mouser, ...).

This is the chip that goes in the Phenom:
http://www.digikey.com/product-detail/en/ATTINY44A-SSU/ATTINY44A-SSU-ND/1914708

Since the chip is rather small and difficult to test with, you can get the same chip in DIP format to fit in a standard breadboard (warning: this chip is only for testing the programming, this chip will not fit in the marker):
http://www.digikey.com/product-detail/en/ATTINY44A-PU/ATTINY44A-PU-ND/1914707

Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Laggard on Jun 29, 2012, 01:00 pm
So I disassembled the eGrip on my X7 classic. Under a sticker on the chip I found the markings of an Atmel ATtiny44. (jackpot!) It is a stock Tippmann board, and from what I can understand the board is very closely related to the Phenom, moreso than the 98c and A5. I also own a 98pro and will disassemble it tomorrow to see if it is the same chip. This project may help a bunch of people if this is correct, not just Phenom users.

I don't have an adequate camera on hand. However, I compared with pictures found online and this is the exact same board, only mine is blue and with the solenoid still soldered on (mine fell off and I had to stick it back on) and a capacitor on the back that reads 6800µF / 10V.

http://i.imgur.com/0kWMP.jpg (http://i.imgur.com/0kWMP.jpg)

Perhaps it is my calling to port this amazing code to other Tippmann eGrips. I figured I might as well try the X7C first because the board is already soldered back and forth a few times.  :D

Thanks for the links by the way, but I fear the shipping fee is a bit excessive. $30 to ship a $1 chip of negligible weight to Norway seems off-putting somehow. I'll look for the part elsewhere.

Edit: I ordered an adapter cradle for ATtiny chips (http://www.ebay.com/itm/261012681784), the chips themselves and some breadboards from ebay and farnell.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on Jun 29, 2012, 04:15 pm
The adapter cradle for the tiny chips looks handy!!! I like that, good find!

I'm not an electronics genius (yet lol) nor do I pretend to be, but just on initial thought I'm thinking that that A5 and 98c boards are going to be completely different and this software may need tons of revamping to make it work. The main thing that tips me off to that is the fact of how each of them turn on. This may be minor, but it does signify in my mind a bit of different circuitry (hall effect vs push button).

Like I said though, this is just theory and though. I'm looking forward to finding out though.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Laggard on Jun 29, 2012, 05:59 pm
Yes, I may be overreaching in respect to my skill level there.  :smiley-roll-blue: The 98 pro / A5 board is not nearly similar to the x7 / Phenom family.  I disassembled it and recognized absolutely zero major components. I'll shelf the idea.

The adapter cradle (I don't know if it's called that but it sounded right) is perhaps the laziest way to reprogram the chips; then again, I am lazy and my rate of success hinges solely on a trial-and-error basis. Plus, I'm a lumberjack by trade and my abrasive, clumsy hands are not meant for precision soldering. Perhaps, with some luck - and a stanley knife - a cradle component like the one on top of that adapter can be soldered onto the motherboard itself. Could be useful for swapping chips fast.

As for the programming itself; from studying pictures and specification write-ups of the two boards, it seems this software is compatible without major modifications. The hardest challenge would presumably be swapping the mechanical mode on the Phenom eGrip with a semi-auto mode (or another slot for programmable firing modes, like on the APE board). Without modifications, I presume the board will either default to the programmed setting, not function on semi-auto, or not function at all. Murphy's Law tells me it's the latter, so I'll begin scouring the code itself to look for the loops I need to focus on. The two boards may be one magnetic sensor component off from being the exact same board, however.

I am a complete noob at this so bear with me if something I say makes absolutely no sense.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 29, 2012, 06:36 pm

The 98 pro / A5 board is not nearly similar to the x7 / Phenom family.  I disassembled it and recognized absolutely zero major components.


I agree.  My neighbor has an eGrip for the A5 and it didn't seem to be powered by a Atmel chip.  I wasn't able to get too close, but I would guess by the switches used to modify the firing modes, that it is not powered by a microcontroller.


The hardest challenge would presumably be swapping the mechanical mode on the Phenom eGrip with a semi-auto mode (or another slot for programmable firing modes, like on the APE board). Without modifications, I presume the board will either default to the programmed setting, not function on semi-auto, or not function at all. Murphy's Law tells me it's the latter...


In the Phenom board, there are three electromagnetic relays that are used to turn on the board, and sense when the trigger is pulled.  I may have been wrong in how I'm using them (it has been a burning question in my head since I started).  Out of the 3 relays, I'm utilizing 1 of them.  2 of the relays appear to be identical; they sense when the trigger is pulled.  The other relay does not appear to connect directly to the micro controller (it is used to power the board).

On the Phenom, there is a rare earth magnet in the safety switch.  When the switch is rotated to full auto, the magnet activates a relay to power on the board.  I'm not sure how an APE board is powered on for the x7.  It's possible that their board has another relay to sense the mechanical safety-switch position as well as full auto.  In other words, this may not be possible for the x7 or Phenom without modifying the hardware on the board.

I'll take another look at the relays on my board to see if one of the relays could be used to sense the mechanical safety-switch position.

As for modifying the software, it all depends on the pin-outs of the board:
Pins 5 and 7 connect to the relays for the trigger.  (their voltage goes LOW when the trigger is pulled).  I'm only using pin 5 to sense for trigger pulls.  Hopefully this matches the x7 classic.  As far as I could tell, there is no pin to control the relay that powers on the board.  It's probably connected directly to the voltage regulator to supply power to the chip.


Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 30, 2012, 12:47 am
I tried to create a picture representation of my test board.  I think I got all the connections right.  :D

Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on Jun 30, 2012, 12:51 am
Whats with the green highlights on the powered rows and columns? is that a feature I missed in VBB?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jun 30, 2012, 01:16 am
I used a different program called Fritzing.  It uses highlights on the breadboard for easy reading:

http://fritzing.org/

I especially like the auto routing capabilities between the breadboard and Schematic modes.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Laggard on Jun 30, 2012, 03:02 am
I agree.  My neighbor has an eGrip for the A5 and it didn't seem to be powered by a Atmel chip.  I wasn't able to get too close, but I would guess by the switches used to modify the firing modes, that it is not powered by a microcontroller.

It is an 8-pin something something that I'm not too familiar with.  :) It'll be a project for a time when resources are scarce I suppose.

In the Phenom board, there are three electromagnetic relays that are used to turn on the board, and sense when the trigger is pulled.  I may have been wrong in how I'm using them (it has been a burning question in my head since I started).  Out of the 3 relays, I'm utilizing 1 of them.  2 of the relays appear to be identical; they sense when the trigger is pulled.  The other relay does not appear to connect directly to the micro controller (it is used to power the board).

On the Phenom, there is a rare earth magnet in the safety switch.  When the switch is rotated to full auto, the magnet activates a relay to power on the board.  I'm not sure how an APE board is powered on for the x7.  It's possible that their board has another relay to sense the mechanical safety-switch position as well as full auto.  In other words, this may not be possible for the x7 or Phenom without modifying the hardware on the board.

There are three electromagnetic relays on the X7C board. Two are on adjacent opposite positions on both sides of where the trigger magnet is situated on a trigger pull, while one is situated on the other side of the board, outside where the magnet in the safety switch "wing" positions itself if you flip it one more step into the programmed mode (for the Phenom, where the electronics kick in).  I'm fairly confident, after bending the two mirrored relays a bit back and forth, that they are essentially giving the same information to the controller. Perhaps there is two of them because of redundancy, or polarity sensing limitations. The safety switch relay is only on one side for obvious reasons. Do you have any insight into the mechanical mode and how it is relayed?

Edit: Well now I feel stupid. Of course the mechanical mode is not relayed, that's the entire point.  :smiley-roll-blue:
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: bag06a on Jun 30, 2012, 03:38 am
I'm wondering if the two sensors are for when the gun is in response mode. To me it makes sense; pull the trigger and one/both get flipped, but while the trigger is in ge pulled position, even if for just that brief second it then senses when the second one gets flipped on th way out to trigger the solenoid?

Jus a theory, plausible theory IMO too.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Cainxxx on Jul 26, 2012, 01:59 pm
What's happened with the wiki page?
http://code.google.com/p/phenomx7-etrigger/w/list
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jul 26, 2012, 02:49 pm
Thank you for pointing this out.  There was a problem with the google code source repository.  I've repaired the issue and the wiki should be back.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Laggard on Jul 27, 2012, 03:45 pm
I got my USBASP programmer yesterday after 23 days waiting. Of course this happened during the time the wiki was down haha. I successfully programmed one of the spare ATTINY44 chips using WinAVR though; now I wonder if there's any way to test it. Do you have a picture or schematic for a test bed breadboard? If not, don't sweat it. I'll have to study the x7 chip to figure out differences with the Phenom anyway. Also, would upgrading to an ATTINY84 have a significant impact on anything?
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jul 27, 2012, 04:59 pm
Yeah, I'm sorry about the wiki.  I was trying to switch over the source code repository, but apparently google does not auto transfer what was already on the site.  I'll attempt the switch again eventually, but not for a while.

I've attached a schematic of a test breadboard that should work with our programming for the Phenom.  I need to make a few changes to it for the original Tippmann chip (it requires more pins to be pulled-up/pulled-down than my firmware), but this test breadboard should work just fine for our firmware.

The ATtiny84 is a drop in replacement for the ATtiny44 (pinouts are the same, clock is the same, etc.).  The ATtiny84 provides 8k of memory versus the 4k on the ATtiny44, but other than that, it's the same chip.  I would love to grow the firmware with additional options that I'm currently unable to fit on the ATtiny44 due to the smaller memory, but I want to keep the firmware small enough so people can use it on stock versions of the board (no soldering required).

If you do plan on soldering in a new ATtiny84, perhaps we should branch the source code for this firmware and start adding features.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Laggard on Jul 28, 2012, 02:28 pm
Thank you for the schematic, very clear and helpful. It would only take one more resistor to add a switch (the safety switch electromagnetic relay), correct? I've only ordered 10 which should be here shortly. Which pin does it use on the Phenom?

I could solder on an t84 right away if I thought I had the skill. Maybe I can ask a friend to help me though. What functions were you thinking of, more firing modes or more refined logic?  Originally, I envisioned an I²C library to have it connect to other devices such as a display and scroll wheel. Crazy, I know. I shelved the idea when I realized it would probably severely impact battery life and reliability.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: mikedehaan on Jul 28, 2012, 05:50 pm

It would only take one more resistor to add a switch (the safety switch electromagnetic relay), correct?


The safety switch relay does not connect directly to the ATtiny44.  Instead, the relay controls the power to the chip Vcc (Pin 1).  To simulate this on the breadboard, I just plug and unplug the power source.


What functions were you thinking of, more firing modes or more refined logic?


A mixture of both.  The stock board has the ability to detect low voltage from the battery and indicate that the battery is low to the user.  I have not finished researching this, but I don't really have the space for it on the chip either.  It was that or presets.  For firing modes, I don't have any ramping.  I would like to include some version of it.  I'm trying to optimize the code a bit (without going to assembly) and might be able to make room for one more firing mode (fingers crossed).


Originally, I envisioned an I²C library to have it connect to other devices such as a display and scroll wheel. Crazy, I know. I shelved the idea when I realized it would probably severely impact battery life and reliability.


Crazy?  Absolutely!  But we're all a little crazy.  We've had similar ideas about adding peripherals (kill counter, ammo counter, ...).  For this, I think we would include a separate enclosure with a picatinny mount so it could store a separate battery for itself, and link up to the stock board with a cable tied to the pinouts (drawing as little current as possible to get the job done).  I'm not a hardware guy, but I think this is possible.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Laggard on Jul 28, 2012, 09:51 pm
The safety switch relay does not connect directly to the ATtiny44.  Instead, the relay controls the power to the chip Vcc (Pin 1).  To simulate this on the breadboard, I just plug and unplug the power source.



This is true but I would need to include a separate switch in order to customize the code for the X7 classic. The relic requires being powered by pressing the programming button, and programming mode is only entered if you activate the board with the trigger pulled. The electromagnetic relay would only serve as a precondition for alternate firing modes to be activated, as the board being powered but the relay untriggered constitutes a separate, electronic, semi-automatic firing mode. This might be a problem, considering the limited available memory space.


A mixture of both.  The stock board has the ability to detect low voltage from the battery and indicate that the battery is low to the user.  I have not finished researching this, but I don't really have the space for it on the chip either.  It was that or presets.  For firing modes, I don't have any ramping.  I would like to include some version of it.  I'm trying to optimize the code a bit (without going to assembly) and might be able to make room for one more firing mode (fingers crossed).



I could possibly buy another stock board for my Phenom, to experiment with the t84. Then I would be less likely to get bruised up like seven hells if it spazzes out. I'm game. Give me a couple weeks though.

Crazy?  Absolutely!  But we're all a little crazy.  We've had similar ideas about adding peripherals (kill counter, ammo counter, ...).  For this, I think we would include a separate enclosure with a picatinny mount so it could store a separate battery for itself, and link up to the stock board with a cable tied to the pinouts (drawing as little current as possible to get the job done).  I'm not a hardware guy, but I think this is possible.



Haha I never thought of that. A separate device with its own power supply would be great, if it means the etrigger device works independently of the battery condition of the peripheral. Potentially this could be a total conversion awesomification set to make your Phenom a goddamn Starship Troopers space gun to distinguish it from that there gaggle of "normal" space laser guns.
Title: Re: Dumping firmware/software...and/or reflashing??
Post by: Cainxxx on Sep 14, 2012, 01:24 pm
anyone experienced this problem? (unwanted auto cycle trouge all presets)
http://code.google.com/p/mad-phenom/issues/detail?id=2