Here’s a nice little discussion about reading and writing AVR flash memory that [Windel] put together. He’s using an In System Programmer to read the flash memory from an ATmega328 using AVRdude, the programming software which we used in our AVR Programming Tutorials. He covers the particulars of the commands, how this might be useful, and finishes up with the gotcha’s involved in reading back code from the chip. We recently tried this out with that LED light bulb but were unsuccessful because the lock bits on the ATtiny13 chip had been set in order to protect the firmware from our prying eyes. Hopefully you’ll have more luck with these methods.
Hey speaking of AVR flash… does anyone have experience writing to the flash of e.g. atemga32 from application memory? apparently, you have to make a function to write, save it in the bootloader portion of memory, then call to it from your application. Does anyone have any examples of this? It will help a great deal here. Thank you.
Why is this post not showing up on the front page anymore?
avrs are not arduinos, and sketch is not a replacement name for firmware.
@bluewraith it is for me atm
@dioxide wrong thread d00d?
Another question: does anyone know how to read the compiler output files to find out where a particular variable would be stored in flash?
e.g. if you had a sample in an array in a piece of software and you wanted to ONLY overwrite the piece of code in a particular spot?
no, looks like the right thread to me.
of course, youd have to actually read the article for my comment to make sense.
Nice, perfect timing for my adventures in iClicker hacking. They use an ATmega8, have 6 pin ISP header, and no lock bits set :)
Since the arduino madness startet, people started writing articles about simple basic stuff about microcontrollers like they have discovered some great thing.(like using a vref pin… or this).
I understand, it is for people who have nothing to do with microcontrollers and if the vref article does indeed have some info in it… i see nothing useful in it.
If you have problems losing files, use a version control software and backup.
Haters gonna hate
“lock bits on the ATtiny13 chip had been set in order to protect the firmware from our prying eyes”
couldnt a ATtiny13 based chip be used to protect video games from copying?
go back to the 80’s and make cartridge based games.
inside the cartridge would be a board with a ATtiny13 chip containing the game’s code done in vector to minimize filesize, midi for the music notes and only real samples for the instruments and real samples for the voices?
yes it would make them more prone to failure due to bad contacts (remember the problems with nintendo?)
the companies could be able to protect the content better because of the lock bits.
a possible way way around the space limitation of cartridges are to use in combination with cd or dvd.
cartridges for the game code and cd or dvd for the sound andskins that are applied over the vector wire frams (most people want to copy the entire game not the images and sounds and music (unless there is a specific image or song))
@bogdan
Yeah, let’s just publish articles that only engineers can understand, and f*** DIY spirit.
NOT.
Are you afraid of some guys knowing what a VRef pin is ? Wanna keep knowledge for an elite ? Why are you even posting here ?
@ejonesss: First, you have no idea how game consoles work. Nor how game copy protection works.
Secondly, you underestimate the hackers.
Read this: http://www.fpgb.org/?page_id=17
And this ‘article’ disappoints me. This is very basic stuff. If you name something “The facts about flash memory” I kinda expect the following:
-Amount of write cycles.
-How to do self programming (bootloaders) in different types of chips. The ATMega only supports self programming from the “bootloader” area, while the ATTiny supports self programming from any address.
-I expect things like sector sizes, low level ISP commands.
If you really want to know a bit more about the flash in the AVR chips, then open the datasheet of your chip, and goto the chapter called “Boot Loader Support Read-While-Write Self-Programming”
And the chapter “Memory Programming”
I remember having trouble porting my bootloader from atmega64 to atmega128 because of the 16-bit addresses. I have one reserved block in my bootloader at the end that contains the flashing code in case I wanted to update the bootloader itself. The bootloader starts with a check of the fusebits too. Does some CRC calcs and simple symmetrical encryption. Would have been better if I weren’t using all 8KB yet :/ (yeah of course I could extend to app area at some point…)