Re: [Openocd-development] Adding support for SST 39VF6401B externalflash
Hi All, I am not sure I am doing this correctly, But here are the required patches to support the device in subject. It is patched against 0.4.0 using beyond compare as I do not use git. Hope someone can make it part of official code as it has been working for almost a year now on my system. Thanks in advance. Regards Flemming -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Flemming Futtrup Sent: 14. januar 2010 09:01 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Adding support for SST 39VF6401B externalflash Hi all, It works! This was a simple matter of using auto erase with the flash. flash write_image $IMGFILE 0x8000 became: flash write_image erase $IMGFILE 0x8000 I am not sure I understand why but it works. I will create a patch containing the changes mentioned in my first message, when I get the time(unless someone else is eager to do so). With DCC+Amontec-tiny I can download at 43 kbps (4 MB in 90 seconds). Thanks for all the support anyway. Regards Flemming -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Michael Schwingen Sent: 31. december 2009 10:40 Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Adding support for SST 39VF6401B external flash David Brownell wrote: FWIW that Sparkun forum is only moderately obscure. It's the one Olimex points its customers to, and we mention it as a User's Forum in our documentation. Interesting - I did not even know about it until this thread. Do we really want to point users to a forum where the developers do not read about the problems? (In general, I refuse to read web forums except when pointed to an explicit thread. I do not bother to regularly check forums because keeping track of already-read parts combined with the lack of threading makes them a PITA). cu Michael ___ 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 sst39vf6401b.patch Description: sst39vf6401b.patch sst39vf6401b_2.patch Description: sst39vf6401b_2.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Amontec jtagkey2 OpenOCD on Windows error : Cannot build run test program using ftd2xx.lib
On Wed, Sep 15, 2010 at 1:42 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Sep 14, 2010 at 12:57 AM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Mon, Sep 13, 2010 at 4:38 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Download our new Amontec JTAGkey Driver from : http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip Hi Laurent, thanks very much. I can confirm that with this drivers it is compiling and working fine. Good to hear that. Are you saying that you do not need to do anything to the FTDI library file to build openocd_d2xx? Yeap, exactly. It builds with ftd2xx, not with ftdi library. Last time I needed to do something to the FTDI driver (maybe older version) to solve the Cannot build run test program using ftd2xx.lib problem. *** http://forum.sparkfun.com/viewtopic.php?t=17598 Well, I have seen this problem before, with old drivers (the ones I first downloaded). With new drivers Laurent pointed to it works with no problems. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] U-Boot on PXA 320
Dne St 15. září 2010 13:28:56 Moshe Artzi napsal(a):
Thanks for your fast reply,
I invoked those commands and on both commands I get the same error message.
Copy paste from the telnet console:
reset halt; load_image iplntim.bin 0x5c04; resume 0x5c04
JTAG tap: pxa3xx.cpu tap/device found: 0x6e642013 (mfg: 0x009, part:
0xe642, ver: 0x6) BUG: can't assert SRST
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x08d3 pc: 0x
MMU: disabled, D-Cache: disabled, I-Cache: disabled
(processor reset)
1472 bytes written at address 0x5c04
downloaded 1472 bytes in 0.015625s (92.000 kb/s)
Failed to receiving data from debug handler after 1000 attempts
Command handler execution failed
in procedure 'resume' called at file command.c, line 650
called at file command.c, line 361
reset halt; load_image u-boot.bin 0x5c04;resume 0x5c04
JTAG tap: pxa3xx.cpu tap/device found: 0x6e642013 (mfg: 0x009, part:
0xe642, ver: 0x6) BUG: can't assert SRST
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x88d3 pc: 0x
MMU: disabled, D-Cache: disabled, I-Cache: disabled
(processor reset)
205620 bytes written at address 0x5c04
downloaded 205620 bytes in 1.00s (200.801 kb/s)
Failed to receiving data from debug handler after 1000 attempts
Command handler execution failed
in procedure 'resume' called at file command.c, line 650
called at file command.c, line 361
There was something similar on OpenOCD mailing list, CCing.
Check Re: [Openocd-development] PXA question in their mailing list archive.
btw. I have this weird hack applied on my openocd, but it's certainly incorrect
:) It helped me with some issues some time ago:
diff --git a/src/target/xscale.c b/src/target/xscale.c
index 7cdff21..45e5b9a 100644
--- a/src/target/xscale.c
+++ b/src/target/xscale.c
@@ -759,6 +759,7 @@ static int xscale_update_vectors(struct target *target)
}
else
{
+ continue;
retval = target_read_u32(target, 0x + 4*i,
xscale-high_vectors[i]);
if (retval == ERROR_TARGET_TIMEOUT)
return retval;
@@ -778,6 +779,7 @@ static int xscale_update_vectors(struct target *target)
}
else
{
+ continue;
retval = target_read_u32(target, 0x0 + 4*i, xscale-
low_vectors[i]);
if (retval == ERROR_TARGET_TIMEOUT)
return retval;
Seems like the download process failed
any ideas what can cause this failure ?
Thanks,
Moshe.
-Original Message-
From: Marek Vasut [mailto:marek.va...@gmail.com]
Sent: Wednesday, September 15, 2010 12:34 PM
To: Moshe Artzi
Cc: Gena Chap; openpxa-us...@lists.sourceforge.net
Subject: Re: U-Boot on PXA 320
Dne St 15. září 2010 12:18:58 Moshe Artzi napsal(a):
Hi Marek, thank you for your reply,
I decided to go with the OpenOCD solution you suggested me,
I got OpenOCD working and I'm able to communicate with the flash memory
and cpu using the jtag by telnet.
But now the command nand list is not working so I can't perform the
probe command in order to nand (flash) The PXA 320 Memory with the
iplntim.bin and u-boot.bin,
Well, load iplntim.bin into SRAM and execute it. (reset halt ; load_image
iplntim.bin 0x5c04 ; resume 0x5c04).
Then load uboot the same way (reset halt; load_image uboot.bin 0x5c04;
resume 0x5c04).
Between these two steps, you must not power-cycle the board. Once done,
uboot should appear on the screen. Then you can reflash using uboot.
To download the files faster, run this in openocd right after uboot is
running:
halt; load_image iplntim.bin 0xa000 ; load_image 0xa002 ; resume
And then in uboot:
nand scrub ; nand erase 0x0 0x6 ; nand write 0xa000 0x0 0x6
Should work.
Also please keep CC so people wont go asking me this question again and
again
Are there any steps I have to perform before invoking the nand list
command?
Any help will be appreciated,
Thanks a lot,
Moshe.
-Original Message-
From: Marek Vasut [mailto:marek.va...@gmail.com]
Sent: Tuesday, September 14, 2010 10:47 AM
To: Moshe Artzi
Cc: Gena Chap; openpxa-us...@lists.sourceforge.net
Subject: Re: U-Boot on PXA 320
Dne Út 14. září 2010 10:24:45 Moshe Artzi napsal(a):
Hi Marek,
Hi,
I'm Moshe - S/W engineer
I'm using Toradex Colibri PXA 320 CPU on Colibri Evaluation Board Rev
.2.1.
I'm trying to run the U-Boot version,
After I'm flash the Memory with the files iplntim.bin(in address
0x) and u-boot.bin(in address 0x0002),
according to the ReadMe file, the U-Boot
Re: [Openocd-development] Adding support for SST 39VF6401B externalflash
Great:-) -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: 15. september 2010 11:40 To: Flemming Futtrup Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Adding support for SST 39VF6401B externalflash Pushed. Thanks! -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 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] Amontec jtagkey2 OpenOCD on Windows error : Cannot build run test program using ftd2xx.lib
For end users, I will recommend to use the libusb-win32 inf-wizard. It is very easy to go through the wizard process and install libusb-win32 device driver for the USB Jtag debuggers like FT2232x based device, J-Link or R-Link. By default, it will list USB Composite Device (like FT2232x) as two device, so that you can choose to install the libusb-win32 device driver for Interface 0 (Ch A) only and keep the existing FTDI driver for Interface 1 (CHB) if it is used as a virtual serial port. inf-wizard: inside libusb-win32-src-1.2.1.0.zip http://sourceforge.net/projects/libusb-win32/files/ It has built-in signed binary driver and works under 32bit/64bit Windows. Zadig from libwdi project is another option. http://libusb.org/wiki/windows_backend Yes true, but actually I will recommend to still use D2XX drivers and build your openocd for d2xx driver. Why : D2XX driver is actually still faster than libusb driver on Windows ... D2XX driver is backward compatible with older D2XX ;-), not libusb driver ... D2XX driver allows to have one only driver for JTAG channel and UART channel ... (VCP D2XX), not the libusb D2XX driver has a true compatibility trough OS (windows / linux / mac ) ... D2XX driver is signed and Micrsoft WHQL certified for 32bits and 64bits, not the libusb For the Amontec USB JTAG key dongle series please use the //http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip //Regards, Laurent http://www.amontec.com JTAGkey-2 : Amontec USB JTAG Cable Debugger JTAGkey-3 : Amontec USB JTAG + SWD Cable Debugger // // ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Amontec jtagkey2 OpenOCD on Windows error : Cannot build run test program using ftd2xx.lib
Laurent Gauch wrote: actually I will recommend to still use D2XX drivers and build your openocd for d2xx driver. Why : D2XX driver is actually still faster than libusb driver on Windows ... Do you know why this is? Have you compared also using libusb-1.0, which uses WinUSB.sys? D2XX driver is backward compatible with older D2XX ;-), not libusb driver ... Hm, this would be a problem of libftdi I guess. Do you know if current products use older chips? D2XX driver allows to have one only driver for JTAG channel and UART channel ... (VCP D2XX), not the libusb This is maybe the most significant benefit. But if driver installation can be automated then I don't know if it matters anymore. D2XX driver has a true compatibility trough OS (windows / linux / mac ) ... This is of course also the case for libusb. That, and a straightforward API are IMO the most significant benefits of libusb. :) D2XX driver is signed and Micrsoft WHQL certified for 32bits and 64bits, not the libusb The libusb-win32 driver is signed as well, and I think at least a previous version has been WHQL certified. And for many systems libusb-1.0 can use WinUSB.sys from Microsoft themselves. For the Amontec USB JTAG key dongle series please use the http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip I understand that it is a little too early still, but hopefully libusb becomes a viable alternative for you soon. :) Kind regards //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Amontec jtagkey2 OpenOCD on Windows error : Cannot build run test program using ftd2xx.lib
On Wed, Sep 15, 2010 at 8:23 PM, Peter Stuge pe...@stuge.se wrote: Laurent Gauch wrote: actually I will recommend to still use D2XX drivers and build your openocd for d2xx driver. Why : D2XX driver is actually still faster than libusb driver on Windows ... Do you know why this is? Have you compared also using libusb-1.0, which uses WinUSB.sys? I've tried to use libftdi-1.0/libusb-1.0 with OpenOCD under Linux and it is not faster than libftdi/libusb-0.1 since OpenOCD has not been written to be based on the async API of libftdi-1.0/libusb-1.0. UrJtag developers have done things to improve the performance by using the async API of libftdi-1.0. There was a discussion in the archive of the mailing list. I've also tried to use libftdi-1.0/libusb-1.0/WinUSB under Windows, the result is similar. D2XX driver is backward compatible with older D2XX ;-), not libusb driver ... Hm, this would be a problem of libftdi I guess. Do you know if current products use older chips? One thing is that libusb-1.0 Windows right now does not support libusb0.sys yet. So libusb-1.0 and libusb-Win32 (libusb-0.1) use different driver now. D2XX driver allows to have one only driver for JTAG channel and UART channel ... (VCP D2XX), not the libusb This is maybe the most significant benefit. But if driver installation can be automated then I don't know if it matters anymore. The above is certainly not true. You can install libusb-win32 driver (or WinUSB driver) to one of the JTAG channel and use the FTDI driver for the other channel (for VCP). The inf file Freddie distributes already take care of this. D2XX driver has a true compatibility trough OS (windows / linux / mac ) ... This is of course also the case for libusb. That, and a straightforward API are IMO the most significant benefits of libusb. :) FTDI D2xx driver under Linux is actually based on libusb-0.1. Its performance is also inferior to the FTDI driver under Windows. D2XX driver is signed and Micrsoft WHQL certified for 32bits and 64bits, not the libusb The libusb-win32 driver is signed as well, and I think at least a previous version has been WHQL certified. And for many systems libusb-1.0 can use WinUSB.sys from Microsoft themselves. Some of the vendors supplied WHQL driver for FTDI based JTAG debugger (like FTDI's original VID/PID or Amontec). Other vendors do not have WHQL driver. Vendors can also choose to submit WHQL for driver package based on libusb0.sys or WinUSB.sys. For the Amontec USB JTAG key dongle series please use the http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip I understand that it is a little too early still, but hopefully libusb becomes a viable alternative for you soon. :) Next version of libusb-win32 will provide an easy way to install libusb-win32 filter driver for a specific device (for every individual interface). In that case, the users can still use the existing D2xx driver and then use either openocd_d2xx or openocd_libftdi. Preview of this feature: http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/branches/libusb-testing/src/install-filter-help.txt?revision=343view=markup Test run: D:\work\openocd\libusb-win32-bin-1.2.1.22\bin\x86install-filter.exe install --device=USB\VID_0403PID_CFF8MI_00 libusb-win32 installer (v1.2.1.22) stopping libusbd service.. deleting libusbd service.. stopping devices.. creating libusb0 service.. starting devices.. inserting device upper filter libusb0.. inserting device upper filter libusb0.. D:\work\openocd\libusb-win32-bin-1.2.1.22\bin\x86install-filter.exe install --device=USB\VID_0403PID_CFF8MI_01 libusb-win32 installer (v1.2.1.22) stopping libusbd service.. deleting libusbd service.. removing device upper filter libusb0.. stopping devices.. creating libusb0 service.. starting devices.. inserting device upper filter libusb0.. inserting device upper filter libusb0.. D:\Program Files\OpenOCD\0.4.0\bindir 16/01/2010 10:49 AM 113,211 libftdi.dll 22/02/2010 07:05 PM 1,084,928 openocd.exe (from Freddie, stripped) 13/09/2010 08:47 PM 3,932,272 openocd_d2xx.exe (not stripped, so size is bigger) 3 File(s) 5,130,411 bytes D:\Program Files\OpenOCD\0.4.0\binopenocd -f interface/jtagkey2.cfg -f board/olimex_lpc_h2148.cfg Open On-Chip Debugger 0.4.0 (2010-02-22-19:05) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html RCLK - adaptive jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain Info : max TCK change to: 3 kHz Info : RCLK (adaptive clock speed) Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : Embedded ICE version 4 Info : lpc2148.cpu: hardware has 2 breakpoint/watchpoint units D:\Program Files\OpenOCD\0.4.0\binopenocd_d2xx -f interface/jtagkey2.cfg -f board/olimex_lpc_h2148.cfg Open On-Chip Debugger 0.4.0
Re: [Openocd-development] Amontec jtagkey2 OpenOCD on Windows error : Cannot build run test program using ftd2xx.lib
On Wed, Sep 15, 2010 at 8:12 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Yes true, but actually I will recommend to still use D2XX drivers and build your openocd for d2xx driver. D2XX driver is actually still faster than libusb driver on Windows ... For this reason, right now it is true that FTDI D2xx driver is still better. On the other hand, as per the GPL discussion in this list last time, it is not allowed to redistribute openocd_d2xx. So it is a problem for end users who do not want to build OpenOCD by their own. So Freddie's libftdi based OpenOCD under Windows will still be popular. ;-) BTW, I personally tend to not agree with the assertion that dynamically linking to ftd2xx.dll violates GPL, Many others like Freddie and even the original author do not agree with that assertion either. But that is an issue probably only lawyers can solve. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Amontec jtagkey2 OpenOCD on Windows error : Cannot build run test program using ftd2xx.lib
On Wed, Sep 15, 2010 at 9:27 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Sep 15, 2010 at 8:23 PM, Peter Stuge pe...@stuge.se wrote: Laurent Gauch wrote: actually I will recommend to still use D2XX drivers and build your openocd for d2xx driver. Why : D2XX driver is actually still faster than libusb driver on Windows ... Do you know why this is? Have you compared also using libusb-1.0, which uses WinUSB.sys? I've tried to use libftdi-1.0/libusb-1.0 with OpenOCD under Linux and it is not faster than libftdi/libusb-0.1 since OpenOCD has not been written to be based on the async API of libftdi-1.0/libusb-1.0. UrJtag developers have done things to improve the performance by using the async API of libftdi-1.0. There was a discussion in the archive of the mailing list. I've also tried to use libftdi-1.0/libusb-1.0/WinUSB under Windows, the result is similar. Maybe the reply from libftdi-1.0's developer in the libftdi mailing list can shed some light. -- Forwarded message -- From: Jie Zhang Date: Sat, Feb 20, 2010 at 12:37 PM Subject: Re: libftdi-1.0 for Ubuntu 9.10 To: libftdi AT developer.intra2net.com On Sat, Feb 20, 2010 at 12:21 PM, Xiaofan Chen wrote: On Sat, Feb 20, 2010 at 11:47 AM, Jie Zhang wrote: You need to modify OpenOCD to utilize the async mode to get higher performance. See The commit: http://urjtag.git.sourceforge.net/git/gitweb.cgi?p=urjtag/urjtag;a=commit;h=ad53771377357e1f10206b2916069373fda01122 The patch: http://sourceforge.net/mailarchive/message.php?msg_name=4B70279A.3010307%40analog.com The explanation: http://developer.intra2net.com/mailarchive/html/libftdi/2010/msg00065.html Thanks. Maybe I will forward this to OpenOCD and there may be people who can do that. Current ftdi code in OpenOCD: http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/drivers/ft2232.c;h=82132d3b2d41159eb7974c370ce63a61a74752ff;hb=HEAD Seems it can be done in the same way in ft2232_send_and_recv for OpenOCD. But I have no time and no hardware to do it now by myself. The only USB JTAG cable I have is Blackfin gnICE. Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On 09/14/2010 01:45 PM, Drasko DRASKOVIC wrote: On Tue, Sep 14, 2010 at 10:24 PM, Nived nive...@gmail.com wrote: Hi, i am using openocd 0.4.0 to debug an intelmote2 device. I am able to set a break point and then transfer control to that point. When i do a continue (c) or a next (n) the execution returns to the same point. Is there any particular reason why this may be happening ? - Nived Hello Nived, I am experiencing the similar problem. I have been struggling for days with it and still have not found a solution, because it seems not to be too much explanation how the OpenOCD manages breakpoints internally. This is odd. I am using OpenOCD on a pxa270 target and I don't see this, neither through telnet nor gdb. Assumed this was a cache-related problem on arm946. Nived, intelmote2 is xscale also, correct? Drasko, I looked at breakpoint management recently. It's not that arcane, though the call stack is a bit long; mostly wrapper functions: handle_bp_command() - handle_bp_command_set() - breakpoint_add() - target_add_breakpoint() - arch_add_breakpoint - arch_set_breakpoint() Most of the infrastructure code is in breakpoint_add(), which allocates and populates a structure to record the breakpoint, and of course arch_set_breakpoint(). Mike ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
Hi Mike, On Wed, Sep 15, 2010 at 5:23 PM, Mike Dunn miked...@newsguy.com wrote: This is odd. I am using OpenOCD on a pxa270 target and I don't see this, neither through telnet nor gdb. Assumed this was a cache-related problem on arm946. Might be... But I introduced cache-flushing on memory write in OPenOCD code, as I explained before, and the problem persist. Can somebody confirm that this : https://lists.berlios.de/pipermail/openocd-development/2010-September/016401.html is a correct procedure to flush the caches (I am using arm966e as a target, but have arm946e core in my chip), i.e. based on information given here : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.arm9/index.html would these lines : printf (Invalidate I$\n); retval = arm966e_write_cp15(target, 0x0f, 0); printf (Invalidate D$\n); retval = arm966e_write_cp15(target, 0x0e, 0); really flush the cache ? If somebody can confirm this, than we can sign-off cache coherency as a problem and concentrate on a breakpoint handling. Drasko, I looked at breakpoint management recently. It's not that arcane, though the call stack is a bit long; mostly wrapper functions: handle_bp_command() - handle_bp_command_set() - breakpoint_add() - target_add_breakpoint() - arch_add_breakpoint - arch_set_breakpoint() Most of the infrastructure code is in breakpoint_add(), which allocates and populates a structure to record the breakpoint, and of course arch_set_breakpoint(). Thanks Mike, I will have a look at this. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Message script openocd 0.4.0 windows for In Board flash programming.
HI all berlios members list. I'm looking for help. When i execute some commands wrote in .cfg file (openocd.exe), i encounter the message *command requires more arguments* which i hadn't understand or explain exactly where's the problem. Commands as halt , poll , flash erase_check. Also, the command daemon_startup reset cause another Error (system dpn't recognize this command name?) Here attached the script that i'm using. C:\Program Files\OpenOCD\0.4.0\binopenocd.exe -f openocd.cfg Open On-Chip Debugger 0.4.0 (2010-02-22-19:05) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html parport port = 0x378 trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 TargetName Type Endian TapNameState -- -- -- -- -- *flash write_binary 0 BootLoader_108.bin 0x0 0: command requires more arguments* C:\Program Files\OpenOCD\0.4.0\bin My main goal is to program internal lpc2212 flash by one file and after, program an lpc2212 external flash, through an LPT wiggler interface and openOcd 0.4.0 windows platform. I haven't any debugging purpose, just downloading images into board flashes. I m not progressing as it could be. Is there any friend that could help me in this subject, so, I will recognize this for him so much. Note : i'm new in openOcd development. Thank you. Kamel Mahjoub # #daemon configuration telnet_port gdb_port #interface interface parport parport_port 0x378 parport_cable wiggler # jtag_rclk 1000 #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst srst_pulls_trst # reset delays jtag_nsrst_delay 100 jtag_ntrst_delay 100 #jtag scan chain #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) jtag newtap lpc2212 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x4F1F0F0F #target configuration daemon_startup reset targets #0 target create lpc2212.cpu arm7tdmi -endian little -chain-position lpc2212.cpu -variant arm7tdmi-s_r4 # internal SRAM lpc2212.cpu configure -work-area-virt 0 -work-area-phys 0x4000 -work-area-size 0x4000 -work-area-backup 0 ## program_flash BootLoader_108.bin set _CHIPNAME lpc2212 set _TARGETNAME $_CHIPNAME.cpu set _FLASHNAME $_CHIPNAME.flash flash bank $_FLASHNAME lpc2000 0x0 0x2 0 0 $_TARGETNAME lpc2000_v1 14745 calc_checksum set _File BootLoader_108.bin flash banks halt sleep 10 poll flash probe 0 flash erase_check 1 0 1 flash write_binary 0 $_File 0x0 0 sleep 200 shutdown ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fwd: Message script openocd 0.4.0 windows for In Board flash programming.
My board consists of LPC2212 micro and Flash Spansion S29AL016D. Yours truly Kamel Mahjoub -- Forwarded message -- From: Mahjoub Kamel mahjoubkame...@gmail.com Date: 2010/9/15 Subject: Message script openocd 0.4.0 windows for In Board flash programming. To: openocd-development@lists.berlios.de, openocd-development-requ...@lists.berlios.de Cc: Kamel MAHJOUB kamel.mahj...@sagemcom.com HI all berlios members list. I'm looking for help. When i execute some commands wrote in .cfg file (openocd.exe), i encounter the message *command requires more arguments* which i hadn't understand or explain exactly where's the problem. Commands as halt , poll , flash erase_check. Also, the command daemon_startup reset cause another Error (system dpn't recognize this command name?) Here attached the script that i'm using. C:\Program Files\OpenOCD\0.4.0\binopenocd.exe -f openocd.cfg Open On-Chip Debugger 0.4.0 (2010-02-22-19:05) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html parport port = 0x378 trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 TargetName Type Endian TapNameState -- -- -- -- -- *flash write_binary 0 BootLoader_108.bin 0x0 0: command requires more arguments* C:\Program Files\OpenOCD\0.4.0\bin My main goal is to program internal lpc2212 flash by one file and after, program an lpc2212 external flash, through an LPT wiggler interface and openOcd 0.4.0 windows platform. I haven't any debugging purpose, just downloading images into board flashes. I m not progressing as it could be. Is there any friend that could help me in this subject, so, I will recognize this for him so much. Note : i'm new in openOcd development. Thank you. Kamel Mahjoub # #daemon configuration telnet_port gdb_port #interface interface parport parport_port 0x378 parport_cable wiggler # jtag_rclk 1000 #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst srst_pulls_trst # reset delays jtag_nsrst_delay 100 jtag_ntrst_delay 100 #jtag scan chain #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) jtag newtap lpc2212 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x4F1F0F0F #target configuration daemon_startup reset targets #0 target create lpc2212.cpu arm7tdmi -endian little -chain-position lpc2212.cpu -variant arm7tdmi-s_r4 # internal SRAM lpc2212.cpu configure -work-area-virt 0 -work-area-phys 0x4000 -work-area-size 0x4000 -work-area-backup 0 ## program_flash BootLoader_108.bin set _CHIPNAME lpc2212 set _TARGETNAME $_CHIPNAME.cpu set _FLASHNAME $_CHIPNAME.flash flash bank $_FLASHNAME lpc2000 0x0 0x2 0 0 $_TARGETNAME lpc2000_v1 14745 calc_checksum set _File BootLoader_108.bin flash banks halt sleep 10 poll flash probe 0 flash erase_check 1 0 1 flash write_binary 0 $_File 0x0 0 sleep 200 shutdown ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote: If somebody can confirm this, than we can sign-off cache coherency as a problem and concentrate on a breakpoint handling. I sent in a patch a while back to fix this very problem on the xscale; i.e., software breakpoints didn't work because of cache issues. The problem was clear: execution failed to halt on software breakpoints most of the time. And always if set a few instructions ahead of the current value of the pc. Once the code to clean and flush the cache was added, the problem went away and I haven't seen any issues since, and I use sw breakpoints frequently. My guess is that this is not a cache issue. I never saw wierd behavior like winding up at the same instruction after a step. If I were seeing the same problem on my target, I would guess a bug in the single-stepping code. Since I'm not seeing it, I'm at a loss. Mike ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On 09/15/2010 08:35 AM, Nived wrote: Mike, Yes, the intelmote2 is Xscale. Could it be a configuration issue then ? Perhaps. I am using the default cfg files pxa270.cfg, crossbow_tech_imote2.cfg and olimex_arm_usb_tiny_h.cfg. I'm using the same Olimex i/f as you (finally upgraded from parallel port wiggler). My board is a actually a Palm Treo with JTAG wires soldered on. So only our target boards differ, and possibly our version of OpenOCD. Nived, I would make sure I'm running with the latest OpenOCD source from git, if you haven't already. Software breakpoints on xscale were fixed in the not too distant past, and breakpoiint-related enhancements just went in the other day. The latest change will let you see the bkpt instruction in memory (using 'mdw' or 'arm disassemble') right after issuing the 'bp' command. I would also experiment on the telnet interface. If after hitting the bp, if you remove it, then set another one on the next instruction and resume, do you step to the next instruction? Can you see the bkpt instruction in memory after adding it? Mike ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn miked...@newsguy.com wrote: On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote: I sent in a patch a while back to fix this very problem on the xscale; i.e., software breakpoints didn't work because of cache issues. The problem was clear: execution failed to halt on software breakpoints most of the time. And always if set a few instructions ahead of the current value of the pc. Once the code to clean and flush the cache was added, the problem went away and I haven't seen any issues since, and I use sw breakpoints frequently. Yes, not hitting breakpoint can make one suspect on caches, i.e. breakpoint was put in RAM, but not replicated in cache. Here we are facing different behavior : breakpoint is always hit, no mater at which instruction it is put. My guess is that this is not a cache issue. I never saw wierd behavior like winding up at the same instruction after a step. If I were seeing the same problem on my target, I would guess a bug in the single-stepping code. I am thinking the same - not a cache issue, but breakpoint management/single stepping bug. I also said that it might have something to do with interrupt handling, having in mind of SIGINT involved in a SW breakpoint mechanism... Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
On Wed, Sep 15, 2010 at 8:28 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn miked...@newsguy.com wrote: On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote: I sent in a patch a while back to fix this very problem on the xscale; i.e., software breakpoints didn't work because of cache issues. The problem was clear: execution failed to halt on software breakpoints most of the time. And always if set a few instructions ahead of the current value of the pc. Once the code to clean and flush the cache was added, the problem went away and I haven't seen any issues since, and I use sw breakpoints frequently. Yes, not hitting breakpoint can make one suspect on caches, i.e. breakpoint was put in RAM, but not replicated in cache. Here we are facing different behavior : breakpoint is always hit, no mater at which instruction it is put. OK, writing previous e-mail, one thing crossed my mind : I was (and probably NIved also) putting breakppoints before starting a program, which in my case is e-Cos application. As e-Cos will initialize caches during the boot, bkpt instruction placed by the GDB in RAM will be replicated to the cache. But I never before did try to start e-Cos, stop it via GDB and place a SW breakpoint. This way, if it is really a cache problem, bkpt instruction will be placed in memory, but not replicated in cache and thus never seen when we do 'c'. And that is exactly what happens in my case - program never stops after. So, this can prove two things : 1) Problem comes from cache inconsistency. 2) My routines for cache flushing : printf (Invalidate I$\n); retval = arm966e_write_cp15(target, 0x0f, 0); printf (Invalidate D$\n); retval = arm966e_write_cp15(target, 0x0e, 0); are not good. My question is here can anybody, based on ARM946E doc given here : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.arm9/index.html can give me valid parameters to write into CP15 with arm966e_write_cp15() function in order to flush I$, because I can not see what is wrong with the lines I came up with... Nived, as Mike pointed out you probably took old code without cache-handling patch. Can you also try to run your program without any breakpoint set, than stop it with CTRL+C, and then set breakpoint to some instruction that is after the address at which you stopped (yet to come in program execution flow), and continue execution (by putting 'c' in GDB). If it is a cache problem it will never stop on this new breakpoint. Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unable to step through code in GDB
Mike, Yes, it turns out i was using an older version of OpenOCD, i just tried with the latest version, and its working fine. Thanks so much for your help. Drasko, i am sorry i can't be of more help with your issue, i hope you find a solution soon. - Nived On Wed, Sep 15, 2010 at 11:56 AM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Wed, Sep 15, 2010 at 8:28 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Wed, Sep 15, 2010 at 7:58 PM, Mike Dunn miked...@newsguy.com wrote: On 09/15/2010 08:47 AM, Drasko DRASKOVIC wrote: I sent in a patch a while back to fix this very problem on the xscale; i.e., software breakpoints didn't work because of cache issues. The problem was clear: execution failed to halt on software breakpoints most of the time. And always if set a few instructions ahead of the current value of the pc. Once the code to clean and flush the cache was added, the problem went away and I haven't seen any issues since, and I use sw breakpoints frequently. Yes, not hitting breakpoint can make one suspect on caches, i.e. breakpoint was put in RAM, but not replicated in cache. Here we are facing different behavior : breakpoint is always hit, no mater at which instruction it is put. OK, writing previous e-mail, one thing crossed my mind : I was (and probably NIved also) putting breakppoints before starting a program, which in my case is e-Cos application. As e-Cos will initialize caches during the boot, bkpt instruction placed by the GDB in RAM will be replicated to the cache. But I never before did try to start e-Cos, stop it via GDB and place a SW breakpoint. This way, if it is really a cache problem, bkpt instruction will be placed in memory, but not replicated in cache and thus never seen when we do 'c'. And that is exactly what happens in my case - program never stops after. So, this can prove two things : 1) Problem comes from cache inconsistency. 2) My routines for cache flushing : printf (Invalidate I$\n); retval = arm966e_write_cp15(target, 0x0f, 0); printf (Invalidate D$\n); retval = arm966e_write_cp15(target, 0x0e, 0); are not good. My question is here can anybody, based on ARM946E doc given here : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.arm9/index.html can give me valid parameters to write into CP15 with arm966e_write_cp15() function in order to flush I$, because I can not see what is wrong with the lines I came up with... Nived, as Mike pointed out you probably took old code without cache-handling patch. Can you also try to run your program without any breakpoint set, than stop it with CTRL+C, and then set breakpoint to some instruction that is after the address at which you stopped (yet to come in program execution flow), and continue execution (by putting 'c' in GDB). If it is a cache problem it will never stop on this new breakpoint. Best regards, Drasko ___ 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] cortex-r4 core
Gene Smith wrote, On 09/14/2010 02:26 PM: Will openocd work with a cortex-r4 core (armv7-r)? I think it is similar to armv7-a but w/o MMU. The only vendor making a generally available part with this core is TI TMS570 dual core. I would be using it in a custom ASIC with a jtag interface. -gene Actually using the r4 core in the ASIC, not the TMS570 (just to be clear). Guess I missed this from 2009 on this list: http://www.mail-archive.com/openocd-development@lists.berlios.de/msg07473.html This seems to be the only commercial eval board for this core (TMS570 is actually dual core): http://processors.wiki.ti.com/index.php/TMS570_MDK_Kit The board is made by Keil (or has their name on it) for TI and another article shows using the jlink. They provide a direct usb debug interface that they mainly emphasize. Any ideas on what kind of problems might be run into if using this with openocd via jtag? -gene ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
