Self-Destructing arduino code

Yeah the EEPROM doesn't change unless you specifically write something else to it. It also stays even when you turn off the power.

The EEPROM on the atmega328p (and most AVRs) is good for around about 100 000 writes. That's probably not going to be a problem for you. The main flash memory of the chip, incidentally, is only good for approximately 10 000 writes. One of my next projects is going to be an "EEPROM destroyer", to see how many cycles I can get out of this thing! Some videos I've seen have gotten about 120 000 writes!

Thanks for all the replies,the EEPROM looks like the thing i need, i will get into it and keep you posted!

Oh one mroe thing im wokring with a teensy 3.0 with a

MK20DX128

32 bit ARM

Cortex-M4

48 MHz

and the EEPROM is 2048, i dont know how many writes i have, but it shouldn't be a problem, right?

No problems at all! You have 2047 more addresses than you need! Don't worry about how many writes you have either, for your application it doesn't really matter. When you get into data-loggingy stuff then it becomes an issue.

Thanks Mark, that's good to know. I had done a quick search and I must've gotten something outdated or just wrong

So that would mean dirtdiver would just need a separate sketch to clear the one memory address he is using as the flag.

Interesting point about the legal side of it. I once put a time limit on a custom app, requiring a typed-in key to unlock it, and I'm pretty sure I would not have gotten paid without it!

dirtdiver, In terms of the number of writes available, you would only write the one memory location once per self-destruct button press. Or if the trigger is time related I suppose you could check it before writing so you don't re-write it unnecessarily.

See...I told you...EEPROM way is the best...!!

dont bother abt write cycles, you just have to read the values continously to keep ur sketch active.

yes in terms of number of writes available i will be OK, and as far as the legal side goes im not selling this im getting involved in a partnership, and the club is not mine so whats stopping the guy from saing thats his, i have no way of proving that i made the simulator and like i said i can gain leverage when i simply render the teensy useles. (I am also thinking about patenting the simulator but im not sure how to do that or what will the cost or time be like)(The other possibility is a contract which i will look into)

Anyway thanks for the help,i will keep you posted on my progress!

Don't patent it!

I tell you, it's a waste of time, money and effort. You need to pay thousands of dollars, and here's the worst part: you have to publish a detailed description of your product and how it works! You're just making it a hundred times easier for some el-cheapo manufacturer to copy it! They won't care if you have a patent. If you do decide to sue someone over copying it, then that's going to set you back quite a bit for a lawyer! There's no way, even if you win, that you'll get that much money back from the patent.

If you decide to sell it (perhaps on a large scale) then there are precautions you can take to stop people from copying it. For example, you could get a custom PCB built for it, and sandpaper off all the markings on the ICs. If and when you decide to go big, then maybe a patent might be feasable. Also, if you don't really care about the money, and just want to get recognised, a patent might be a good idea, even now. Just know that you'll be paying a LOT of money for it. Think of how many goodies you can get on this website for $5000!

---

Also, @Sunil, the EEPROM method may not necessarily be the best way. In fact, there may not be a 'best' way at all. It's one way of doing things, and it seems feasable. It all depends on what the kill switch is for, how much effort you are willing to go to write the code, how good you are at coding, your time constraints, etc, etc, etc. This kill switch idea is good, but I can see it causing some disputes. A dedicated self destruct button will tick off the club owner much more than a simple discreet reset switch (which by the way, is not analogue as you mentioned before - analogue refers to a range of voltages in this case, the reset switch still uses digital logic), and you can still use the switch for leverage. Just tell the guy you need to take it for 'servicing' and secretly flip the switch while pretending to calibrate stuff, and give him a long technincal explanation as to why it went bust, like "the internal temperature of the dual H-bridge stepper driver rose too far beyond the nominal". He won't know you designed it for leverage (which I'm sure will make him mad and ruin the partnership), but he will know that only you can fix it, which gives you the leverage. Also it requires no extra coding. In addition to this, constantly checking the EEPROM might be quite taxing to the microcontroller, especially since it's doing a LOT of other work - this simulator is pretty complex! You might find that it decreases performance. This might be in the form of jittery servos for example - even with simple programs, if the MCU is checking constantly for, say, a timer value, then the servo just freaks out and goes all over the place! You could optimise this out using interrupts and all that but that just adds to the complexity of your program!

Again, this is also just one way of doing things. It may or may not be better than the EEPROM method, but it's up to dirtdriver to decide

Rahul

Someone in the Arduino.cc forums did a self destruct, by writing and then reading the address.

The 10/100k write is the MINIMUM the manufacturer guarantees it will work for.

I think (hazy memory) it was more like 1m write cycles he got.

Anyway as everyone has posted, it only needs to be written once.

dirtdiver

You can run the button check routine as an interrupt, or whenever you read other inputs.

This would clear the EEPROM (or write to it) and on next powerup, when it checks.......

To make it look genuine, after the 'self destruct', you could always make it do a loop that looked like it 'booted' up then died and repeated.

"Genuine failure mate, probably something inside the micro .....I can fix it, but btw about that account..."

I have been known to remove the chip identity by sanding it off, when we didn't want it reverse engineered.

Black spray paint, or encasement in rubber solution or epoxy (with glass) is also frustrating.

Mark

@Rahul,,

yeah i am agreed to you , I just told that Reset pin is too much a easy way to stop execution of the microcontroller for that complex machine.

sure continously reading the EEPROM values sometimes may delay in response and surely it will impact the servo one day theoretically...but so far now I have not seen such a case yet..May be i have to do some more EEPROM stress analysis.

What if we mount a small RTC IC (DS1307) and read the EEPROM values after a specefic period of time say once in 2 days or 4 days etc...coz that will surely give the chip some time to relax. And if the value is not there after 2 days...Simulater will shutoff...!! until unless the value is not saved in it again.

DS1307 can last upto 5yrs approx with a single coin cell and we can detect from the Arduino or any other Microcontroller wether RTC is running or not, just incase if somebody plugs out the cell from it and make our program much stable and secured with it...

Yeah, thats what i heard about the patenting too, so its out of the game,

also im not worried about reverse engineering couse all they are going to see is the teensy the code in it cant be extracted as far as I know (it can but it will be all messed up and not full- it will be pretty useles)

I have a friend lawyer, i will talkmto him about a shor contract declaring that i have rights over the simulator or something similar i dont know yet .

Im not a good programer,as you can see from the simulator i dont have that kind of money to fool around with , i dont have much time,I will try the EEPROM (at least for the educational purpose of it , but if it slows down the program, then i wont use it)