[Openocd-development] [PATCH] add imx31pdk board
Please find patch attached. Regards, Alan addimx31pdk.diff Description: application/mbox ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] add ledtest to imx27ads board
Committed. Thanks! -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] add imx31pdk board
Committed. Thanks! -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] debugging on a lpc2468
Hello, I am new with openocd and I am trying to debug a demo program on a board with an lpc2468. I have created a lpc2468.cfg file based on lpc2294.cfg on svn. I am debugging from gdb (without any gui). I can run the program with cont and stop it with ctrl-c. Then I try to set a brekpoint or run step by step and then I have the problems. step command in not working and if I set a breakpoint I can use cont one time, and one time will not work. the error is always the same one: I receive 2 warnings in openocd window: Warn : memory write caused data abort (address: 0x03a4, size: 0x4, count: 0x1) Warn : memory write caused data abort (address: 0x03a4, size: 0x4, count: 0x1) and the same message in gdb but only one time and without the Warn :. To start the openocd I used the following command: sudo ./src/openocd -f src/target/interface/openocd-usb.cfg -f src/target/target/lpc2468.cfg openocde-usb.cfg is from the svn revision 1315 and lpc2468 is attached to the mail. any idea? Thanks and Regards, Mariano.- lpc2468.cfg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 1.0 or 0.1?
I agree that we shouldn't lose momentum on doing a release. My failure to make oocd a standard part of my tools so far has had a lot to do with the moving target of the config files (as well as time cognitive difficulties ;) Supporting the 'biggies' (ARM7 - NXP, Atmel, ST, M3 - Luminary, ST) cleanly seems like a good release point regardless of what we're calling it - might please most of the people most of the time. x.y.z is fine with me. Steve On Wed, Jan 14, 2009 at 12:55 AM, Rick Altherr kc8...@kc8apf.net wrote: On Jan 13, 2009, at 11:35 PM, Øyvind Harboe wrote: The difference between 0.1 and 0.7 is entirely in perception. The version numbers are effectively arbitrary since we have never made any other versioned release. If we are going to use 0.x (the two responses I got have both suggested that path), we might as well start with the beginning of the minor version number space (0.1) rather than an arbitrary point in the middle. You're contradicting yourself. You say that the version # is about perception, then you say that 0.7 is arbitrary. The two are not mutually exclusive. Since there have been no versioned releases, the first number is entirely arbitrary since we need to pick a number but it has no meaning within the project itself. But it also means that users will perceive a meaning based on comparisons to other projects. 0.7 indicates 70% done to me. Very much workable, but not a finished product. Sure, but 0.1 can just as easily indicate the first release that we feel is acceptable for users to test. The number has no intrinsic meaning at this point since it is the first one. Any meaning attached to the number isn't likely to make any sense to a general user. In fact, choosing something like 0.7 could just as easily cause more confusion than confidence. Someone will ask where versions 0.1-0.6 are. Saying we chose 0.7 because we wanted people to have more confidence that it was stable or because we wanted to give the impression that it was close to a 1.0 feels like an attempt to mislead. A JTAG debugger is 100% done by the time it is obsolete, so it is a product, unlike others that *must* and *should* be used before it is finished. Every software project suffers the same fate. There are always new features to add, bugs to fix, and better architectures. Version 1.0 doesn't mean a project is done, just that it has reached a point where it is good enough for general use. Otherwise, Microsoft Office wouldn't be working on version 14.0. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svf support
2009/1/16 SimonQian simonq...@simonqian.com: I've finished parsing SVF file and added it to OpenOCD. telnet to OpenOCD, and run svf filename.svf. With -d3 option, more information about parsing the SVF file will be outputed. Below are commands correspond to a jtag operation: 1.TRST -- control TRST line call jtag_add_trst ... OK 2.STATE -- statemove or pathmove call jtag_add_pathmove if path is defined ... OK eg: STATE DREXIT2 DRUPDATE DRSELECT IRSELECT IRCAPTURE IREXIT1 IRPAUSE; But, I can't find jtag_add_statemove ... CALL WHO? eg: STATE DRPAUSE 3.RUNTEST -- runtest at stable state call jtag_add_runtest ... OK 4.SIR and SDR -- scan ir/dr call jtag_add_plain_ir_scan or jtag_add_plain_dr_scan ... OK 5.FREQUENCY -- set jtag_speed call command_run_linef(cmd_ctx, jtag_khz %d, speed_khz); ... OK My question is how to call statemove in command STATE? Use: jtag_add_pathmove Attachment is the log file showing how the SVF file is parsed. 2009-01-16 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
