[Openocd-development] SAM7S256 still broken, by 1889 too
Hello list, the SAM7S256 is still broken like I have reported before: https://lists.berlios.de/pipermail/openocd-development/2009-May/006929.html The OpenOCD output looks like: = C:\Temp\SAM7S256Testopenocd-1889 -f .\prj\jtagkey.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-23-09:57) svn:1889 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ 30 kHz Info : JTAG tap: sam7s256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) Info : JTAG Tap/device matched 30 kHz Info : JTAG tap: sam7s256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) Info : JTAG Tap/device matched Warn : srst pulls trst - can not reset into halted mode. Issuing halt after rese t. Warn : value captured during scan didn't pass the requested check: Warn : captured: 0x0F check_value: 0x01 check_mask: 0x0F Error: timed out while waiting for target halted Runtime error, file embedded:startup.tcl, line 212: expected return code but got 'TARGET: sam7s256.cpu - Not halted' Runtime error, file .\prj\jtagkey.cfg, line 99: = Attached is the d3 log file too. Please apply the patch from Magnus, which was send here too: https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html - jtag_090522.patch - ft2232_090522.patch This solve the problem. All the three patches was tested against 1881 with the following targets under Windows and FT2232: SAM7S256, SAM7X256, AT91R40008, SAM7SE512, LPC2148, LPC2294, STR710, STM32F103ZE. Tested was RAM debugging under Insight. The same test with SAM7S256 LPC2148, LPC2294 STR710, STM32F103ZE was done under Mac OS X with FT2232 and J-Link, RAM debugging under Eclipse. Regards, Michael Debug: 9 0 configuration.c:83 find_file(): found .\prj\jtagkey.cfg Debug: 11 0 command.c:88 script_command(): script_command - telnet_port Debug: 12 0 command.c:105 script_command(): script_command - telnet_port, argv[0]=ocd_telnet_port Debug: 13 0 command.c:105 script_command(): script_command - telnet_port, argv[1]= Debug: 15 0 command.c:88 script_command(): script_command - gdb_port Debug: 16 0 command.c:105 script_command(): script_command - gdb_port, argv[0]=ocd_gdb_port Debug: 17 0 command.c:105 script_command(): script_command - gdb_port, argv[1]= Debug: 19 0 command.c:88 script_command(): script_command - tcl_port Debug: 20 0 command.c:105 script_command(): script_command - tcl_port, argv[0]=ocd_tcl_port Debug: 21 0 command.c:105 script_command(): script_command - tcl_port, argv[1]= Debug: 23 0 command.c:88 script_command(): script_command - gdb_memory_map Debug: 24 0 command.c:105 script_command(): script_command - gdb_memory_map, argv[0]=ocd_gdb_memory_map Debug: 25 0 command.c:105 script_command(): script_command - gdb_memory_map, argv[1]=enable Debug: 27 0 command.c:88 script_command(): script_command - gdb_flash_program Debug: 28 0 command.c:105 script_command(): script_command - gdb_flash_program, argv[0]=ocd_gdb_flash_program Debug: 29 0 command.c:105 script_command(): script_command - gdb_flash_program, argv[1]=enable Debug: 31 0 command.c:88 script_command(): script_command - interface Debug: 32 0 command.c:105 script_command(): script_command - interface, argv[0]=ocd_interface Debug: 33 0 command.c:105 script_command(): script_command - interface, argv[1]=ft2232 Debug: 35 0 command.c:88 script_command(): script_command - ft2232_device_desc Debug: 36 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc Debug: 37 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[1]=Amontec JTAGkey A Debug: 39 0 command.c:88 script_command(): script_command - ft2232_layout Debug: 40 0 command.c:105 script_command(): script_command - ft2232_layout, argv[0]=ocd_ft2232_layout Debug: 41 0 command.c:105 script_command(): script_command - ft2232_layout, argv[1]=jtagkey Debug: 43 0 command.c:88 script_command(): script_command - ft2232_vid_pid Debug: 44 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[0]=ocd_ft2232_vid_pid Debug: 45 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[1]=0x0403 Debug: 46 0 command.c:105 script_command(): script_command - ft2232_vid_pid, argv[2]=0xcff8 Debug: 48 0 command.c:88 script_command(): script_command - jtag_khz Debug: 49 0 command.c:105 script_command(): script_command - jtag_khz, argv[0]=ocd_jtag_khz Debug: 50 0 command.c:105 script_command(): script_command - jtag_khz, argv[1]=30 Debug: 51 0 jtag.c:2787 handle_jtag_khz_command(): handle jtag khz User : 52 0 command.c:380 command_print(): 30 kHz Debug: 54 0 command.c:88 script_command(): script_command - reset_config Debug: 55 0 command.c:105
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, May 23, 2009 at 10:14 AM, Zach Welch z...@superlucidity.net wrote: On Sat, 2009-05-23 at 09:54 +0800, Xiaofan Chen wrote: [snip] I am also thinking that the USB timeout value may be extended a bit longer. Right now it is 1000ms. Should be ok. But may not be ok for people using VM or similar. The problem with this is that it slows down the failure process when something is actually broken. I think more intelligence is needed, not just a different default setting. I do not see a way of intelligence here. But I am not a programmer and I do not even know the format of printf for a long int. ;-). I think it can be safely increased to 5000ms. But maybe this is not the really issue. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
I am also thinking that the USB timeout value may be extended a bit longer. Right now it is 1000ms. Should be ok. But may not be ok for people using VM or similar. The problem with this is that it slows down the failure process when something is actually broken. I think more intelligence is needed, not just a different default setting. Considering that USB bulk transfers are best effort and might easily be delayed by concurrent activity to a USB disk or webcam ... a single second seems absurdly short. Even if the device were guaranteed to be able to respond that quickly. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, May 23, 2009 at 6:57 PM, David Brownell davi...@pacbell.net wrote: I am also thinking that the USB timeout value may be extended a bit longer. Right now it is 1000ms. Should be ok. But may not be ok for people using VM or similar. The problem with this is that it slows down the failure process when something is actually broken. I think more intelligence is needed, not just a different default setting. Considering that USB bulk transfers are best effort and might easily be delayed by concurrent activity to a USB disk or webcam ... a single second seems absurdly short. Even if the device were guaranteed to be able to respond that quickly. Yes this is what I think as well. I do not know what is the best value though. What do you think? -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Tue, May 19, 2009 at 8:26 AM, Igor Skochinsky skochin...@mail.ru wrote: What I mean is I could write up a list of missing/underdocumented commands and describe their input/output parameters. I don't have a J-Link so I don't really need the code myself. Are you using reverse engineering from the J-Link Windows DLL? -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SAM7S256 still broken, by 1889 too
Michael Fischer pisze: the SAM7S256 is still broken I've tested r1889 with LPC2103 and it fails too I run: openocd-r1889 -f interface/jtagkey.cfg -f target/lpc2103.cfg Which results in: Info : JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched Warn : no telnet port specified, using default port Warn : no gdb port specified, using default port Warn : no tcl port specified, using default port So it's fine now. I connect via telnet and: poll target state: running soft_reset_halt requesting target halt and executing a soft reset target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x So it's still fine. But when I add a reset: reset JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0 xf1f0, Version: 0x4) JTAG Tap/device matched poll target state: running soft_reset_halt requesting target halt and executing a soft reset Failed to halt CPU after 1 sec poll target state: running The only way to halt it again is to restart OpenOCD - I do not touch the reset button on the target. Below I add a complete d3 log of OpenOCD for the following set: poll target state: running soft_reset_halt requesting target halt and executing a soft reset target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x reset JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0 xf1f0, Version: 0x4) JTAG Tap/device matched poll target state: running soft_reset_halt requesting target halt and executing a soft reset Failed to halt CPU after 1 sec poll target state: running openocd-r1889 -d3 -f interface/jtagkey.cfg -f target/lpc2103.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-23-12:22) svn:unknown BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ Debug: 5 0 configuration.c:83 find_file(): found C:\Program Files\OpenOCD\0.1.0\ bin\../interface/jtagkey.cfg Debug: 7 0 command.c:88 script_command(): script_command - interface Debug: 8 0 command.c:105 script_command(): script_command - interface, argv[0]=o cd_interface Debug: 9 0 command.c:105 script_command(): script_command - interface, argv[1]=f t2232 Debug: 11 0 command.c:88 script_command(): script_command - ft2232_device_desc Debug: 12 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc Debug: 13 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[1]=Amontec JTAGkey A Debug: 15 0 command.c:88 script_command(): script_command - ft2232_layout Debug: 16 0 command.c:105 script_command(): script_command - ft2232_layout, argv [0]=ocd_ft2232_layout Debug: 17 0 command.c:105 script_command(): script_command - ft2232_layout, argv [1]=jtagkey Debug: 19 16 command.c:88 script_command(): script_command - ft2232_vid_pid Debug: 20 16 command.c:105 script_command(): script_command - ft2232_vid_pid, ar gv[0]=ocd_ft2232_vid_pid Debug: 21 16 command.c:105 script_command(): script_command - ft2232_vid_pid, ar gv[1]=0x0403 Debug: 22 16 command.c:105 script_command(): script_command - ft2232_vid_pid, ar gv[2]=0xcff8 Debug: 23 16 configuration.c:83 find_file(): found C:\Program Files\OpenOCD\0.1. 0\bin\../target/lpc2103.cfg Debug: 25 16 command.c:88 script_command(): script_command - reset_config Debug: 26 16 command.c:105 script_command(): script_command - reset_config, argv [0]=ocd_reset_config Debug: 27 16 command.c:105 script_command(): script_command - reset_config, argv [1]=trst_and_srst Debug: 28 16 command.c:105 script_command(): script_command - reset_config, argv [2]=srst_pulls_trst Debug: 29 16 jtag.c:2029 jim_newtap_cmd(): Creating New Tap, Chip: lpc2103, Tap: cpu, Dotted: lpc2103.cpu, 8 params Debug: 30 16 jtag.c:2048 jim_newtap_cmd(): Processing option: -irlen Debug: 31 16 jtag.c:2048 jim_newtap_cmd(): Processing option: -ircapture Debug: 32 16 jtag.c:2048 jim_newtap_cmd(): Processing option: -irmask Debug: 33 16 jtag.c:2048 jim_newtap_cmd(): Processing option: -expected-id Debug: 34 16 jtag.c:2161 jim_newtap_cmd(): Created Tap: lpc2103.cpu @ abs positi on 0, irlen 4, capture: 0x1 mask: 0xf Debug: 35 16 target.c:3969 jim_target(): Target command params: Debug: 36 16 target.c:3970 jim_target(): target create lpc2103.cpu arm7tdmi -end ian little -chain-position lpc2103.cpu -variant arm7tdmi-s_r4 Debug: 38 16 command.c:88 script_command(): script_command - bank Debug: 39 16 command.c:105 script_command(): script_command - bank, argv[0]=ocd_ flash_bank Debug: 40 31 command.c:105 script_command(): script_command - bank, argv[1]=lpc2 000 Debug: 41 31 command.c:105 script_command(): script_command - bank, argv[2]=0x0 Debug: 42 31 command.c:105 script_command():
[Openocd-development] SVN revision in Windows
Hello! can someone tell me how to get the proper SVN revision to be displayed in OpenOCD? I just can't make that happen... I checkout directly into the compile folder via TortoiseSVN, compile and always get: Open On-Chip Debugger 0.2.0-in-development (2009-05-23-12:22) svn:unknown ); regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SAM7S256 still broken, by 1889 too
Hello Freddie, response to: https://lists.berlios.de/pipermail/openocd-development/2009-May/007113.html here it is working with a LPC2148, tested with r1888 and the pathes from Magnus: https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html Can you test it with the jtag_090522.patch and ft2232_090522.patch too? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SVN revision in Windows
Hello Freddie, have you installed SVN under Cygwin too? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SVN revision in Windows
Michael Fischer pisze: have you installed SVN under Cygwin too? I use MSYS + MinGW to compile, so I guess that I should use some SVN client for MSYS for that feature to work? regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SAM7S256 still broken, by 1889 too
Michael Fischer pisze: here it is working with a LPC2148, tested with r1888 and the pathes from Magnus: https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html Can you test it with the jtag_090522.patch and ft2232_090522.patch too? I've tested with r1889. It's still failing, but in some other way. Now I can't reset the target Open On-Chip Debugger poll target state: running soft_reset_halt requesting target halt and executing a soft reset target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x reset JTAG communication failure, check connection, JTAG interface, target power etc. trying to validate configured JTAG chain anyway... poll target state: running soft_reset_halt requesting target halt and executing a soft reset Failed to halt CPU after 1 sec poll target state: running and -d3 logs for that: openocd-r1889-patched -d3 -f interface/jtagkey.cfg -f target/lpc2103.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-23-14:15) svn:unknown BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ Debug: 5 0 configuration.c:83 find_file(): found C:\Program Files\OpenOCD\0.1.0\ bin\../interface/jtagkey.cfg Debug: 7 0 command.c:88 script_command(): script_command - interface Debug: 8 0 command.c:105 script_command(): script_command - interface, argv[0]=o cd_interface Debug: 9 0 command.c:105 script_command(): script_command - interface, argv[1]=f t2232 Debug: 11 0 command.c:88 script_command(): script_command - ft2232_device_desc Debug: 12 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[0]=ocd_ft2232_device_desc Debug: 13 0 command.c:105 script_command(): script_command - ft2232_device_desc, argv[1]=Amontec JTAGkey A Debug: 15 0 command.c:88 script_command(): script_command - ft2232_layout Debug: 16 0 command.c:105 script_command(): script_command - ft2232_layout, argv [0]=ocd_ft2232_layout Debug: 17 0 command.c:105 script_command(): script_command - ft2232_layout, argv [1]=jtagkey Debug: 19 0 command.c:88 script_command(): script_command - ft2232_vid_pid Debug: 20 0 command.c:105 script_command(): script_command - ft2232_vid_pid, arg v[0]=ocd_ft2232_vid_pid Debug: 21 15 command.c:105 script_command(): script_command - ft2232_vid_pid, ar gv[1]=0x0403 Debug: 22 15 command.c:105 script_command(): script_command - ft2232_vid_pid, ar gv[2]=0xcff8 Debug: 23 15 configuration.c:83 find_file(): found C:\Program Files\OpenOCD\0.1. 0\bin\../target/lpc2103.cfg Debug: 25 15 command.c:88 script_command(): script_command - reset_config Debug: 26 15 command.c:105 script_command(): script_command - reset_config, argv [0]=ocd_reset_config Debug: 27 15 command.c:105 script_command(): script_command - reset_config, argv [1]=trst_and_srst Debug: 28 15 command.c:105 script_command(): script_command - reset_config, argv [2]=srst_pulls_trst Debug: 29 15 jtag.c:2030 jim_newtap_cmd(): Creating New Tap, Chip: lpc2103, Tap: cpu, Dotted: lpc2103.cpu, 8 params Debug: 30 15 jtag.c:2049 jim_newtap_cmd(): Processing option: -irlen Debug: 31 15 jtag.c:2049 jim_newtap_cmd(): Processing option: -ircapture Debug: 32 15 jtag.c:2049 jim_newtap_cmd(): Processing option: -irmask Debug: 33 15 jtag.c:2049 jim_newtap_cmd(): Processing option: -expected-id Debug: 34 15 jtag.c:2162 jim_newtap_cmd(): Created Tap: lpc2103.cpu @ abs positi on 0, irlen 4, capture: 0x1 mask: 0xf Debug: 35 15 target.c:3969 jim_target(): Target command params: Debug: 36 15 target.c:3970 jim_target(): target create lpc2103.cpu arm7tdmi -end ian little -chain-position lpc2103.cpu -variant arm7tdmi-s_r4 Debug: 38 15 command.c:88 script_command(): script_command - bank Debug: 39 15 command.c:105 script_command(): script_command - bank, argv[0]=ocd_ flash_bank Debug: 40 31 command.c:105 script_command(): script_command - bank, argv[1]=lpc2 000 Debug: 41 31 command.c:105 script_command(): script_command - bank, argv[2]=0x0 Debug: 42 31 command.c:105 script_command(): script_command - bank, argv[3]=0x80 00 Debug: 43 31 command.c:105 script_command(): script_command - bank, argv[4]=0 Debug: 44 31 command.c:105 script_command(): script_command - bank, argv[5]=0 Debug: 45 31 command.c:105 script_command(): script_command - bank, argv[6]=0 Debug: 46 31 command.c:105 script_command(): script_command - bank, argv[7]=lpc2 000_v2 Debug: 47 31 command.c:105 script_command(): script_command - bank, argv[8]=1200 0 Debug: 48 31 command.c:105 script_command(): script_command - bank, argv[9]=calc _checksum Debug: 50 31 command.c:88 script_command(): script_command - jtag_khz Debug: 51 31 command.c:105 script_command(): script_command - jtag_khz, argv[0]= ocd_jtag_khz Debug: 52 31 command.c:105 script_command(): script_command - jtag_khz, argv[1]= 1000 Debug: 53 31 jtag.c:2788 handle_jtag_khz_command(): handle jtag khz User : 54 31 command.c:380
Re: [Openocd-development] SAM7S256 still broken, by 1889 too
Michael Fischer pisze: only a test. Take a look at the LPC2148 here you will find the following lines: jtag_nsrst_delay 200 jtag_ntrst_delay 200 Please add this two lines to your lpc2103 cfg too. With those delays the patched r1889 works. The delays can by very low - I've tried with 10ms and it still works. But here is the funny thing - the _unpatched_ r1889 works as well when I add those delays... Anyway - I attach a patch that adds those delays to lpc2103.cfg, lpc2124.cfg and lpc2129.cfg (all LPC2000 cfgs that don't have those delays specified). If those delays are mandatory now (it doesn't work without them) shouldn't those be always enabled to some low value (like 10ms?) so that user wouldn't need to specify that? When used does specify a value, that would override the default hidden values in the code. 0 could also be allowed. regards Index: src/target/target/lpc2103.cfg === --- src/target/target/lpc2103.cfg (revision 1889) +++ src/target/target/lpc2103.cfg (working copy) @@ -21,6 +21,10 @@ # LPC2000 - SRST causes TRST reset_config trst_and_srst srst_pulls_trst +# reset delays +jtag_nsrst_delay 100 +jtag_ntrst_delay 100 + jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID set _TARGETNAME [format %s.cpu $_CHIPNAME] Index: src/target/target/lpc2124.cfg === --- src/target/target/lpc2124.cfg (revision 1889) +++ src/target/target/lpc2124.cfg (working copy) @@ -22,7 +22,11 @@ #use combined on interfaces or targets that can't set TRST/SRST separately reset_config trst_and_srst srst_pulls_trst -jtag_nsrst_delay 10 + +# reset delays +jtag_nsrst_delay 100 +jtag_ntrst_delay 100 + jtag_khz 1000 #jtag scan chain Index: src/target/target/lpc2129.cfg === --- src/target/target/lpc2129.cfg (revision 1889) +++ src/target/target/lpc2129.cfg (working copy) @@ -23,6 +23,11 @@ #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 jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Building OpenOCD with Cygwin
With the help of the SparkFun thread, http://forum.sparkfun.com/viewtopic.php?t=11221 I was tryam going to build OpenOCD but somehow it failed. $ ./configure --enable-maintainer-mode --enable-jlink CC=gcc -mno-cygwin CFLAGS=-O0 -g -Wall This is ok. But make failed. mc...@acerpc ~/mcu/openocd/trunk $ make make all-recursive make[1]: Entering directory `/home/mcuee/mcu/openocd/trunk' Making all in src make[2]: Entering directory `/home/mcuee/mcu/openocd/trunk/src' Making all in helper make[3]: Entering directory `/home/mcuee/mcu/openocd/trunk/src/helper' /bin/sh ../../libtool --tag=CC --mode=compile gcc -mno-cygwin -std=gnu99 -DHAV E_CONFIG_H -I. -I../.. -I../../src/server -I../../src/target -DPKGDATADIR=\/us r/local/share/openocd\ -DPKGLIBDIR=\/usr/local/lib/openocd\ -Wno-sign-compar e -O0 -g -Wall -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-p arameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT libhelpe r_la-binarybuffer.lo -MD -MP -MF .deps/libhelper_la-binarybuffer.Tpo -c -o libhe lper_la-binarybuffer.lo `test -f 'binarybuffer.c' || echo './'`binarybuffer.c mkdir .libs gcc -mno-cygwin -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/server -I../ ../src/target -DPKGDATADIR=\/usr/local/share/openocd\ -DPKGLIBDIR=\/usr/local /lib/openocd\ -Wno-sign-compare -O0 -g -Wall -Wall -Wstrict-prototypes -Wformat -security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredun dant-decls -Werror -MT libhelper_la-binarybuffer.lo -MD -MP -MF .deps/libhelper_ $ binarybuffer.o In file included from ../../config.h:256, from binarybuffer.c:24: ./replacements.h:213: error: parse error before Elf32_Addr ./replacements.h:213: warning: type defaults to `int' in declaration of `Elf32_A ddr' ./replacements.h:213: warning: data definition has no type or storage class ./replacements.h:214: error: parse error before Elf32_Half ./replacements.h:214: warning: type defaults to `int' in declaration of `Elf32_H alf' ./replacements.h:214: warning: data definition has no type or storage class ./replacements.h:215: error: parse error before Elf32_Off ./replacements.h:215: warning: type defaults to `int' in declaration of `Elf32_O ff' ./replacements.h:215: warning: data definition has no type or storage class ./replacements.h:216: error: parse error before Elf32_Sword $ word' ./replacements.h:216: warning: data definition has no type or storage class ./replacements.h:217: error: parse error before Elf32_Word ./replacements.h:217: warning: type defaults to `int' in declaration of `Elf32_W ord' ./replacements.h:217: warning: data definition has no type or storage class ./replacements.h:218: error: parse error before Elf32_Size ./replacements.h:218: warning: type defaults to `int' in declaration of `Elf32_S ize' ./replacements.h:218: warning: data definition has no type or storage class ./replacements.h:219: error: parse error before Elf32_Hashelt ./replacements.h:219: warning: type defaults to `int' in declaration of `Elf32_H ashelt' ./replacements.h:219: warning: data definition has no type or storage class ./replacements.h:224: error: parse error before Elf32_Half ./replacements.h:224: warning: no semicolon at end of struct or union ./replacements.h:225: warning: type defaults to `int' in declaration of `e_machi ne' ./replacements.h:225: warning: data definition has no type or storage class ./replacements.h:226: error: parse error before e_version ./replacements.h:226: warning: type defaults to `int' in declaration of `e_versi on' ./replacements.h:226: warning: data definition has no type or storage class ./replacements.h:227: error: parse error before e_entry ./replacements.h:227: warning: type defaults to `int' in declaration of `e_entry ' ./replacements.h:227: warning: data definition has no type or storage class ./replacements.h:228: error: parse error before e_phoff ./replacements.h:228: warning: type defaults to `int' in declaration of `e_phoff ' ./replacements.h:228: warning: data definition has no type or storage class ./replacements.h:229: error: parse error before e_shoff ./replacements.h:229: warning: type defaults to `int' in declaration of `e_shoff ' ./replacements.h:229: warning: data definition has no type or storage class ./replacements.h:230: error: parse error before e_flags ./replacements.h:230: warning: type defaults to `int' in declaration of `e_flags ' ./replacements.h:230: warning: data definition has no type or storage class ./replacements.h:231: error: parse error before e_ehsize ./replacements.h:231: warning: type defaults to `int' in declaration of `e_ehsiz e' ./replacements.h:231: warning: data definition has no type or storage class ./replacements.h:232: error: parse error before e_phentsize ./replacements.h:232: warning: type defaults to `int' in declaration of `e_phent size' ./replacements.h:232: warning: data definition has no type or storage class ./replacements.h:233: error: parse error before e_phnum ./replacements.h:233:
Re: [Openocd-development] Building OpenOCD with Cygwin
Add #include stdint.h in replacements.h to solve this problem. 2009-05-24 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： Xiaofan Chen 发送时间： 2009-05-24 00:36:17 收件人： Openocd-Dev 抄送： 主题： [Openocd-development] Building OpenOCD with Cygwin With the help of the SparkFun thread, http://forum.sparkfun.com/viewtopic.php?t=11221 I was tryam going to build OpenOCD but somehow it failed. $ ./configure --enable-maintainer-mode --enable-jlink CC=gcc -mno-cygwin CFLAGS=-O0 -g -Wall This is ok. But make failed. mc...@acerpc ~/mcu/openocd/trunk $ make make all-recursive make[1]: Entering directory `/home/mcuee/mcu/openocd/trunk' Making all in src make[2]: Entering directory `/home/mcuee/mcu/openocd/trunk/src' Making all in helper make[3]: Entering directory `/home/mcuee/mcu/openocd/trunk/src/helper' /bin/sh ../../libtool --tag=CC --mode=compile gcc -mno-cygwin -std=gnu99 -DHAV E_CONFIG_H -I. -I../.. -I../../src/server -I../../src/target -DPKGDATADIR=\/us r/local/share/openocd\ -DPKGLIBDIR=\/usr/local/lib/openocd\ -Wno-sign-compar e -O0 -g -Wall -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-p arameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT libhelpe r_la-binarybuffer.lo -MD -MP -MF .deps/libhelper_la-binarybuffer.Tpo -c -o libhe lper_la-binarybuffer.lo `test -f 'binarybuffer.c' || echo './'`binarybuffer.c mkdir .libs gcc -mno-cygwin -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/server -I../ ../src/target -DPKGDATADIR=\/usr/local/share/openocd\ -DPKGLIBDIR=\/usr/local /lib/openocd\ -Wno-sign-compare -O0 -g -Wall -Wall -Wstrict-prototypes -Wformat -security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredun dant-decls -Werror -MT libhelper_la-binarybuffer.lo -MD -MP -MF .deps/libhelper_ $ binarybuffer.o In file included from ../../config.h:256, from binarybuffer.c:24: ./replacements.h:213: error: parse error before Elf32_Addr ./replacements.h:213: warning: type defaults to `int' in declaration of `Elf32_A ddr' ./replacements.h:213: warning: data definition has no type or storage class ./replacements.h:214: error: parse error before Elf32_Half ./replacements.h:214: warning: type defaults to `int' in declaration of `Elf32_H alf' ./replacements.h:214: warning: data definition has no type or storage class ./replacements.h:215: error: parse error before Elf32_Off ./replacements.h:215: warning: type defaults to `int' in declaration of `Elf32_O ff' ./replacements.h:215: warning: data definition has no type or storage class ./replacements.h:216: error: parse error before Elf32_Sword $ word' ./replacements.h:216: warning: data definition has no type or storage class ./replacements.h:217: error: parse error before Elf32_Word ./replacements.h:217: warning: type defaults to `int' in declaration of `Elf32_W ord' ./replacements.h:217: warning: data definition has no type or storage class ./replacements.h:218: error: parse error before Elf32_Size ./replacements.h:218: warning: type defaults to `int' in declaration of `Elf32_S ize' ./replacements.h:218: warning: data definition has no type or storage class ./replacements.h:219: error: parse error before Elf32_Hashelt ./replacements.h:219: warning: type defaults to `int' in declaration of `Elf32_H ashelt' ./replacements.h:219: warning: data definition has no type or storage class ./replacements.h:224: error: parse error before Elf32_Half ./replacements.h:224: warning: no semicolon at end of struct or union ./replacements.h:225: warning: type defaults to `int' in declaration of `e_machi ne' ./replacements.h:225: warning: data definition has no type or storage class ./replacements.h:226: error: parse error before e_version ./replacements.h:226: warning: type defaults to `int' in declaration of `e_versi on' ./replacements.h:226: warning: data definition has no type or storage class ./replacements.h:227: error: parse error before e_entry ./replacements.h:227: warning: type defaults to `int' in declaration of `e_entry ' ./replacements.h:227: warning: data definition has no type or storage class ./replacements.h:228: error: parse error before e_phoff ./replacements.h:228: warning: type defaults to `int' in declaration of `e_phoff ' ./replacements.h:228: warning: data definition has no type or storage class ./replacements.h:229: error: parse error before e_shoff ./replacements.h:229: warning: type defaults to `int' in declaration of `e_shoff ' ./replacements.h:229: warning: data definition has no type or storage class ./replacements.h:230: error: parse error before e_flags ./replacements.h:230: warning: type defaults to `int' in declaration of `e_flags ' ./replacements.h:230: warning: data definition has no type or storage class ./replacements.h:231: error: parse error before e_ehsize ./replacements.h:231: warning: type defaults to `int' in declaration of `e_ehsiz e' ./replacements.h:231: warning: data definition has no type or storage class
Re: [Openocd-development] Building OpenOCD with Cygwin
2009/5/24 SimonQian simonq...@simonqian.com: Add #include stdint.h in replacements.h to solve this problem. Thanks. It seems to help. Cygwin is really slow here so it is still building. Maybe I should learn to cross-compile OpenOCD under Linux for Windows. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building OpenOCD with Cygwin
On Sun, 2009-05-24 at 00:38 +0800, SimonQian wrote: Add #include stdint.h in replacements.h to solve this problem. There has been a report of this in the past, but I thought that it turned out to be a red herring: http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04166.html Here are the notes that John Devereux posted for building on CygWin: http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04261.html Something needs to be done before 0.2.0, if CygWin does require a patch. If those instructions do work, then I suggest we add them to the repository before the release. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SVN revision in Windows
On Sat, 2009-05-23 at 16:11 +0200, Freddie Chopin wrote: Michael Fischer pisze: have you installed SVN under Cygwin too? I use MSYS + MinGW to compile, so I guess that I should use some SVN client for MSYS for that feature to work? Yes. Take a look at guess-rev.sh. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD J-link under Windows
On Tue, May 19, 2009 at 2:47 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, May 19, 2009 at 2:38 PM, Spencer Oliver s...@spen-soft.co.uk wrote: I have tested both the filter and native driver under winxp. Never tested the filter driver under vista64, but the native driver works. Thanks for the confirmation. I will try out the libusb-win32 device driver for Windows Vista 32bit. Actually the libusb-win32 device driver should not work under Vista 64bit as there is no digital signature for it. But you are probably use a hack to disable that one. Anyway, I do not use Vista 64bit. Luckily as there are many device driver not working under Vista 64 ;-) Yes I just built trunk 1889 and OpenOCD seems to work fine with J-Link V3 (black) and LPC-P2148 board. I am using libusb-win32 device driver (svn trunk version built under Cygwin) under Vista 32 bit. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Big smoketest with r1888 and the 3 patches from Magnus
Hello list, I have make a new smoketest with the r1888 and the patches which can be find here: https://lists.berlios.de/pipermail/openocd-development/2009-May/007085.html Tested under Windows with FT2232 and the following targets: LPC2148, LPC2294, SAM7S256, SAM7X256, SAM7SE512, AT91R40008, STR710 and STM32. The same like before, debugging in RAM/ROM with Insight and Eclipse. In case of SAM7SE512, AT91R40008 and STM32 debugging in RAM only. The same test was done under Mac OS X with a FT2232 and a J-Link (V6) with the following targets: LPC2148, LPC2294, SAM7S256, STR710 and STM32. Here debugging with Eclipse only, and in case of STM32 debugging in RAM only. Everything was working for me. Therefore I think the two outstanding patches can be applied too: - jtag_090522.patch - ft2232_090522.patch Btw, the SAM7xxx settings must be changed becasue of the new flash driver. I will do this with a patch next. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SAM7S256 still broken, by 1889 too
Zach Welch pisze: So if I understand this right: 1) With jtag.c patch from Magnus, it works with short delays. 2) Without that patch, it requires long delays. Is that summary correct? No (; If there is ANY delay both versions (clean r1889 and patched r1889) work. When we talk about the clean version of OpenOCD, when there are no delays I cannot halt LPC2103 AFTER reset. When I apply Magnus' patch and there are no delays I cannot even reset. Assuming that I understand the above correctly: if jtag.c is patched, then this patch is not required? For current OpenOCD this patch is required anyway. But the lpc2103.cfg without those delays works fine with 0.1.0 (so around 1300) and probably worked fine with r1746. regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Being careful not to brake anything is good but ...
Common people So much soul searching about a oneliner in jtag.c . Setting the current tap state with cmd_queue_cur_state = TAP_RESET is an obvious error as 5 minutes of code inspection in jtag.c will show you. The variable is not used in any dr/ir scan code, It is only used in jtag_add_path_move to find the start state, and for sanity check in jtag_add_clocks. It will be overwritten by the next call to jtag_prelude by any ir/dr scan, and all driver code uses tap_get_state() instead. Actually ALL uses of cmd_queue_cur_state should be retired and replaced by correct accessor function tap_get_state(), as it is now we have two variables tracing the current tap state, cmd_queue_cur_state and state_follower. I am not saying that nothing will change from this, it most probably will, but the old code is broken and perhaps it is time to fix it. Have a nice weekend Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] SAM7S256 still broken, by 1889 too
Hello Zach, the outstanding patches are required to get the SAM7 working. In case of the LPC, I must use the delay here too for my LPC2148 and LPC2294 targets. Without the delay sometimes the LP2294 is working and sometimes not. It works more stable with the delay. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Sat, 2009-05-23 at 09:54 +0200, Magnus Lundin wrote: Comment - In jlink_execute_reset(jtag_command_t *cmd) jlink_tap_execute(); Should be removed and be superflous, actually both of them should be removed. After seeing your latest post, I now think I understand this to mean that the patch reduces to the one-liner of set_tap_state. Correct? If so, I would be happy to commit the other line shortly. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
On Sat, 2009-05-23 at 13:42 -0700, Zach Welch wrote: On Sat, 2009-05-23 at 09:54 +0200, Magnus Lundin wrote: Comment - In jlink_execute_reset(jtag_command_t *cmd) jlink_tap_execute(); Should be removed and be superflous, actually both of them should be removed. After seeing your latest post, I now think I understand this to mean that the patch reduces to the one-liner of set_tap_state. Correct? I'm a moron. jlink != jtag. Sorry. I'll commit the full patch shortly. Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] remove cmd_queue_cur_state
Hi all,
The attached patch removes the cmd_queue_cur_state global variable,
replacing all uses with calls to tap_set_state() or tap_get_state().
While this seems completely trivial, I wanted to post it for review.
Any objections? All in favor?
Cheers,
Zach
---
jtag/jtag.c | 13 ++---
jtag/jtag.h |3 +--
jtag/zy1000.c |4 ++--
svf/svf.c |9 ++---
target/arm11_dbgtap.c |4 ++--
xsvf/xsvf.c |4 ++--
6 files changed, 19 insertions(+), 18 deletions(-)
Index: src/jtag/zy1000.c
===
--- src/jtag/zy1000.c (revision 1893)
+++ src/jtag/zy1000.c (working copy)
@@ -709,7 +709,7 @@
int interface_jtag_add_clocks(int num_cycles)
{
- return zy1000_jtag_add_clocks(num_cycles, cmd_queue_cur_state,
cmd_queue_end_state);
+ return zy1000_jtag_add_clocks(num_cycles, tap_get_state(),
cmd_queue_end_state);
}
int interface_jtag_add_sleep(u32 us)
@@ -728,7 +728,7 @@
state_count = 0;
- tap_state_t cur_state=cmd_queue_cur_state;
+ tap_state_t cur_state = tap_get_state();
while (num_states)
{
Index: src/jtag/jtag.c
===
--- src/jtag/jtag.c (revision 1893)
+++ src/jtag/jtag.c (working copy)
@@ -94,7 +94,6 @@
enum reset_types jtag_reset_config = RESET_NONE;
tap_state_t cmd_queue_end_state = TAP_RESET;
-tap_state_t cmd_queue_cur_state = TAP_RESET;
int jtag_verify_capture_ir = 1;
int jtag_verify = 1;
@@ -565,7 +564,7 @@
if (state != TAP_INVALID)
jtag_add_end_state(state);
- cmd_queue_cur_state = cmd_queue_end_state;
+ tap_set_state(cmd_queue_end_state);
}
void jtag_add_ir_scan_noverify(int in_num_fields, const scan_field_t
*in_fields, tap_state_t state)
@@ -1066,7 +1065,7 @@
void jtag_add_pathmove(int num_states, const tap_state_t *path)
{
- tap_state_t cur_state = cmd_queue_cur_state;
+ tap_state_t cur_state = tap_get_state();
int i;
int retval;
@@ -1097,7 +1096,7 @@
jtag_prelude1();
retval = interface_jtag_add_pathmove(num_states, path);
- cmd_queue_cur_state = path[num_states - 1];
+ tap_set_state(path[num_states - 1]);
if (retval!=ERROR_OK)
jtag_error=retval;
}
@@ -1168,11 +1167,11 @@
void jtag_add_clocks( int num_cycles )
{
int retval;
-
- if( !tap_is_state_stable(cmd_queue_cur_state) )
+ tap_state_t cur_state = tap_get_state();
+ if( !tap_is_state_stable(cur_state) )
{
LOG_ERROR( jtag_add_clocks() was called with TAP in
non-stable state \%s\,
-tap_state_name(cmd_queue_cur_state) );
+tap_state_name(cur_state) );
jtag_error = ERROR_JTAG_NOT_STABLE_STATE;
return;
}
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 1893)
+++ src/jtag/jtag.h (working copy)
@@ -256,7 +256,6 @@
extern tap_state_t cmd_queue_end_state; /* finish DR scans in
dr_end_state */
-extern tap_state_t cmd_queue_cur_state; /* current TAP state */
typedef void* error_handler_t; /* Later on we can delete error_handler_t, but
keep it for now to make patches more readable */
@@ -891,7 +890,7 @@
{
if (end_state != TAP_INVALID)
cmd_queue_end_state = end_state;
- cmd_queue_cur_state = cmd_queue_end_state;
+ tap_set_state(cmd_queue_end_state);
interface_jtag_add_dr_out(tap, num_fields, num_bits, value,
cmd_queue_end_state);
}
Index: src/target/arm11_dbgtap.c
===
--- src/target/arm11_dbgtap.c (revision 1893)
+++ src/target/arm11_dbgtap.c (working copy)
@@ -48,7 +48,7 @@
int arm11_add_ir_scan_vc(int num_fields, scan_field_t *fields, tap_state_t
state)
{
- if (cmd_queue_cur_state == TAP_IRPAUSE)
+ if (tap_get_state() == TAP_IRPAUSE)
jtag_add_pathmove(asizeof(arm11_move_pi_to_si_via_ci),
arm11_move_pi_to_si_via_ci);
jtag_add_ir_scan(num_fields, fields, state);
@@ -62,7 +62,7 @@
int arm11_add_dr_scan_vc(int num_fields, scan_field_t *fields, tap_state_t
state)
{
- if (cmd_queue_cur_state == TAP_DRPAUSE)
+ if (tap_get_state() == TAP_DRPAUSE)
jtag_add_pathmove(asizeof(arm11_move_pd_to_sd_via_cd),
arm11_move_pd_to_sd_via_cd);
jtag_add_dr_scan(num_fields, fields, state);
Index: src/xsvf/xsvf.c
===
--- src/xsvf/xsvf.c (revision 1893)
+++ src/xsvf/xsvf.c (working copy)
@@ -171,7 +171,7 @@
int retval = ERROR_OK;
tap_state_t moves[8];
- tap_state_t cur_state = cmd_queue_cur_state;
+ tap_state_t
Re: [Openocd-development] RFC: style guide update
On Wed, 2009-05-20 at 01:08 -0700, Zach Welch wrote: Hi all, I want to get the style guide up-to-date. Here's my plan. Barring any objections, I will add doc/manual/style.txt by moving the relevant bits out of openocd.texi. The style guide is for developers working on the code; the user guide should not need to mention the code. though that may take some time. I will then patch the new file with some pending changes that I made when style topics were being discussed in the past month. That patch includes a list of those C99 features that the community seemed to think would be acceptable. Others can then choose to revisit my revisions or to expand this section in its new location. In the process, I will revisit my changes to add another section to provide some rules for typedefs, though I have seen that this needs to be filled out have some discussion. What should the typedef rules be? In r1895-1897, I have done most of what I said I would do above, but -- amusingly -- I did not get around to revisiting the typedef sections. I intend to end all future style wars by updating the guide once a consensus has been reached by the community. [[This includes any flames sparked by my updates to the guide.]] If agreement proves intractable, the maintainers may need to make executive decisions. I hope this will help improve the code over time. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding simulated target support for regression testing purposes
On Thu, 2009-05-21 at 16:54 -0700, David Brownell wrote:
On Thursday 21 May 2009, Michael Fischer wrote:
It looks that these JTAG interfaces have not the same behaviour.
One point could be the RESET signals SRST and TRST. Here the
FT2232 can set both signals at the same time, which I think
is used too.
Yeah, I noticed that *sometimes* an ft2232 adapter was able
to come up OK ... but other times it needed a reset.
I was wondering if the issue was maybe that the JTAG link
wasn't getting properly reset ... either by TRST or some
other process.
This seems highly buglike to me.
Has this problem been resolved in r18{90,92,93}?
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SAM7S256 still broken, by 1889 too
On Sat, 2009-05-23 at 21:41 +0200, Freddie Chopin wrote: Zach Welch pisze: So if I understand this right: 1) With jtag.c patch from Magnus, it works with short delays. 2) Without that patch, it requires long delays. Is that summary correct? No (; If there is ANY delay both versions (clean r1889 and patched r1889) work. When we talk about the clean version of OpenOCD, when there are no delays I cannot halt LPC2103 AFTER reset. When I apply Magnus' patch and there are no delays I cannot even reset. Assuming that I understand the above correctly: if jtag.c is patched, then this patch is not required? For current OpenOCD this patch is required anyway. But the lpc2103.cfg without those delays works fine with 0.1.0 (so around 1300) and probably worked fine with r1746. Applied as r1899. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SVF patch according to Johann's test
On Sat, 2009-05-23 at 02:05 +0800, SimonQian wrote: it only changes svf_check_tdo function, which is used to check tdo output with desired values. The patch will call buf_cmp_mask function to do the comparation instead of writing the loop code. The patch also fix a bug when data length is 32 bit(equal to sizeof(int)). Applied r1900. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Balloon board config and some queries
+++ David Brownell [2009-05-22 10:32 -0700]: On Friday 22 May 2009, Wookey wrote: 1) Is there any agreement that the reset info doesn't really belong in the board file because it depends on the dongle and wiring too, or is that an unusual case? An openocd.cfg file can source the dongle.cfg and board.cfg, then issue a new reset_config overriding any defaults. OK, that makes sense. default reset info in the cpu.cfg, possibly overridden in the board.cfg and then again in the top-level bring-it-all-together.cfg Reset handling does seem conceptually messy though So far as I can see that's intrinsic, rather than anything openocd can fix. ... and that's in addition to what seem like current bugs. At least some of the confusion could go away if there were JTAG commands to disable signals (SRST, RTCK, etc) at various levels (target, board, adapter). Hmm, you mean something could declare that it doesn't pass/expose signals. That would fit reality better. On the other hand it would mean the reset config was now defined as the concatenation of commands in various places and that might make it hard to find out what was going on in some circs. Worth thinking about though. Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove cmd_queue_cur_state
Looks good.
Michael
On Sat, May 23, 2009 at 11:08 PM, Zach Welch z...@superlucidity.net wrote:
Hi all,
The attached patch removes the cmd_queue_cur_state global variable,
replacing all uses with calls to tap_set_state() or tap_get_state().
While this seems completely trivial, I wanted to post it for review.
Any objections? All in favor?
Cheers,
Zach
---
jtag/jtag.c | 13 ++---
jtag/jtag.h | 3 +--
jtag/zy1000.c | 4 ++--
svf/svf.c | 9 ++---
target/arm11_dbgtap.c | 4 ++--
xsvf/xsvf.c | 4 ++--
6 files changed, 19 insertions(+), 18 deletions(-)
Index: src/jtag/zy1000.c
===
--- src/jtag/zy1000.c (revision 1893)
+++ src/jtag/zy1000.c (working copy)
@@ -709,7 +709,7 @@
int interface_jtag_add_clocks(int num_cycles)
{
- return zy1000_jtag_add_clocks(num_cycles, cmd_queue_cur_state,
cmd_queue_end_state);
+ return zy1000_jtag_add_clocks(num_cycles, tap_get_state(),
cmd_queue_end_state);
}
int interface_jtag_add_sleep(u32 us)
@@ -728,7 +728,7 @@
state_count = 0;
- tap_state_t cur_state=cmd_queue_cur_state;
+ tap_state_t cur_state = tap_get_state();
while (num_states)
{
Index: src/jtag/jtag.c
===
--- src/jtag/jtag.c (revision 1893)
+++ src/jtag/jtag.c (working copy)
@@ -94,7 +94,6 @@
enum reset_types jtag_reset_config = RESET_NONE;
tap_state_t cmd_queue_end_state = TAP_RESET;
-tap_state_t cmd_queue_cur_state = TAP_RESET;
int jtag_verify_capture_ir = 1;
int jtag_verify = 1;
@@ -565,7 +564,7 @@
if (state != TAP_INVALID)
jtag_add_end_state(state);
- cmd_queue_cur_state = cmd_queue_end_state;
+ tap_set_state(cmd_queue_end_state);
}
void jtag_add_ir_scan_noverify(int in_num_fields, const scan_field_t
*in_fields, tap_state_t state)
@@ -1066,7 +1065,7 @@
void jtag_add_pathmove(int num_states, const tap_state_t *path)
{
- tap_state_t cur_state = cmd_queue_cur_state;
+ tap_state_t cur_state = tap_get_state();
int i;
int retval;
@@ -1097,7 +1096,7 @@
jtag_prelude1();
retval = interface_jtag_add_pathmove(num_states, path);
- cmd_queue_cur_state = path[num_states - 1];
+ tap_set_state(path[num_states - 1]);
if (retval!=ERROR_OK)
jtag_error=retval;
}
@@ -1168,11 +1167,11 @@
void jtag_add_clocks( int num_cycles )
{
int retval;
-
- if( !tap_is_state_stable(cmd_queue_cur_state) )
+ tap_state_t cur_state = tap_get_state();
+ if( !tap_is_state_stable(cur_state) )
{
LOG_ERROR( jtag_add_clocks() was called with TAP in
non-stable state \%s\,
- tap_state_name(cmd_queue_cur_state) );
+ tap_state_name(cur_state) );
jtag_error = ERROR_JTAG_NOT_STABLE_STATE;
return;
}
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 1893)
+++ src/jtag/jtag.h (working copy)
@@ -256,7 +256,6 @@
extern tap_state_t cmd_queue_end_state; /* finish DR scans in
dr_end_state */
-extern tap_state_t cmd_queue_cur_state; /* current TAP state */
typedef void* error_handler_t; /* Later on we can delete error_handler_t,
but keep it for now to make patches more readable */
@@ -891,7 +890,7 @@
{
if (end_state != TAP_INVALID)
cmd_queue_end_state = end_state;
- cmd_queue_cur_state = cmd_queue_end_state;
+ tap_set_state(cmd_queue_end_state);
interface_jtag_add_dr_out(tap, num_fields, num_bits, value,
cmd_queue_end_state);
}
Index: src/target/arm11_dbgtap.c
===
--- src/target/arm11_dbgtap.c (revision 1893)
+++ src/target/arm11_dbgtap.c (working copy)
@@ -48,7 +48,7 @@
int arm11_add_ir_scan_vc(int num_fields, scan_field_t *fields, tap_state_t
state)
{
- if (cmd_queue_cur_state == TAP_IRPAUSE)
+ if (tap_get_state() == TAP_IRPAUSE)
jtag_add_pathmove(asizeof(arm11_move_pi_to_si_via_ci),
arm11_move_pi_to_si_via_ci);
jtag_add_ir_scan(num_fields, fields, state);
@@ -62,7 +62,7 @@
int arm11_add_dr_scan_vc(int num_fields, scan_field_t *fields, tap_state_t
state)
{
- if (cmd_queue_cur_state == TAP_DRPAUSE)
+ if (tap_get_state() == TAP_DRPAUSE)
jtag_add_pathmove(asizeof(arm11_move_pd_to_sd_via_cd),
arm11_move_pd_to_sd_via_cd);
jtag_add_dr_scan(num_fields, fields, state);
Index: src/xsvf/xsvf.c
===
--- src/xsvf/xsvf.c (revision 1893)
+++ src/xsvf/xsvf.c
[Openocd-development] [PATCH] Doxygen - build when SRCDIR != BLDDIR - it fails
See attached patch. Doxygen does not build if source dir != build dir. This patch fixes that. -Duane. Index: Makefile.am === --- Makefile.am (revision 1858) +++ Makefile.am (working copy) @@ -16,7 +16,7 @@ docs: pdf html doxygen doxygen:: - doxygen Doxyfile 21 | perl tools/logger.pl doxygen.log + cd $(srcdir) doxygen Doxyfile 21 | perl $(srcdir)/tools/logger.pl $(builddir)/doxygen.log doxygen-clean: rm -f -r doxygen doxygen.log ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Doxygen - build when SRCDIR != BLDDIR - it fails
On Sat, 2009-05-23 at 21:22 -0400, Duane Ellis wrote: See attached patch. Doxygen does not build if source dir != build dir. This patch fixes that. Does r1901 float your boat better? It's technically more correct, as far as I know. A PITA, but correct. ;) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Being careful not to brake anything is good but ...
On May 23, 2009, at 1:30 PM, Magnus Lundin wrote: Common people So much soul searching about a oneliner in jtag.c . Setting the current tap state with cmd_queue_cur_state = TAP_RESET is an obvious error as 5 minutes of code inspection in jtag.c will show you. The variable is not used in any dr/ir scan code, It is only used in jtag_add_path_move to find the start state, and for sanity check in jtag_add_clocks. It will be overwritten by the next call to jtag_prelude by any ir/dr scan, and all driver code uses tap_get_state() instead. Actually ALL uses of cmd_queue_cur_state should be retired and replaced by correct accessor function tap_get_state(), as it is now we have two variables tracing the current tap state, cmd_queue_cur_state and state_follower. I am not saying that nothing will change from this, it most probably will, but the old code is broken and perhaps it is time to fix it. Have a nice weekend Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I don't think anyone is soul searching or avoiding this because it in the jtag common code. I know I've been busy the past few days. I believe Zach passed on the issue since he isn't familiar with the code in any way. From what I've seen go by on the list, this has been tested and has either no immediate effect or a positive one. I plan to commit it, but not everyone is working on OpenOCD every day. -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Being careful not to brake anything is good but ...
On Sat, 2009-05-23 at 18:42 -0700, Rick Altherr wrote: On May 23, 2009, at 1:30 PM, Magnus Lundin wrote: Common people So much soul searching about a oneliner in jtag.c . Setting the current tap state with cmd_queue_cur_state = TAP_RESET is an obvious error as 5 minutes of code inspection in jtag.c will show you. The variable is not used in any dr/ir scan code, It is only used in jtag_add_path_move to find the start state, and for sanity check in jtag_add_clocks. It will be overwritten by the next call to jtag_prelude by any ir/dr scan, and all driver code uses tap_get_state() instead. Actually ALL uses of cmd_queue_cur_state should be retired and replaced by correct accessor function tap_get_state(), as it is now we have two variables tracing the current tap state, cmd_queue_cur_state and state_follower. I am not saying that nothing will change from this, it most probably will, but the old code is broken and perhaps it is time to fix it. Have a nice weekend Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I don't think anyone is soul searching or avoiding this because it in the jtag common code. I know I've been busy the past few days. I believe Zach passed on the issue since he isn't familiar with the code in any way. From what I've seen go by on the list, this has been tested and has either no immediate effect or a positive one. I plan to commit it, but not everyone is working on OpenOCD every day. Sorry, his patches committed in r1892 an r1893. I took a little time and looked at the changes in more depth and decided to take the risk, but I forgot to follow up here. I am slowly making my way through the list and finding things that have been missed or overlooked, back to when I posted my 'submit lost works' post. At this point, I have a system in place to make it unlikely for me to let any threads be forgotten, but I am still trying to catch all those that are still in the air. One thing you might look at is David's recent NAND changes ([patch] more NAND cleanup and doc updates), as those are beyond my casual knowledge. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Being careful not to brake anything is good but ...
On Sat, 2009-05-23 at 18:48 -0700, Zach Welch wrote: [snip] At this point, I have a system in place to make it unlikely for me to let any threads be forgotten, but I am still trying to catch all those that are still in the air. One thing you might look at is David's recent NAND changes ([patch] more NAND cleanup and doc updates), as those are beyond my casual knowledge. Also, I could use another opinion on my recent patch (suggested by Magnus): [PATCH] remove cmd_queue_cur_state Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Being careful not to brake anything is good but ...
On May 23, 2009, at 6:48 PM, Zach Welch wrote: On Sat, 2009-05-23 at 18:42 -0700, Rick Altherr wrote: On May 23, 2009, at 1:30 PM, Magnus Lundin wrote: Common people So much soul searching about a oneliner in jtag.c . Setting the current tap state with cmd_queue_cur_state = TAP_RESET is an obvious error as 5 minutes of code inspection in jtag.c will show you. The variable is not used in any dr/ir scan code, It is only used in jtag_add_path_move to find the start state, and for sanity check in jtag_add_clocks. It will be overwritten by the next call to jtag_prelude by any ir/dr scan, and all driver code uses tap_get_state() instead. Actually ALL uses of cmd_queue_cur_state should be retired and replaced by correct accessor function tap_get_state(), as it is now we have two variables tracing the current tap state, cmd_queue_cur_state and state_follower. I am not saying that nothing will change from this, it most probably will, but the old code is broken and perhaps it is time to fix it. Have a nice weekend Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I don't think anyone is soul searching or avoiding this because it in the jtag common code. I know I've been busy the past few days. I believe Zach passed on the issue since he isn't familiar with the code in any way. From what I've seen go by on the list, this has been tested and has either no immediate effect or a positive one. I plan to commit it, but not everyone is working on OpenOCD every day. Sorry, his patches committed in r1892 an r1893. I took a little time and looked at the changes in more depth and decided to take the risk, but I forgot to follow up here. I am slowly making my way through the list and finding things that have been missed or overlooked, back to when I posted my 'submit lost works' post. At this point, I have a system in place to make it unlikely for me to let any threads be forgotten, but I am still trying to catch all those that are still in the air. One thing you might look at is David's recent NAND changes ([patch] more NAND cleanup and doc updates), as those are beyond my casual knowledge. Cheers, Zach David's NAND changes were good to go. I just hadn't gotten to commit them yet. I had gone back through my backlog of emails and tried to catch any languishing patches as well. I _believe_ we are caught up and functionally complete for a 0.2.0 release. -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] davinci NAND for OpenOCD
On Fri, 2009-05-22 at 10:43 -0700, David Brownell wrote: NAND support for DaVinci-family drivers, with HW ECC support. Declare the NAND chip on the DM355 EVM board. Currently tested on DM355 for Linux interop using the standard large page (2KB) chip in the EVM socket; hwecc1 and hwecc4 work fine. (Using hwecc4 relies on patches that haven't quite made it through the Linux-MTD bottlenecks yet.) Not yet tested: 1-bit on small-page (although it's hard to see how that could fail); 4-bit on small page (picky layout issues); the hwecc_infix mode (primarily for older boot ROMs; testing there is blocked on having new bootloader code). --- doc/openocd.texi | 17 src/flash/Makefile.am |2 src/flash/davinci_nand.c | 744 src/flash/nand.c |2 src/target/board/dm355evm.cfg | 12 5 files changed, 774 insertions(+), 3 deletions(-) Committed as r1903. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] more NAND cleanup and doc updates
On Fri, 2009-05-22 at 20:28 -0700, David Brownell wrote:
Update two oddball NAND commands to work with {offset, length}
instead of block numbers, matching the other commands as well
as usage in U-Boot and the Linux-MTD utilities.
Document them accordingly. Update the single in-tree use of
those commands (sheevaplug).
ALSO:
(a) Document the current 2 GByte/chip ceiling for NAND chipsize.
(32 bit offset/length values can't represent 4 GBytes.) Maybe
after the upcoming release, the code can switch to 64-bits.
(b) The nand check_bad_blocks should report bad blocks. They
are not invalid blocks; they're bad ones.
(c) Tweak the nand info command to handle the no arguments
case sanely (show everything, instead of showing garbage) and
not listing the blocksize in hex kbytes (duh).
---
doc/openocd.texi| 37 +++-
src/flash/nand.c| 109 ++
src/target/board/sheevaplug.cfg |2
3 files changed, 109 insertions(+), 39 deletions(-)
Committed as r1904.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] make SheevaPlug init more reliable
When the CPU is in the WFI state, the JTAG interface simply doesn't
respond at all and initial tap examination simply fails. Let's simply
do it again when we come around to assert nSRST.
diff --git a/src/target/board/sheevaplug.cfg b/src/target/board/sheevaplug.cfg
index 276d6f2..d1a0cce 100644
--- a/src/target/board/sheevaplug.cfg
+++ b/src/target/board/sheevaplug.cfg
@@ -17,7 +17,13 @@ proc sheevaplug_init { } {
# We need to assert DBGRQ while holding nSRST down.
# However DBGACK will be set only when nSRST is released.
+ # Furthermore, the JTAG interface doesn't respond at all when
+ # the CPU is in the WFI (wait for interrupts) state, so it is
+ # possible that initial tap examination failed. So let's
+ # re-examine the target again here when nSRST is asserted which
+ # should then succeed.
jtag_reset 0 1
+ feroceon.cpu arp_examine
halt 0
jtag_reset 0 0
wait_halt
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] make SheevaPlug init more reliable
On Sat, 2009-05-23 at 21:59 -0400, Nicolas Pitre wrote: When the CPU is in the WFI state, the JTAG interface simply doesn't respond at all and initial tap examination simply fails. Let's simply do it again when we come around to assert nSRST. Committed as r1905. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] more NAND cleanup and doc updates
On Sat, 23 May 2009, Zach Welch wrote:
On Fri, 2009-05-22 at 20:28 -0700, David Brownell wrote:
Update two oddball NAND commands to work with {offset, length}
instead of block numbers, matching the other commands as well
as usage in U-Boot and the Linux-MTD utilities.
Document them accordingly. Update the single in-tree use of
those commands (sheevaplug).
ALSO:
(a) Document the current 2 GByte/chip ceiling for NAND chipsize.
(32 bit offset/length values can't represent 4 GBytes.) Maybe
after the upcoming release, the code can switch to 64-bits.
(b) The nand check_bad_blocks should report bad blocks. They
are not invalid blocks; they're bad ones.
(c) Tweak the nand info command to handle the no arguments
case sanely (show everything, instead of showing garbage) and
not listing the blocksize in hex kbytes (duh).
---
doc/openocd.texi| 37 +++-
src/flash/nand.c| 109
++
src/target/board/sheevaplug.cfg |2
3 files changed, 109 insertions(+), 39 deletions(-)
Committed as r1904.
FWIW, I just reviewed and tested those changes, and they are fine.
Nicolas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] FT2232H / FT2242H support for D2XX driver
On Wed, 2009-05-20 at 22:59 -0700, Zach Welch wrote:
On Wed, 2009-05-20 at 22:54 -0700, Rick Altherr wrote:
On May 20, 2009, at 10:31 PM, Zach Welch wrote:
On Wed, 2009-05-20 at 22:23 -0700, Rick Altherr wrote:
On Mar 25, 2009, at 2:54 PM, joern kaipf wrote:
* autodetection if FS or HS device attachted - adapt tck max
* enable adaptive clocking if HS device attached and jtag_khz = 0 in
cfg (not
tested yet)
Note:
The HS devices are currently only support by the drivers from FTDI
and not
from the libftdi. So using libftdi and RTCK support will cause a
error
message.
ft2232.patch___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
This doesn't appear to have been applied, but doesn't apply cleanly
to
HEAD. Is there an updated version available?
I cleaned it up and posted it here:
https://lists.berlios.de/pipermail/openocd-development/2009-April/005479.html
It probably needs a little more work.
Cheers,
Zach
It looks like even _that_ version doesn't apply cleanly since the last
batch of updates to the ft2232 driver.
Bummer, but that is where I would start development. I recommend
applying it to the old revision ('svn up -r${PATCH_REV}') then letting
SVN help with the merge through an 'svn up'. You are probably more
familiar with the code and can figure out what to do better than I.
Whoops... looks like this patch almost slipped through the cracks.
I will take a stab at it shortly and repost it, unless you started it.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Broken r1870 (head)
On Fri, 2009-05-22 at 10:57 +0200, Øyvind Harboe wrote:
Trying again...
My editor is screwing things up with whitespace, hence all those irrelevant
changes...
The second attempt was no better. Here it is done right.
Please let me know if this fixes things, and I will get it committed.
Cheers,
Zach
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 1903)
+++ src/target/cortex_m3.c (working copy)
@@ -1426,6 +1426,12 @@
cortex_m3_common_t *cortex_m3 = armv7m-arch_info;
swjdp_common_t *swjdp = armv7m-swjdp_info;
+ if (!cortex_m3-jtag_info.tap-enabled)
+ {
+ LOG_ERROR(Can not examine target %s, TAP not enabled yet,
target-type-name);
+ return ERROR_FAIL;
+ }
+
if ((retval = ahbap_debugport_init(swjdp)) != ERROR_OK)
return retval;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, 2009-05-23 at 03:57 -0700, David Brownell wrote: I am also thinking that the USB timeout value may be extended a bit longer. Right now it is 1000ms. Should be ok. But may not be ok for people using VM or similar. The problem with this is that it slows down the failure process when something is actually broken. I think more intelligence is needed, not just a different default setting. Considering that USB bulk transfers are best effort and might easily be delayed by concurrent activity to a USB disk or webcam ... a single second seems absurdly short. Even if the device were guaranteed to be able to respond that quickly. Right, but that does not mean we should simply throw the program into a blocking call with a longer timeout. I would rather see the device make a try using a _shorter_ timeout and allow for other processing to occur in between retries. That other work might be something as simple as a progress bar, but we could take this design a step further. It is not hard to imagine introducing the ability for the interface to attempt endless retries, requiring the user to cancel the request interactively (or kill the program outright). Or does this seem silly? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Balloon board config and some queries
On Saturday 23 May 2009, Wookey wrote: At least some of the confusion could go away if there were JTAG commands to disable signals (SRST, RTCK, etc) at various levels (target, board, adapter). Hmm, you mean something could declare that it doesn't pass/expose signals. That would fit reality better. By design. :) On the other hand it would mean the reset config was now defined as the concatenation of commands in various places and that might make it hard to find out what was going on in some circs. It's not like it's easy to sort out today! Such commands would necessarily be of the only befor init category, so there are things that could be done to help track it down. Like emitting a debug message when init runs, and recording the name of the script which sayd we don't have TRST. Worth thinking about though. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Being careful not to brake anything is good but ...
On Saturday 23 May 2009, Zach Welch wrote: At this point, I have a system in place to make it unlikely for me to let any threads be forgotten, Some Linux groups use a new tool called patchwork which monitors mailing lists for patches... http://ozlabs.org/~jk/projects/patchwork/ Purely FYI. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Correct script to flash the lpc-2148
Relative long email.
I have not tried to use flashing so far. So today I tried to learn how to
flash the LPC2148 on board of the Olimex LPC-P2148.
I tried to halt the target and then use
flash write_image isoc_io_sample.hex 0x0 ihex but this does
not seem to work. Then I tried to use the following script from psas
(in part or in full, dcc or non-dcc)
http://www.linuxjournal.com/article/10421
#*
# open ocd (on chip debugger) script to flash lpc2148
# 'info .../OCD/src/openocd/doc/openocd.info'
# 3 is most. 0 is least info.
debug_level 1
# stop
reset halt
# log file
log_output write_flash.log
# pause...500mS
sleep 500
# current state
poll
# Force ARM7 into supervisor mode
reg cpsr 0x13
# mww: Memory word write
# Set the MEMMAP reg to point to flash (avoids problems while trying to flash)
mww 0xE01FC040 1
###
# * arm7_9 dcc_downloads ENABLE|DISABLE Enable the use of the debug
# communications channel (DCC) to write larger (128 byte) amounts
# of memory. DCC downloads offer a huge speed increase, but might be
# potentially unsafe, especially with targets running at a very low
# speed. This command was introduced with OpenOCD rev. 60.
arm7_9 dcc_downloads enable
# Wait for target to enter debug mode. Default time is 5ms.
wait_halt
# pause
sleep 10
# current state
poll
# identify the flash
flash probe 0
# erase first bank only:
flash erase_sector 0 0 26
# pause
sleep 20
# memory display halfword from address [COUNT]
mdh 0x0 30
# pause
sleep 20
###
# * flash write_image [ERASE] FILE [OFFSET] [TYPE] Write the image
# FILE to the current target's flash bank(s). A relocation
# [OFFSET] can be specified and the file [TYPE] can be specified
# explicitly as `bin' (binary), `ihex' (Intel hex), `elf' (ELF file)
# or `s19' (Motorola s19). Flash memory will be erased prior to
# programming if the `erase' parameter is given.
flash write_image isoc_io_sample.hex 0x0 ihex
#flash write_image serial.hex 0x0
#flash erase write_image serial.hex 0x0
#flash write_image serial.elf 0x0 elf
#flash write_image serial.hex 0x0 ihex
#flash write_image serial.bin 0x0 bin
# pause
sleep 20
# memory display halfword from address [COUNT]
mdh 0x0 30
# pause
sleep 20
# can't verify because of 0x14 reserved chksum address (LPC SPEC)
#verify_image serial.hex 0x0 bin
# memory display halfword from address [COUNT]
mdh 0x0 30
# pause
sleep 20
#reset run_and_halt
reset
halt
# pause
sleep 10
# stop the open ocd daemon.
#shutdown
#*
The flashing seem to be successful but the target is not working.
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x805f pc: 0x088c
cpsr (/32): 0x0013
dcc downloads are enabled
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x0013 pc: 0x088c
flash 'lpc2000' found at 0x
erased sectors 0 through 26 on flash bank 0 in 0.256274s
0x:
0x0020:
wrote 8036 byte from file isoc_io_sample.hex in 1.586009s (4.948053 kb/s)
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f
e1a0 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f
e1a0 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
Error: invalid mode value encountered
Error: cpsr contains invalid mode value - communication failure
Runtime error, file oocd_flash_lpc2148.script, line 96:
Warn : DBGACK set while target was in unknown state. Reset or
initialize target.
Error: invalid mode value encountered
Error: cpsr contains invalid mode value - communication failure
Warn : DBGACK set while target was in unknown state. Reset or initialize target.
... (keeps the same error)
After this error, I have to unplug everything and then use lpc21isp
to flash the target so that I can run OpenOCD again with J-Link V3.
I know the hex is correct since the target works when flashing
with lpc21isp. The hex file is built from the lpcusb project and
tested with the Linux host program from psas.
What is the correct step to flash the LPC2148?
--
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Sun, May 24, 2009 at 11:18 AM, Xiaofan Chen xiaof...@gmail.com wrote: After this error, I have to unplug everything and then use lpc21isp to flash the target so that I can run OpenOCD again with J-Link V3. I know the hex is correct since the target works when flashing with lpc21isp. The hex file is built from the lpcusb project and tested with the Linux host program from psas. [mc...@acerpc jlinkv3]$ sh lpc21isp.sh lpc21isp version 1.63 File isoc_io_sample.hex: loaded... converted to binary format... image size : 8036 Synchronizing (ESC to abort). OK Read bootcode version: 11 2 Read part ID: LPC2148, 512 kiB ROM / 40 kiB SRAM (0x402FF25) Will start programming at Sector 1 if possible, and conclude with Sector 0 to ensure that checksum is written last. Sector 1: ... Sector 0: ... Download Finished... taking 9 seconds Now launching the brand new code [mc...@acerpc jlinkv3]$ openocd -f myopenocd.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-24-08:11) svn:1898 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ jtag_speed: 20 RCLK - adaptive Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Info : JLink hw version 3 Info : Vref = 3.269 TCK = 1 TDI = 1 TDO = 0 TMS = 1 SRST = 1 TRST = 255 Info : J-Link JTAG Interface ready Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched Info : accepting 'telnet' connection from 0 target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x805f pc: 0x085c Debug: 32 47270 command.c:88 script_command(): script_command - reset Debug: 33 47270 command.c:105 script_command(): script_command - reset, argv[0]=ocd_reset Debug: 34 47270 command.c:105 script_command(): script_command - reset, argv[1]=halt Debug: 35 47271 target.c:3969 jim_target(): Target command params: Debug: 36 47271 target.c:3970 jim_target(): target names Debug: 37 47271 target.c:3103 target_handle_event(): event: 11 reset-start - no action Debug: 38 47271 jtag.c:2416 jtag_init_reset(): Trying to bring the JTAG controller to life by asserting TRST / RESET Debug: 39 47271 jlink.c:488 jlink_reset(): trst: 1, srst: 0 Debug: 40 47277 jtag.c:1264 jtag_add_reset(): SRST line released Debug: 41 47277 jtag.c:1283 jtag_add_reset(): TRST line asserted Debug: 42 47277 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 43 47277 jtag.c:1630 jtag_reset_callback(): - Debug: 44 47478 jlink.c:488 jlink_reset(): trst: 1, srst: 1 Debug: 45 47482 jtag.c:1260 jtag_add_reset(): SRST line asserted Debug: 46 47483 jtag.c:1283 jtag_add_reset(): TRST line asserted Debug: 47 47483 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 48 47483 jtag.c:1630 jtag_reset_callback(): - Debug: 49 47483 jlink.c:488 jlink_reset(): trst: 0, srst: 0 Debug: 50 47496 jtag.c:1264 jtag_add_reset(): SRST line released Debug: 52 47920 jtag.c:2383 jtag_init_inner(): Init JTAG chain Debug: 53 47922 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 54 47922 jtag.c:1630 jtag_reset_callback(): - Info : 55 47929 jtag.c:1751 jtag_examine_chain(): JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : 56 47930 jtag.c:1789 jtag_examine_chain(): JTAG Tap/device matched Debug: 57 47930 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 58 47930 jtag.c:1630 jtag_reset_callback(): - Debug: 59 47933 target.c:3969 jim_target(): Target command params: Debug: 60 47933 target.c:3970 jim_target(): target names Debug: 61 47941 embeddedice.c:363 embeddedice_write_reg(): 0: 0x Debug: 62 47943 embeddedice.c:363 embeddedice_write_reg(): 12: 0x Debug: 63 47943 embeddedice.c:363 embeddedice_write_reg(): 20: 0x Debug: 64 47948 target.c:3969 jim_target(): Target command params: Debug: 65 47948 target.c:3970 jim_target(): target names Debug: 66 47948 target.c:3103 target_handle_event(): event: 12 reset-assert-pre - no action Debug: 67 47948 arm7_9_common.c:976 arm7_9_assert_reset(): target-state: halted Debug: 68 47948 embeddedice.c:363 embeddedice_write_reg(): 8: 0x Debug: 69 47948 embeddedice.c:363 embeddedice_write_reg(): 9: 0x0003 Debug: 70 47949 embeddedice.c:363 embeddedice_write_reg(): 11: 0x Debug: 71 47949 embeddedice.c:363 embeddedice_write_reg(): 12: 0x0100 Debug: 72 47949 embeddedice.c:363 embeddedice_write_reg(): 13: 0x00f7 Debug: 73 47952 jlink.c:488 jlink_reset(): trst: 1, srst: 1 Debug: 74 47958 jtag.c:1260 jtag_add_reset():
Re: [Openocd-development] Being careful not to brake anything is good but ...
On Sat, 2009-05-23 at 20:16 -0700, David Brownell wrote: On Saturday 23 May 2009, Zach Welch wrote: At this point, I have a system in place to make it unlikely for me to let any threads be forgotten, Some Linux groups use a new tool called patchwork which monitors mailing lists for patches... http://ozlabs.org/~jk/projects/patchwork/ Purely FYI I like it (even if I'd have written it in Perl), but I am actually tracking more than patches. I am trying to make sure that all issues get resolved, regardless of whether they have a patch related to them. My system is still evolving though; it remains more ad hoc than I like. Still look at the possibility of a bug tracker too. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Saturday 23 May 2009, Zach Welch wrote: Considering that USB bulk transfers are best effort and might easily be delayed by concurrent activity to a USB disk or webcam ... a single second seems absurdly short. Even if the device were guaranteed to be able to respond that quickly. Right, but that does not mean we should simply throw the program into a blocking call with a longer timeout. I would rather see the device make a try using a _shorter_ timeout and allow for other processing to occur in between retries. Retry? I'd rather see the event loops structured better, so that each activity gets its own thread. That would move from those error-prone presumptions that manually timesliced event loops can scale. I see messages about needing to increase some GDB timeout/interval. But that's foolishness, since I'm not even working with GDB when they start spamming me. The core problem has nothing to do with GDB, and everything to do with a weak concurrency model. Too bad that can't be fixed before the next release. ;) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Adding simulated target support for regression testing purposes
On Saturday 23 May 2009, Zach Welch wrote:
.
One point could be the RESET signals SRST and TRST. Here the
FT2232 can set both signals at the same time, which I think
is used too.
Yeah, I noticed that *sometimes* an ft2232 adapter was able
to come up OK ... but other times it needed a reset.
I was wondering if the issue was maybe that the JTAG link
wasn't getting properly reset ... either by TRST or some
other process.
This seems highly buglike to me.
Has this problem been resolved in r18{90,92,93}?
I was running with the ft2232 and jtag patches ('92, '93),
and they didn't seem to resolve that issue. It was still
not guaranteed that the server could start up properly
without a reset in the recent past. It's not clear if
they changed anything I was noticing (or not).
Newish behavior: doing a reset later doesn't necessarily
fix things. scan_chain stays the same. Need to abort
the server, then restart it.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, 2009-05-23 at 21:06 -0700, David Brownell wrote: On Saturday 23 May 2009, Zach Welch wrote: Considering that USB bulk transfers are best effort and might easily be delayed by concurrent activity to a USB disk or webcam ... a single second seems absurdly short. Even if the device were guaranteed to be able to respond that quickly. Right, but that does not mean we should simply throw the program into a blocking call with a longer timeout. I would rather see the device make a try using a _shorter_ timeout and allow for other processing to occur in between retries. Retry? Well, I am thinking of the J-Link code in particular, which I suppose is more of a continuation condition. I'd rather see the event loops structured better, so that each activity gets its own thread. That would move from those error-prone presumptions that manually timesliced event loops can scale. I like the idea of threads, but that opens a new dimension of problems for embedded systems (though none supported... today). It would be nice to be able to run OpenOCD in a single thread. I see messages about needing to increase some GDB timeout/interval. But that's foolishness, since I'm not even working with GDB when they start spamming me. The core problem has nothing to do with GDB, and everything to do with a weak concurrency model. I agree. This is what I meant by retries. If we're working on the single thread model, no event/action can be allowed to take more than MAX_TIME_SLICE, or you see those sorts of problems. I thought that libusb worked in non-blocking mode, but perhaps I was wrong Too bad that can't be fixed before the next release. ;) Yeah. These are Big Changes. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] 0.2.0 Status Report
Hi all, At this point, I believe almost all of the outstanding patches have been brought up-to-date and applied to the trunk, with the two following exceptions: - FTD2XX high-speed device support - remove cmd_queue_cur_state - add target examination check in cortex m3 The following issues have been reported and should try to be resolved: - reset issues (possibly regressions due to 1890, 1892, and 1893) - flashing on LPC-P2148 (Xiaofan Chen) - LPC2000 series problems - others? Cheers, Zach Welch Corvallis, OR ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] 0.2.0 Pending RFCs
Hi all, The following RFC proposals are still on the table and need resolution: 1) library header file rework: a) rename src/ as openocd/ (preferred) - this will allow public #include, e.g. openocd/jtag/jlink.h b) do not rename src, e.g. #include jtag/jlink.h - something needs to be done; the library work is only half-complete - i have a patch for unit tests, based on this external interface - http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04077.html 2) move board, target, and interface Jim script directories to src/tcl/ - this will move the whole directories intact, parallel to tcl/chip. - more structure can be added, if we see fit; this is a small step. - http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04685.html 3) move src/tcl to tcl/ - aims to cleanly separate the C and TCL code trees - http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04699.html 4) change location of installed files: - RPM packaging exposed filesystem standards conformance issues. - need to resolve the list of changes to make, to do during the above. - http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04626.html 5) commit testing tools - one-step smoke tests! I probably need another week for this. - all in-tree with no new dependencies (maybe a Perl module or two) - http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04030.html Most of these are fairly trivial for me to do, and I think most or all are worth doing for 0.2.0. I can ensure that the transformations are done gradually and are well-documented by their commit comments. Further, I will update these path references in the documentation. Either way, I want to know the community's desires in these matters. Cheers, Zach Welch Corvallis, OR P.S. There are other pending RFCS, but they do not seem 0.2.0 material. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
