Hi folks, I'm working with the AVR platform and have a device that I can only program using JTAG. For this reason, I'd like to get the AVR support in OpenOCD a bit more further along. As far as I can see, only writing the flash is supported. I'm interested in also reading flash and reading/writing fuse bits, eeprom, lock bits, etc.
I'm happy to write some code for this, but I'm not sure what the proper way to implement some of these is. Regarding the reading of the flash. I understand that the normal procedure is to just use the regular memory reading commands of the target, instead of specific reading code in the flash driver. However, for AVR this poses two challenges: - There is no on-chip debug support (and it's not easy to implement, since the JTAG protocol for that is not documented by Atmel). So there is no way to read arbitrary memory right now. - Even if there was, AVR uses separate program flash memory and data ram, both in a separate address space. There is no standard way to map them in a single address space. I can imagine a separate flash reading subcommand, but then you'd have to implement subcommands for reading bytes, words, reading into a file, etc. in the flash driver, which seems like double work. In the flash drivers, there is already a "read" function defined, but most of the flash drivers forward this command to the target driver instead. Additionally, if I'm grepping the sources correctly, this function is only used by the "flash fill*" commands, there is no other way to access them. Would it make sense to somehow define multiple address spaces and to pass the address space to use to the md* and dump_image commands? Regarding the reading and writing of the fuse bits, lock bits, signature bits, etc. I guess the most obvious way here is to just add specific flash subcommands? Something like the "lpc2900 read_custom" command? Or is there a better way? The atmel specifications define that the JTAG commands to work with the flash can only be used when the CPU is in reset mode (and additionally defines a JTAG command to put the CPU in reset mode). Now I think the avr target should contain code to reset the CPU using this JTAG command, but whose responsibility is it to reset the chip when reading flash? Should the flash driver handle this automatically, or should it only flag an error to the user and let the user handle reset instead? Looking more closely, there is actually some related code already. The target is already put in reset through the JTAG command for that when entering "programming mode" (which is a AVR-specific JTAG command) and is removed from reset when leaving programming mode. However, it also checks if the target is halted, but I don't think there is currently any meaningful way to halt a target. There is some code in the avr target code that AFAICS just sets the state to halted without actually doing anything, but I'm not sure how to trigger that code (and if it doesn't actually halt the target, is there a point in requiring the target to be halted?). Addtionally, I tried to generalize the atmega128.cfg into a atmega.cfg, which can be included by specific configurations. Like with other configs, I put "set CPUTAPID 0x3950b03f" in the specific config and pass that value to -expected-id in the general config. However, I'm not sure how to handle the case when there are multiple possible id's? For AVR chips, the version part of the id is set to the hardware revision, so it's likely that that same chip will be encountered with multiple id's. How would you handle this in a generic setup? Add "tap configure -expected-id another_id" after sourcing atmega.cfg? I could also imagine the specific config setting only the "device id" part and then the generic config adding the manufacturer id and a few hardware revisions (just a fixed number, or up to a maximum defined by the specific config perhaps)? I couldn't find anything like this in the other configs, though? Gr. Matthijs
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
