Question on max flashes, Ponyprog, Clock Src

I have recently purchased an AVR MT 128 and am having a great time learning more about it and working with it.

I have a few questions for those experienced with the AVR and PonyProg.

  1. What is the practical maximum number of times I could expect to flash an AVR device before it would die (just like all flash memory has a write cycle limit)?

  2. On Ponyprog is there a way to skip the verify cycle? When flashing an Arduino or even the AVR butterfly the flash happens quickly with their tools (AVRStudio and Arduino’s IDE) and it doesn’t appear they verify because within a few seconds, including programming, it’s ready to go.

With Ponyprog and the AVR MT 128, the programming is equivalently fast, but it goes through a very lengthy verifying cycle which severely limits how fast I can turn around changes. Is there a way anyone knows of to just program it and not worry about the verify? Is that a bad idea?

  1. Finally, I understand on the AVR MT 128, despite the fact that it comes with a 16MHz clock, it’s probably running at 1MHz (or 2Mhz, not sure, due to the /8 prescaler that is apparently factory default in AVRs.) First, is this assumption correct?

3a) Is there a procedure someone can point me to which will show me how to crank this up to its full clock rate? Specifically, someone who’s done it with the AVR MT 128 would be ideal but if it’s a standard procedure for all AVRs, all the better. I’m a little gun-shy as I’ve read other posts here and elsewhere of people jacking up their AVRs by hosing up the fuses, then needing to clock it externally to revive it. I’d obviously like to avoid that if at all possible.

3b) In relation 3a) I should be getting the AVR JTAG programmer from Sparkfun today sometime, so if doing fuses and setting clock sources takes JTAG, I should have what I need to do it. Mainly, looking for a bullet proof procedure specific to AVR MT 128 if possible.

FYI I’m running the latest WinAVR tools…Programmers Notepad 2.0.5.48 and associated tool-chain if that matters to any responses people have.

The AVR data sheet will tell you how many program+erase cycles the part is specified to be able to take. Usually it’s around 10,000-100,000 for program flash and 100,000-1,000,000 for data flash. Speaking for myself, as a hobbyist, this translates to “more cycles than I’m going to put this part through, ever, so I won’t worry about it”.

FYI - In some of my research on tutorials for setting AVR fuse bits, this was one of the best I have come across:

http://www.scienceprog.com/programming- … -settings/

The above had some PonyProg specifics and screen shots.

There’s also this one:

http://electrons.psychogenic.com/module … OGuide.php

Before I burn mine, I may want to get a couple of double checks from you guys first. I’ll get it set, then take some screen shots for verification.

landon:
2) On Ponyprog is there a way to skip the verify cycle? When flashing an Arduino or even the AVR butterfly the flash happens quickly with their tools (AVRStudio and Arduino’s IDE) and it doesn’t appear they verify because within a few seconds, including programming, it’s ready to go.

With Ponyprog and the AVR MT 128, the programming is equivalently fast, but it goes through a very lengthy verifying cycle which severely limits how fast I can turn around changes. Is there a way anyone knows of to just program it and not worry about the verify? Is that a bad idea?

To answer another question I had earlier, the PonyProg progress bar dialog has an “Abort” button on it which can be used during either programming or verifying. I poked in during verify and it immediately stopped and put up a “write failed” alert box, but the actual write had already occurred and is normally just fine. So, while the warning is dire and it’s not really an intuitive interface (I’d rather just have a preference that says “don’t verify”), it does work to abort. I could turn around builds a lot faster by aborting the verify.

Pics.pdf (357 KB)

I could turn around builds a lot faster by aborting the verify.

I would suggest letting the verify complete for the first programming attempt of the session, then abort the rest of them. It could cause considerable pain if you think it’s programming it when in fact it isn’t.

This is what I do…just a thought.