On Thu, Jan 14, 2010 at 12:16:59AM -0800, David Brownell wrote: > On Wednesday 13 January 2010, ?yvind Harboe wrote: > > Seing that avr is not at the level of an "official feature" I don't have > > a problem with merging this work in progress as it does not affect > > any other code. It can probably be refactored easily enough. > > > > Meanwhile we can "measure" how much interest there is openocd > > + avr w/some crude support... > > A minor goal of mine was to throw OpenOCD at some AVR chips (AVR8 > and AVR32) before 0.4 ships to see how it all behaves... assuming > I get around to that, it'll be with this patch included.
Thanks. Do you think it worth introducing additional custom avrf commands for reading flash and eeprom with the documented jtag commands? I'm sure memory-mapped way will not work in the nearest future and having any way to dump current firmware would already be nice (to at least verify the flashing). Probably also some tcl script can be added to automate flashing/verifying process, especially considering the fact that windows doesn't have tools to e.g. strip tailing 0xFFs before file comparision. > > Perhaps there will be some feedback on minor things to change, > > perhaps use size_t i for iteration variable instead of uint32_t i... Well, that was just a copy-paste of the code which already was there for flash. I assume the intention of the original author to use the same type for "i" as he used for the upper boundary in the "for" cycle. > At some point it would be nice to sort out the various JTAG ops > on AVR8. As I recall, they document only the ones used to write > flash and EEPROM, and perform boundary scan. Whereas: Also "fuse settings" (which are important enough and for most devices need to be changed from the default) and reading all of those back. > The On-chip Debug support is considered being private > JTAG instructions, and distributed within ATMEL and to > selected third party vendors only. > > Clearly, someone needs to throw a JTAG/SPI sniffer at some of the > transactions issued by AVR studio, and so some "reverse engineering > for interoperability". :) Luckily someone already did that, see [1] (they used Free AVR ICE to sniff). [1] http://mirrors.igsobe.com/nongnu/freeice/AVR-OCD-Documentation.html -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
