[Openocd-development] Fwd: Delivery Status Notification (Failure)
-- Forwarded message -- From: Mail Delivery Subsystem mailer-dae...@googlemail.com Date: 15 December 2011 16:14 Subject: Delivery Status Notification (Failure) To: axo...@gmail.com Delivery to the following recipient failed permanently: openocd-de...@lists.sourceforge.net Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 unknown user (state 14). - Original message - MIME-Version: 1.0 Received: by 10.180.18.135 with SMTP id w7mr5559834wid.55.1323962080733; Thu, 15 Dec 2011 07:14:40 -0800 (PST) Received: by 10.227.27.203 with HTTP; Thu, 15 Dec 2011 07:14:40 -0800 (PST) In-Reply-To: CAHHcNofEe_e=g8z9GVX+j99x=bbqtgos9+hzheusgwm_uqd...@mail.gmail.com References: CAHHcNofEe_e=g8z9GVX+j99x=bbqtgos9+hzheusgwm_uqd...@mail.gmail.com Date: Thu, 15 Dec 2011 16:14:40 +0100 Message-ID: cahhcnofwewdycsysa2sgqmyopa9zdymggyy_kocqxpjovfn...@mail.gmail.com Subject: Fwd: LPC1768 test for swd From: Akos Vandra axo...@gmail.com To: openocd-de...@lists.sourceforge.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable -- Forwarded message -- From: Akos Vandra axo...@gmail.com Date: 15 December 2011 16:13 Subject: LPC1768 test for swd To: openocd-de...@lists.sourceforge.net, Tomek CEDRO tomek.ce...@gmail.com Hi! I just started trying out the swd mode for an lpc1768. However it does not work unfortunately. I haven't had the time to dig deep into the code yet, but I keep getting an ACK with value 0, even though this ACK value is undefined in the header files. I'm not sure if this help a lot, but I'll try to dig deeper when I have the time. My output: akos@FM12BQ:~/Downloads/openocd-libswd-git4/libswd$ src/openocd -s tcl -f openocd-swd.cfg Open On-Chip Debugger 0.5.0-dev-g918cd08-dirty (2011-12-08-12:15) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'swd' adapter_nsrst_delay: 200 10 kHz 10 kHz Info : KT-LINK SWD-Mode initialization complete... Info : max TCK change to: 3 kHz Info : clock speed 10 kHz SWD_N: Using libswd master-GIT-devel (http://libswd.sf.net) SWD_N: (c) Tomasz Boleslaw CEDRO (http://www.tomek.cedro.info) Info : New SWD context initialized at 0x0x2593230 SWD_I: Executing swd_dap_activate(swdctx=@0x2593230, operation=SWD_OPERATION_EXECUTE) SWD_I: Executing swd_dap_reset(swdctx=@0x2593230, operation=SWD_OPERATION_EXECUTE) SWD_I: Executing swd_dp_read_idcode(swdctx=@0x2593230, operation=SWD_OPERATION_EXECUTE) SWD_E: swd_drv_transmit(swdctx=@0x0x2593230, cmd=@0x0x2593780, ack=0): Unknown ACK detected! DAP Stalled or Target Powered Down...? SWD_E: swd_drv_transmit(swdctx=@0x0x2593230, cmd=@0x0x2593780): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_dap_detect() error -16 ([SWD_ERROR_ACK] acknowledge error) in procedure 'transport' Runtime Error: openocd-swd.cfg:4: in procedure 'script' at file embedded:startup.tcl, line 58 in procedure 'init' called at file openocd-swd.cfg, line 4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: Delivery Status Notification (Failure)
Hi! Sorry for my last letter, my target really was powered down. (OOPS) However, now I am getting a succ. IDCODE read, but after that openocd enters an endless loop. Ouptut: akos@FM12BQ:~/Downloads/openocd-libswd-git4/libswd$ src/openocd -s tcl -f openocd-swd.cfg Open On-Chip Debugger 0.5.0-dev-g918cd08-dirty (2011-12-08-12:15) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'swd' adapter_nsrst_delay: 200 10 kHz 10 kHz Info : KT-LINK SWD-Mode initialization complete... Info : max TCK change to: 3 kHz Info : clock speed 10 kHz SWD_N: Using libswd master-GIT-devel (http://libswd.sf.net) SWD_N: (c) Tomasz Boleslaw CEDRO (http://www.tomek.cedro.info) Info : New SWD context initialized at 0x0x917210 SWD_I: Executing swd_dap_activate(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE) SWD_I: Executing swd_dap_reset(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE) SWD_I: Executing swd_dp_read_idcode(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE) SWD_I: swd_dp_read_idcode(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE, **idcode=0x2BA01477/001010111011010001110111). Info : SWD transport initialization complete. Found IDCODE=0x2BA01477. Info : Selecting SWD transport command set. SWD_I: swd_dp_read(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE, addr=0x4, **data=0xF003/0011). SWD_I: swd_dp_read(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE, addr=0x4, **data=0xF001/0001). SWD_I: swd_dp_read(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE, addr=0x4, **data=0xF000/). SWD_I: swd_dp_read(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE, addr=0x4, **data=0xF000/). SWD_I: swd_dp_read(swdctx=@0x917210, operation=SWD_OPERATION_EXECUTE, addr=0x4, **data=0xF001/0001). SWD_W: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x9184b0): SWD_ACK_WAIT detectd! SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x9184b0): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_ap_read() error: [SWD_ERROR_ACK_WAIT] got ACK_WAIT response SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918570, ack=7): Unknown ACK detected! DAP Stalled or Target Powered Down...? SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918570): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_dp_read() error: [SWD_ERROR_ACK] acknowledge error Error: Cannot read CTRL/STAT! SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918630, ack=7): Unknown ACK detected! DAP Stalled or Target Powered Down...? SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918630): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_ap_read() error: [SWD_ERROR_ACK] acknowledge error SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x917990, ack=7): Unknown ACK detected! DAP Stalled or Target Powered Down...? SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x917990): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_dp_read() error: [SWD_ERROR_ACK] acknowledge error Error: Cannot read CTRL/STAT! SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x917a50, ack=7): Unknown ACK detected! DAP Stalled or Target Powered Down...? SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x917a50): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_ap_read() error: [SWD_ERROR_ACK] acknowledge error SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918a30, ack=7): Unknown ACK detected! DAP Stalled or Target Powered Down...? SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918a30): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_dp_read() error: [SWD_ERROR_ACK] acknowledge error Error: Cannot read CTRL/STAT! SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918af0, ack=7): Unknown ACK detected! DAP Stalled or Target Powered Down...? SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918af0): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_ap_read() error: [SWD_ERROR_ACK] acknowledge error SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918bb0, ack=7): Unknown ACK detected! DAP Stalled or Target Powered Down...? SWD_E: swd_drv_transmit(swdctx=@0x0x917210, cmd=@0x0x918bb0): Bad ACK, clearing cmdq tail to preserve synchronization... Error: swd_dp_read() error: [SWD_ERROR_ACK] acknowledge error Error: Cannot read CTRL/STAT! Regards, Ákos Vandra On 15 December 2011 16:33, Spencer Oliver s...@spen-soft.co.uk wrote: On 15 December 2011 15:15, Akos Vandra axo...@gmail.com wrote: -- Forwarded message -- From: Mail Delivery Subsystem mailer-dae...@googlemail.com Date: 15 December 2011 16:14 Subject: Delivery Status Notification (Failure) To: axo...@gmail.com Delivery to the following recipient failed permanently
Re: [Openocd-development] LPC1768 test for swd
: 190 617 interface.c:41 oocd_interface_signal_find(): Searching for signal RnW Debug: 191 617 interface.c:62 oocd_interface_signal_find(): Signal RnW already exists. Debug: 192 621 ft2232.c:733 ft2232_transfer(): ft2232_transfer(device=@(nil), bits=1, mosidata=@0x746520, misodata=@0x746520, nLSDfirst=0) SWD_P: swd_drv_transmit(swdctx=@0x0x19c06c0, cmd=@0x0x19c0d70) bits=1 cmdtype=MISO_TRN returns=1 payload=0x0001 (0001) Debug: 193 623 ft2232.c:733 ft2232_transfer(): ft2232_transfer(device=@(nil), bits=3, mosidata=@0x746588, misodata=@0x746590, nLSDfirst=0) Debug: 194 629 swd_libswd_drv_openocd.c:124 swd_drv_miso_8(): OpenOCD's swd_drv_miso_8(swdctx=@0x19c06c0, cmd=@0x19c0da0, data=@0x19c0da0, bits=3, nLSBfirst=0x00) reads: 0x01 SWD_P: swd_drv_transmit(swdctx=@0x0x19c06c0, cmd=@0x0x19c0da0) bits=3 cmdtype=MISO_ACK returns=3 payload=0x0001 (0001) Debug: 195 629 ft2232.c:733 ft2232_transfer(): ft2232_transfer(device=@(nil), bits=32, mosidata=@0x746540, misodata=@0x746560, nLSDfirst=0) Debug: 196 693 swd_libswd_drv_openocd.c:152 swd_drv_miso_32(): OpenOCD's swd_drv_miso_32(swdctx=@0x19c06c0, cmd=@0x19c0f90, data=@0x19c0f90, bits=32, nLSBfirst=0x00) reads: 0xF001 Debug: 197 693 swd_libswd_drv_openocd.c:153 swd_drv_miso_32(): OpenOCD's swd_drv_miso_32() reads: 0xF001 SWD_P: swd_drv_transmit(swdctx=@0x0x19c06c0, cmd=@0x0x19c0f90) bits=32 cmdtype=MISO_DATAreturns=32 payload=0xf001 (0001) Debug: 198 693 ft2232.c:733 ft2232_transfer(): ft2232_transfer(device=@(nil), bits=1, mosidata=@0x746588, misodata=@0x746590, nLSDfirst=0) Debug: 199 695 swd_libswd_drv_openocd.c:124 swd_drv_miso_8(): OpenOCD's swd_drv_miso_8(swdctx=@0x19c06c0, cmd=@0x19c0fc0, data=@0x19c0fc0, bits=1, nLSBfirst=0x00) reads: 0x01 SWD_P: swd_drv_transmit(swdctx=@0x0x19c06c0, cmd=@0x0x19c0fc0) bits=1 cmdtype=MISO_PARITY returns=1 payload=0x0001 (0001) SWD_I: swd_dp_read(swdctx=@0x19c06c0, operation=SWD_OPERATION_EXECUTE, addr=0x4, **data=0xF001/0001). Debug: 200 695 swd_libswd_drv_openocd.c:167 swd_drv_mosi_trn(): OpenOCD's swd_drv_mosi_trn(swdctx=@0x19c06c0, bits=1) Debug: 201 695 interface.c:41 oocd_interface_signal_find(): Searching for signal RnW Debug: 202 695 interface.c:62 oocd_interface_signal_find(): Signal RnW already exists. Debug: 203 696 ft2232.c:733 ft2232_transfer(): ft2232_transfer(device=@(nil), bits=1, mosidata=@0x746528, misodata=@0x746528, nLSDfirst=0) SWD_P: swd_drv_transmit(swdctx=@0x0x19c06c0, cmd=@0x0x19c0ff0) bits=1 cmdtype=MOSI_TRN returns=1 payload=0x () Debug: 204 697 swd_libswd_drv_openocd.c:55 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x19c06c0, cmd=@0x19c1020, data=0xFFA9, bits=8, nLSBfirst=0x00) Debug: 205 697 ft2232.c:733 ft2232_transfer(): ft2232_transfer(device=@(nil), bits=8, mosidata=@0x7465e8, misodata=@0x7465f0, nLSDfirst=0) SWD_D: Sending Request: W DP Addr=01/([CTRL/STAT] or WCR) Parity=1 SWD_P: swd_drv_transmit(swdctx=@0x0x19c06c0, cmd=@0x0x19c1020) bits=8 cmdtype=MOSI_REQUEST returns=8 payload=0xffa9 (10101001) Debug: 206 713 swd_libswd_drv_openocd.c:194 swd_drv_miso_trn(): OpenOCD's swd_drv_miso_trn(swdctx=@0x19c06c0, bits=1) Debug: 207 713 interface.c:41 oocd_interface_signal_find(): Searching for signal RnW Debug: 208 713 interface.c:62 oocd_interface_signal_find(): Signal RnW already exists. Debug: 209 717 ft2232.c:733 ft2232_transfer(): ft2232_transfer(device=@(nil), bits=1, mosidata=@0x746520, misodata=@0x746520, nLSDfirst=0) SWD_P: swd_drv_transmit(swdctx=@0x0x19c06c0, cmd=@0x0x19c1050) bits=1 cmdtype=MISO_TRN returns=1 payload=0x0001 (0001) Debug: 210 719 ft2232.c:733 ft2232_transfer(): ft2232_transfer(device=@(nil), bits=3, mosidata=@0x746588, misodata=@0x746590, nLSDfirst=0) Debug: 211 725 swd_libswd_drv_openocd.c:124 swd_drv_miso_8(): OpenOCD's swd_drv_miso_8(swdctx=@0x19c06c0, cmd=@0x19c1080, data=@0x19c1080, bits=3, nLSBfirst=0x00) reads: 0x01 SWD_P: swd_drv_transmit(swdctx=@0x0x19c06c0, cmd=@0x0x19c1080) bits=3 cmdtype=MISO_ACK returns=3 payload=0x0001 (0001) Debug: 212 725 swd_libswd_drv_openocd.c:167 swd_drv_mosi_trn(): OpenOCD's swd_drv_mosi_trn(swdctx=@0x19c06c0, bits=1) On 15 December 2011 22:29, Tomek CEDRO tomek.ce...@gmail.com wrote: Thanks for testing Akos :-) Please set debug_level 3 then we can see the bitflow :-) On Thu, Dec 15, 2011 at 3:13 PM, Akos Vandra axo...@gmail.com wrote: Hi! I just started trying out the swd mode for an lpc1768. However it does not work unfortunately. I haven't had the time to dig deep into the code yet, but I keep getting an ACK with value 0, even though this ACK value is undefined in the header files. I'm not sure if this help a lot, but I'll try to dig deeper when I have the time. My output: akos@FM12BQ:~/Downloads/openocd-libswd-git4/libswd$ src/openocd -s tcl -f openocd-swd.cfg Open On-Chip Debugger 0.5.0-dev-g918cd08-dirty (2011-12-08-12:15
Re: [Openocd-development] pandaboard with busblaster v2
Hi! When burning flash on an lpc17xx, with the libswd fork - but withJTAG, I also get this error, however the flashing is successful. Ákos On 3 November 2011 10:30, Ramkumar Jayaraman ramkumarj2000comm...@gmail.com wrote: Hi, I am trying to get OpenOCD working with a Pandaboard. I m getting Warn : Invalid ACK 0x6 in JTAG-DP transaction followed by the Polling target failed, GDB will be halted. Polling again in 6300ms. Machine : Fedora Linux Debugger : Busblaster v2 (v1.3.jtagkey) My config files are all standard. openocd.cfg source busblaster.cfg source [find board/ti_pandaboard.cfg] adapter_khz 2000 busblaster.cfg interface ft2232 ft2232_device_desc Dual RS232-HS ft2232_layout jtagkey ft2232_vid_pid 0x0403 0x6010 Any thoughts/idea ? TIA, Ram Open On-Chip Debugger 0.6.0-dev-00180-g444f202 (2011-11-02-23:22) snip Info : JTAG tap: omap4430.jrc tap/device found: 0x3b95c02f (mfg: 0x017, part: 0xb95c, ver: 0x3) Info : JTAG tap: omap4430.dap enabled Polling target failed, GDB will be halted. Polling again in 100ms Polling target failed, GDB will be halted. Polling again in 300ms Polling target failed, GDB will be halted. Polling again in 700ms Info : JTAG tap: omap4430.m30_dap enabled Info : JTAG tap: omap4430.m31_dap enabled Warn : Invalid ACK 0x6 in JTAG-DP transaction Polling target failed, GDB will be halted. Polling again in 1500ms Polling target failed, GDB will be halted. Polling again in 3100ms Polling target failed, GDB will be halted. Polling again in 6300ms Polling target failed, GDB will be halted. Polling again in 6300ms ^C ___ 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
[Openocd-development] gerrit mails
Hi! Would it be possible to move the gerrit emails to another list? Like openocd-gerrit, or something? I would be very interested in the development discussions on the lists however the gerrit commits are spamming the real emails. I use gmail, and it's not possible to create a filter that would separate gerrit emails from the other ones. It is possible to apply a label for the emails from the lists, and another one for the email from gerrit, but gerrit emails still get the label meant for list emails. Regards, Ákos Vandra ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Only every second programming works
Hi! Changing the reset config to separate, and the script to use reset halt worked, now every programming works! Here's my output. http://sem.sch.bme.hu/~akos/output.txt It was created using reset_config trst_pulls_srst and reset run. If it is any help I can send the output using the fixed scripts. Thanks for your help guys! Regards, Ákos Vandra On 20 October 2011 11:24, Peter Stuge pe...@stuge.se wrote: Akos Vandra wrote: I know what TRST is, but not SRST. Would it be the normal chip reset? Right, system reset. //Peter ___ 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] Only every second programming works
I know what TRST is, but not SRST. Would it be the normal chip reset? Ákos On 20 October 2011 11:12, Peter Stuge pe...@stuge.se wrote: Akos Vandra wrote: 1. (in reply to freddie choppin) As far as I understand, reset halt is not supported on my target because srst pulls trst. Note that this was set incorrectly for the lpc17xx chip. Double check if the setting in openocd really actually matches your hardware. You need to check both chip and the board schematic. //Peter ___ 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
[Openocd-development] Only every second programming works
Hi guys! I am trying to program an lpc1768 device using an oocdlink (Ft2232-based) programmer. Only every other programming works, which is very strange. After the first programming, the uC seems to be in a lockup state. After second programming, it always works as a charm. I'm pretty much sure the problem is with my program script, but can anyone please help me out with this? Regards, Ákos Vandra my openocd.cfg: debug_level 1 source [find interface/oocdlink.cfg] source [find target/lpc1768.cfg] jtag_khz 200 my programming script: akos@FM12BQ:~/projects/ARM/falcoeye/Debug$ cat `which burnjtag` #!/bin/sh FILE=`ls *.elf`; #OPENOCD='/home/akos/Downloads/openocd-0.5.0/src/openocd -s /home/akos/Downloads/openocd-0.5.0/tcl' OPENOCD=openocd echo $FILE; if [ -f $FILE]; then echo No ELF file found...; exit fi #lpcfixchecksum takes only binary files, so #make a binary file from the elf, and fix the checksum. arm-eabi-objcopy -O binary $FILE tmp.bin lpcfixchecksum tmp.bin $OPENOCD -f ./openocd.cfg -c init -c reset run -c mwb 0x400FC040 0x01 -c halt -c flash write_image erase unlock tmp.bin 0x0 bin -c reset run -c mwb 0x400FC040 0x01 -c exit $OPENOCD -f ./openocd.cfg -c init -c reset run -c mwb 0x400FC040 0x01 -c halt -c flash write_image erase unlock tmp.bin 0x0 bin -c reset run -c mwb 0x400FC040 0x01 -c exit rm tmp.bin play /usr/share/sounds/ubuntu/stereo/bell.ogg -q ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Docs not building
Hi! I tried building the docs from the HEAD (did a git pull, I guess that's the counterpart for svn update), but it gives an error. I might be missing some package, but I don't know what is needed. I have installed texinfo manually, other than that I think I have only the stuff needed to build the code, and what ubuntu comes with. I hope somebody can help me out. Error output is: Making pdf in doc make[1]: Entering directory `/home/akos/Downloads/openocd-git/openocd/doc' TEXINPUTS=.:$TEXINPUTS \ MAKEINFO='/bin/bash /home/akos/Downloads/openocd-git/openocd/missing --run makeinfo -I .' \ texi2dvi --pdf --batch openocd.texi egrep: Invalid range end make[1]: *** [openocd.pdf] Error 1 make[1]: Leaving directory `/home/akos/Downloads/openocd-git/openocd/doc' make: *** [pdf-recursive] Error 1 Cheers, Ákos ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's up? Why so slow?
(At least) in SWD mode with an FTDI programmer openocd is sending data bit by bit. I am planning to send in a patch to fix that, but I am currently unable to test it, because I am waiting for my SWD-capable programmer. Regards, Ákos Vandra On 9 October 2011 08:21, Øyvind Harboe oyvind.har...@zylin.com wrote: USB roundtrips? On Sun, Oct 9, 2011 at 3:40 AM, Peter Stuge pe...@stuge.se wrote: EK-LM3S9B90 ICDI JTAG openocd git jtag_khz 6000 (gdb) load Loading section .text, size 0x1e5f8 lma 0x0 Loading section .data, size 0xe0 lma 0x1e5f8 Start address 0xc63d, load size 124632 Transfer rate: 3 KB/sec, 13848 bytes/write. Seriously, in 2011? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ 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
[Openocd-development] Typo in src/flash/nor/lpc2000.c
Hi! Shouldn't the line in src/flash/nor/lpc2000.c:333 be LOG_ERROR(BUG: unknown lpc2000_info-variant encountered); ? I suspect copy pasting from the switch above it. Regards, Ákos ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: SWD?
Also, I get a build error for ./src/transport/swd_libswd_drv_openocd.c.
I suspect it is because I have an x64 system where pointers are 64bits in size.
The lines listed below try to cast a pointer to an int (signed 32bit),
for producing log messages.
I don't know why the address pointed is useful log information, and
don't really know how to make this
piece of code portable between 32bit and 64bit systems, so I'll leave
it up to you.
I quick-fixed it for my machine by changing the cast to (long long
int), and adjusting the printf argument to %LX. That way it builds.
The errors are:
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_8’:
swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_32’:
swd_libswd_drv_openocd.c:90: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:90: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_8’:
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:131: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_32’:
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:159: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_trn’:
swd_libswd_drv_openocd.c:174: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_drv_miso_trn’:
swd_libswd_drv_openocd.c:201: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c: In function ‘swd_log_level_inherit’:
swd_libswd_drv_openocd.c:228: error: cast from pointer to integer of
different size
Regards,
Ákos
On 26 September 2011 00:02, Akos Vandra axo...@gmail.com wrote:
Hi!
Thank you for the advice, I will do my best to live up to them :)
I'm new to git as well, I tried making the patch you requested:
Cheers,
Ákos
From 88a430100be4d9685863aa2912173ddc5b83e92f Mon Sep 17 00:00:00 2001
From: Akos akos@FM12BQ.(none)
Date: Sun, 25 Sep 2011 23:55:36 +0200
Subject: [PATCH] Fixed two warnings for uninitialized variables
generating build errors
Two retvals in the functions oocd_swd_transport_init and
mem_ap_read_buf_u32 have not had their values initialized
and generated a warning, which cause the build to fail.
Fixed by initializing these variables to ERROR_OK
---
src/target/arm_adi_v5.c | 2 +-
src/transport/swd_core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index f529446..1454007 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -696,7 +696,7 @@ int mem_ap_read_buf_u32(struct adiv5_dap *dap,
uint8_t *buffer,
// uint32_t invalue, adr = address;
// uint8_t* pBuffer = buffer;
- int i, retval;
+ int i, retval = ERROR_OK;
uint32_t invalue;
//count = 2;
// wcount = count;
diff --git a/src/transport/swd_core.c b/src/transport/swd_core.c
index 383199f..36191fb 100644
--- a/src/transport/swd_core.c
+++ b/src/transport/swd_core.c
@@ -125,7 +125,7 @@ int oocd_swd_run(struct adiv5_dap *dap){
// TODO: We are operating on global interface pointer, change it into
function parameter asap.
int oocd_swd_transport_init(struct command_context *ctx){
LOG_DEBUG(entering function...);
- int retval, *idcode;
+ int *idcode, retval = ERROR_OK;
struct target *target = get_current_target(ctx);
struct arm *arm = target_to_arm(target);
--
1.7.1
On 25 September 2011 23:15, Peter Stuge pe...@stuge.se wrote:
Hi Akos,
Akos Vandra wrote:
Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).
10.10 is soon one year old, which can be a long time in open source.
Also keep in mind that pretty much every major distribution is
applying significant amounts of patches in their toolchain packages
and possibly also system libraries.
They intend this to make things better of course, but it can backfire
and make the toolchain unusable sometimes. Keep this in mind if you
encounter a weird build issue of any package.
From many years of use of gcc and binutils I would recommend to use
a vanilla toolchain, or at the very least very aggressively pulling
toolchain updates from your distribution.
I have been getting some warnings (treated as errors) due to some
retvals didn't have initial value set, but I set them to ERROR_OK,
and now it passes those points.
Please send patch(es) for these to the mailing list. Thanks
[Openocd-development] ft2232_transfer why bit-by-bit?
Hi! Is there a good reason why ft2232_transfer uses bit-by-bit mpsse transfer? If not, I would be happy to rewrite it to use bytewise transfer, if the number of bits to be transferred is divisable by 8. Might make things a *little* bit faster... Regards, Ákos ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fwd: ft2232_transfer why bit-by-bit?
-- Forwarded message -- From: Akos Vandra axo...@gmail.com Date: 26 September 2011 23:36 Subject: Re: [Openocd-development] ft2232_transfer why bit-by-bit? To: Laurent Gauch laurent.ga...@amontec.com Hi! Sorry, it seems like I wanted to do too much too fast. Turns out I don't have an SWD compatible programmer yet. I am going to make a programmer compatible with kt_link_swd. I found its pinout over the internet, and I am currently making up the schematic. Does anyone by chance have designs for such a programmer, that I could build myself? I find 50E too much for the kt_link. If not, I might release the gerber files to the public. Regards, Ákos On 26 September 2011 15:08, Laurent Gauch laurent.ga...@amontec.com wrote: Hi! Is there a good reason why ft2232_transfer uses bit-by-bit mpsse transfer? If not, I would be happy to rewrite it to use bytewise transfer, if the number of bits to be transferred is divisable by 8. Might make things a *little* bit faster... Regards, Ákos This will be great, Akos. Also, the high level JTAG API will allow you to implement byte wise - bit wise instead bit wise only without changing the API interface. Have fun. Regards, Laurent http://www.amontec.com Amontec JTAGkey-2P High-Speed USB JTAG SPI Emulator Cable with Power supply 3.3V @ 500mA on pin 19. ___ 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
[Openocd-development] SWD?
Hello everyone! I am a first-year, MSc student studying computer engineering. The subject of my thesis is analyzing test code coverege on a Cortex-M3 processor. In order to do this I intend to use the SWO trace-port of the Cortex-M3 processor. To use the SWO output, the processor must be set into SWD mode, because it shares a pin with the JTAG interface. My first task would be to analyze and present trace data to the user, but later on the goal would be to program up the trace peripheral through SWD, and test code coverage *without* using any kind of extra code downloaded to the microcontroller. For this I would need something that supports the SWD protocol and debugging of course, as I don't intent to rewrite it from scratch. That was a kind of long introduction, but now for my question: How does SWD support stand in openocd? The information I found over the lists are contradictory and not quite clear. As far as I understand, there is a working adapter named versaloon, which is also ARM-based? My hardware would use an FT2232 chip (layout similar to oocdlink), so if the transport layer is ready, I would be happy to write a driver for it, if you can give me a few pointers where and how to start. Currently my main need would be to use SWD to access the internal memory bus, and read/write data. I would be happy to contribute as much as I can to openocd, and I'd love to see trace support integrated into openocd. (Won't need to occupy a serial port for printf-s, and other useful data could be retrieved, something similar to: Switched to task EventTask at 2394nS etc.) Regards, Ákos Vandra ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fwd: SWD?
-- Forwarded message -- From: Akos Vandra axo...@gmail.com Date: 25 September 2011 18:03 Subject: Re: [Openocd-development] SWD? To: Tomek CEDRO tomek.ce...@gmail.com Hi! I'm trying to follow your instructions here http://stm32primer2swd.sf.net/ but I cannot find the interface script for kt-link-swd. I tried cloning the openocd git repo from here: git://openocd.git.sourceforge.net/gitroot/openocd/openocd It doesn't build but it doesn't contain the interface script either. My hardware is not a kt-link, but it *should* work, because the SWD pinout is the same. Regards, Ákos On 25 September 2011 16:23, Akos Vandra axo...@gmail.com wrote: Hi Tomek, Thank you for the pointers, I chew them through, and get back to you when I'm starting to get a hang of it. Or when I get stuck, hope it will be the former :) Regards, Ákos On 25 September 2011 16:07, Tomek CEDRO tomek.ce...@gmail.com wrote: Hello Akos :-) The transport layer is ready and functional using LibSWD[1]. I dont know about how well Versaloon supports the SWD, but I created dedicated driver for FT2232 so it should match your hardware, it is more versatile because it has some TCL interface. The current task is to make Target layer work with SWD because there were some JTAG-only parts of the code in the transport system. You are in the right place and time to help me with the Target and the SWO :-) There is a dedicated git fork for openocd+libswd [2]. You can see my scratchpad on SWD implementation since its beginnings. The current state of the code is that error handling and retransmission needs to be implemented in case target returns WAIT or FAULT response, this is your first task :-) Please ask if you need any additional information :-) The recommended order to get familiar with the organization is [3] [1] [2]. The documentation on the LibSWD website is a bit outdated as it used SVN and I have switched to GIT meanwhile, but I will try to sync repositories asap, you can clone the git repository and make doxygen to have a fresh copy at glance. Best regards :-) Tomek Cedro [1] http://libswd.sf.net [2] http://repo.or.cz/w/openocd/libswd.git [3] http://stm32primer2swd.sf.net -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: SWD?
Hi! Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu). I have been getting some warnings (treated as errors) due to some retvals didn't have initial value set, but I set them to ERROR_OK, and now it passes those points. Right now build gets stuck at In file included from ../../src/helper/command.h:26, from ../../src/helper/log.h:29, from swd_libswd_drv_openocd.c:42: ../../src/helper/types.h:115: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘le_to_h_u32’ ../../src/helper/types.h:120: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘le_to_h_u24’ ../../src/helper/types.h:125: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘le_to_h_u16’ ../../src/helper/types.h:130: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘be_to_h_u32’ ../../src/helper/types.h:135: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘be_to_h_u24’ ../../src/helper/types.h:140: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘be_to_h_u16’ It seems like uint32_t is not defined, even though it should be, as stdint.h is included. Funny thing, if I set the first occurance of uint32_t to unsigned int, the other ones build fine, which is kinda wierd. Working on it... I'll try to spam you less 'til mid october then, I have some work to finish myself, but I have to get going with my thesis as well. :) Also, should we spamming the developer list, or rather continue this discussion personally? I'm not familiar with opensource development *at all*, so I'm not familiar with list policies either. Cheers, Ákos On 25 September 2011 18:28, Tomek CEDRO tomek.ce...@gmail.com wrote: On Sun, Sep 25, 2011 at 4:03 PM, Akos Vandra wrote: I'm trying to follow your instructions here http://stm32primer2swd.sf.net/ but I cannot find the interface script for kt-link-swd. I tried cloning the openocd git repo from here: git://openocd.git.sourceforge.net/gitroot/openocd/openocd The openocd-libswd trunk repository is git://repo.or.cz/openocd/libswd.git the http interface is at http://repo.or.cz/w/openocd/libswd.git Please tell me what is your build environment, I use FreeBSD, there were some issues with Linux build, but I fixed some of them (mainly on LibSWD, still there may be some in openocd), please let me know what does not work. I will setup virtual machine with your build environment and try to help you. I think Linux Ubuntu is the most common Linux distro nowadays..? I have been extremely overworked recently, please call me on chart for critical issues, I should have more time on mid October (~2..3 weeks) but I will support you as much as I can meanwhile :-) My hardware is not a kt-link, but it *should* work, because the SWD pinout is the same. The pin definitions are now taken out to the TCL / configuration file, so they should be not hardcoded (except standard FT2232 pins but we shout bring them out anyway) and easy to match any other interface with no need to rewrite the sources :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: SWD?
Hi!
Thank you for the advice, I will do my best to live up to them :)
I'm new to git as well, I tried making the patch you requested:
Cheers,
Ákos
From 88a430100be4d9685863aa2912173ddc5b83e92f Mon Sep 17 00:00:00 2001
From: Akos akos@FM12BQ.(none)
Date: Sun, 25 Sep 2011 23:55:36 +0200
Subject: [PATCH] Fixed two warnings for uninitialized variables
generating build errors
Two retvals in the functions oocd_swd_transport_init and
mem_ap_read_buf_u32 have not had their values initialized
and generated a warning, which cause the build to fail.
Fixed by initializing these variables to ERROR_OK
---
src/target/arm_adi_v5.c |2 +-
src/transport/swd_core.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index f529446..1454007 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -696,7 +696,7 @@ int mem_ap_read_buf_u32(struct adiv5_dap *dap,
uint8_t *buffer,
// uint32_t invalue, adr = address;
// uint8_t* pBuffer = buffer;
- int i, retval;
+ int i, retval = ERROR_OK;
uint32_t invalue;
//count = 2;
// wcount = count;
diff --git a/src/transport/swd_core.c b/src/transport/swd_core.c
index 383199f..36191fb 100644
--- a/src/transport/swd_core.c
+++ b/src/transport/swd_core.c
@@ -125,7 +125,7 @@ int oocd_swd_run(struct adiv5_dap *dap){
// TODO: We are operating on global interface pointer, change it into
function parameter asap.
int oocd_swd_transport_init(struct command_context *ctx){
LOG_DEBUG(entering function...);
- int retval, *idcode;
+ int *idcode, retval = ERROR_OK;
struct target *target = get_current_target(ctx);
struct arm *arm = target_to_arm(target);
--
1.7.1
On 25 September 2011 23:15, Peter Stuge pe...@stuge.se wrote:
Hi Akos,
Akos Vandra wrote:
Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).
10.10 is soon one year old, which can be a long time in open source.
Also keep in mind that pretty much every major distribution is
applying significant amounts of patches in their toolchain packages
and possibly also system libraries.
They intend this to make things better of course, but it can backfire
and make the toolchain unusable sometimes. Keep this in mind if you
encounter a weird build issue of any package.
From many years of use of gcc and binutils I would recommend to use
a vanilla toolchain, or at the very least very aggressively pulling
toolchain updates from your distribution.
I have been getting some warnings (treated as errors) due to some
retvals didn't have initial value set, but I set them to ERROR_OK,
and now it passes those points.
Please send patch(es) for these to the mailing list. Thanks!
It seems like uint32_t is not defined, even though it should be, as
stdint.h is included.
stdint.h is included only #ifdef HAVE_STDINT_H. Did you verify with
gcc -E or at least in config.h that HAVE_STDINT_H is defined?
Funny thing, if I set the first occurance of uint32_t to unsigned
int, the other ones build fine, which is kinda wierd.
It is not funny at all. I find it typical of a toolchain issue. It is
bullshit that wastes precious developer time. :\
Also, should we spamming the developer list,
Certainly yes. The purpose of the developer list is to carry
developer discussion.
or rather continue this discussion personally?
Absolutely not.
I'm not familiar with opensource development *at all*,
Welcome to open source! It can be a wonderful environment of
cooperation and synergy when things align well. It can also be a
challenging environment of conflicts and complaints when they don't.
Overall I personally find it to be more than worth the trouble, and
I think it leads to better software.
so I'm not familiar with list policies either.
Again, this is a developer list whose sole purpose is for developer
communication. Direct communication should be an exception.
(Sometimes it's the right thing of course, just usually it is not.)
Please study git and work on becoming fluent with it if you are not
already. It is a great tool that supports development in very many
ways. Beyond simply keeping track of what happened in the code git
when used well allows incredibly efficient review and movement of
code between developers in a project. I can recommend the
http://progit.org/ book, but start out by just playing with it a
little. Make some repositories with some commits and get the basic
workflow going. Learning the rest is usually easy. I also recommend
the #git IRC channel on freenode, for getting live help.
One use for developer mailing lists is to distribute proposed
patches, so that they can be reviewed and then included into the
public source tree.
To make the review step quick and thus make it somewhat likely to
actually happen, it is *critical* that the patch is what I call
clean. Maybe all this is obvious to you
