Re: [Openocd-development] Google presentation on OpenOCD Gerrit experience
/ What do you mean by Senior developers ? / Developers bestowes us with their great acumen. / What do you really interpret At the sharp rise, Gerrit was introduced ? / # of commits rose from 3 to 30 a week. I am really not sure to find any correlation between the coming of gerrit and the number of new commits ! Also 90% of the last new commits were whitespace diffs ! Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Google presentation on OpenOCD Gerrit experience
good read ! Thanks. What do you mean by Senior developers ? What do you really interpret At the sharp rise, Gerrit was introduced ? Laurent http://www.amontec.com HIGH-SPEED USB JTAG INTERFACE as generic as possible ___ 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 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 at FM12BQ https://lists.berlios.de/mailman/listinfo/openocd-development:~/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 first prog. from a blank device, or first prog. just after connecting your debugger / programmer to your device ? That's not the same ? Laurent http://www.amontec.com/ Amontec JTAGkey-2 : High speed USB JTAG interface ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
Well, the ARM-JTAG-EW is not an FT2232 device as far as I can tell -- it's supposed to be a JLink clone for IAR. I guess the answer is no then. Looks like the right thing is to get a real JLink. Thanks anyway! On Tue, Oct 18, 2011 at 1:52 AM, Tomek CEDROtomek.cedro at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / On Tue, Oct 18, 2011 at 2:47 AM, Michael Ashtondata at gtf.org https://lists.berlios.de/mailman/listinfo/openocd-development wrote: //Hi, //I'm wondering if anyone can say whether it's possible, or might ever be //possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD? //I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure // whether //that really means anything. //thanks! --Michael // // Driver is generic for FT2232 devices, you can play with some // resistor/diode to make JTAG interface work as SWD :-) // // -- // CeDeROM, SQ7MHZ,http://www.tomek.cedro.info / certainly olime waits on Segger JLINK SWD implementation in openocd to let say their arm jtag ew has swd certainly olime waits on Amontec JTAGkey-3 SWD implementation in openocd to let say their 2232 has swd ... Regards, Laurent http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Gerrit Review
Hi Spen, Why using a commercial server and a commercial url for an open source project? Regards, Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [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 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
Re: [Openocd-development] [PATCH] jtag dependendy removed from arm_adi_v5
Hi, due to the coming SWD support, I found that the arm_adi_v5 has dependencies to the jtag subsystem. To preserve the performance I changed the interface to the transport layer. Both, dap_queue_ap_write and dap_queue_ap_read gets a pointer to a data array not a single value. The adi_v5_jtag now implements the loop reading the registers via jtag transport layer. So other transports like SWD can implement it's own efficient method reading a register multiple times. I tested the patch with my Amontec JTAGKey2 and a LPC1768. Can anyone revisit the patch. Sven Great. I think that's the good way to go. Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag dependendy removed from arm_adi_v5
I can take a look at this as I'm finishing to solder a hardware that I will finish the SWD implementation in upcoming days, but I would rather not change interface/jtag/transport layer until SWD is done. When its done and working then we can change internals, otherwise we will have two different forks and additional work to do. Best regards, Tomek Hi Tomek, ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Wed, Jul 13, 2011 at 10:55 PM, Xiaofan Chen xiaofanc at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Under Linux, ftd2xx 1.04 (based on libusb-1.0.8) does not seem to offer // any advantage than libftdi (tested with 0.19) / This is the same as reported last time. / mcuee at Ubuntu https://lists.berlios.de/mailman/listinfo/openocd-development:~/Desktop/build/openocd/lm3s1968$ openocd-d2xx -f // board/ek-lm3s1968.cfg // Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:28) // Licensed under GNU GPL v2 // For bug reports, read //http://openocd.berlios.de/doc/doxygen/bugs.html // Info : only one transport option; autoselect 'jtag' // 500 kHz // Error: unable to get latency timer: 0 // Error: ftd2xx 1.04 detected - this has known issues with // FT_GetLatencyTimer, upgrade to a newer version // Info : device: 4 2232C // Info : deviceID: 67353817 // Info : SerialNumber: 070200A1A // Info : Description: Stellaris Evaluation Board A // Info : clock speed 500 kHz // Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: // 0x23b, part: 0xba00, ver: 0x3) // Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints // Info : accepting 'telnet' connection from // 500 kHz // cortex_m3 reset_config sysresetreq // Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: // 0x23b, part: 0xba00, ver: 0x3) // target state: halted // target halted due to debug-request, current mode: Thread // xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 // flash 'stellaris' found at 0x // auto erase enabled // wrote 262144 bytes from file ./demo.bin in 50.572987s (5.062 KiB/s) // 500 kHz // cortex_m3 reset_config sysresetreq // Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: // 0x23b, part: 0xba00, ver: 0x3) // target state: halted // target halted due to debug-request, current mode: Thread // xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 // 1200 kHz // flash 'stellaris' found at 0x // auto erase enabled // wrote 262144 bytes from file ./demo.bin in 42.674957s (5.999 KiB/s) // ^C // // mcuee at Ubuntu https://lists.berlios.de/mailman/listinfo/openocd-development:~/Desktop/build/openocd/lm3s1968$ openocd -f board/ek-lm3s1968.cfg // Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:21) // Licensed under GNU GPL v2 // For bug reports, read //http://openocd.berlios.de/doc/doxygen/bugs.html // Info : only one transport option; autoselect 'jtag' // 500 kHz // Info : clock speed 500 kHz // Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: // 0x23b, part: 0xba00, ver: 0x3) // Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints // Info : accepting 'telnet' connection from // 500 kHz // cortex_m3 reset_config sysresetreq // Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: // 0x23b, part: 0xba00, ver: 0x3) // target state: halted // target halted due to debug-request, current mode: Thread // xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 // 1200 kHz // flash 'stellaris' found at 0x // auto erase enabled // wrote 262144 bytes from file ./demo.bin in 42.677986s (5.998 KiB/s) // ^C / Then I did similar test under Windows with libftdi-0.19 (with Liminary's FTDI driver and libusb-win32 filter driver). The speed is faster than under Linux. Kind of interesting. I will try the ftd2xx Windows build later. D:\work\openocd\build_cxf\openocd_14Jul2011_mingw32\binopenocd.exe -f board\ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc-dirty (2011-07-14-21:37) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file ./demo.bin in 11.093000s (10.908 KiB/s) -- Xiaofan Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ? If yes, please do the same comparaison with libusb and d2xx on Linux and windows, and with the Amontec JTAGkey D2XX device driver package WHQL certified . Regards, Laurent http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SRST TRST have to be buffered?
Hello! I'm trying to embed a FT2232D based programmer into my board with a STM32 (Cortex-M3 MCU). I want the programmer to be compatible with jtagkey, so I looked at schematics of compaible designs. I noticed that while the JTAG signals (TCK, TDI, TDO, TMS) are only buffered when translation is necessary, the SRST and TRST signals are always tri-state buffered, with OE going into the FTDI chip. Is there a reason for that? Can I omit the buffers? On the JTAGkey http://www.amontec.com/jtagkey.shtml , the output buffers have 3 basic functions: - remove any pull-down or pull-up from the internal of JTAGkey (The pull-up and pull-down value must be controlled by the target board and not by the emultator) - pass from 8mA output to 32mA output driver (JTAGkey and JTAGkey-2 are tested to support more than 12 daisy-chain devices on the same JTAG Chain) - possibility to tristate the JTAG port at any time - provide an ultra large IO voltage tolerance from 1.5V to 5V ;-) The Amontec JTAGkey was designed to be the most generic USB JTAG adapter as possible. Also, the Amontec JTAGkey has the advantage to provide a full control of the TRST and SRST line. In fact, the TRST and SRST of the Amontec JTAGkey can be configured as push-pull buffer and as open-drain buffer. Note, SRST can be monitored from the JTAGkey Layout. Also, I heard it's possible to omit the TRST signal and only keep the SRST signal, because system reset will also reset the TAP controller. Is that true? Are there problems with that? TRST and SRST are optional, and their usage will depend on what is the target need. So you can try to customize the Amontec JTAGkey Layout for your need, or you can use it as it is. The advantage of using the original Amontec JTAGkey Layout is you make to sure have a full compatibility with software supporting JTAGkey ! Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-speed USB JTAG Adapter with RTCK feature. Many thanks! Matthew ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
Hi, I'm working with an LPC2388 (arm7tdmi-s core). I use the IDLE power mode to stop the arm core to reduce power consumption. All IT and peripheral are still ON in this mode, only the arm core is sleeping. I the software running on the CPU doesn't use the power reduction mode (arm core is still ON in this case) then I have no problem with the jtag. The problem seams to be related only to the power mode. Whatever the openocd command I use (reset, halt, soft_reset_halt, resume 0x00) openocd error is like : Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt' If I try to directly write to the CPU register to disable the IDLE mode, i get (a normal error message): Target not halted So I can not disable the IDLE mode with my jtag. I have to use the CPU integrated bootloader to reload a software with no IDLE mode through the RS232 link before I can use my Jtag again. I've seen other messages related to this point on the ML but has anyone found a solution to this problem ? Regards, -- Luc Try to reduce the JTAG frequency or use a JTAGkey-2 with RTCK feature enabled since you have a ARM -s (arm7tdmi-s core). The RTCK will help to have your JTAG interface synchronized with the target frequency. Regards, Laurent Gauch http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 13:17, Spencer Oliver spen at spen-soft.co.uk https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Openocd did work ok for wfi as long as the jtag clock was slow enough. // However this was broken in HEAD last time i tested it - it has been on // my look at list for a while /I'm not using 'WFI' instruction, I've found this one in the instruction set. I suppose this arm (Armv4T architecture) has not. I'm using a LPC2388 specific register to command entering low power mode (IDLE) (up to the next IRQ, so I obtain an same behavior that with WFI). -- Luc Are you sure your Target JTAG interface is active in your low power mode ? Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec USB JTAG 30MHz / RTCK / 4 on-boards Status LEDs / 1.4V to 5.5V auto-sense. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On 6 July 2011 13:52, Laurent Gauch laurent.gauch at amontec.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Are you sure your Target JTAG interface is active in your low power mode ? /You seams to be right (even if I have not found this information in the user manual of the LPC2388 for the moment) : /From http://www.keil.com/support/man/docs/mcb2300/mcb2300_fp_ulink.htm /I found : The Embedded ICE in the LPC2000 core is disabled when the device is in Power Down or Idle ULINK stops working if your code puts the ARM device into Idle or Power Down mode (here ULINK is the name of their usb-jtag adapter) -- Luc Happy to know I point you to the right . The Power Down are specific to the target vendor not to the ARM arch. ;-) For me it is normal the target vendor disable the arm Embedded ICE core during the Power Down, by default. Regards, Laurent http://www.amontec.com/jtagkey.shtml USB JTAG programmer debugger for ARM7 ARM7tdmi-s ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] USB Blaster support broken
Greetings all, In the past few days I have been trying to get my USB Blaster clone (called USB Blaster mini) to work with OpenOCD from the latest git tree (762ca59dd5cbe70026234d549bb5f5ac1a05d5b4 http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=tree;h=762ca59dd5cbe70026234d549bb5f5ac1a05d5b4;hb=45287bda76ace1f93b9e48ead7fed83c774258d1). I have found out that support for this dongle is broken in OpenOCD due to a couple bugs in the OpenOCD usbblaster interface driver: 1. The USB Blaster clone does not use the original FT245 chip, and so it tries to emulate its behavior. As it turns out, the API call FT_GetLatencyTimer is not properly emulated by the clone, and this makes OpenOCD abort. In reality, this API call is not necessary, so I have removed this call. 2. The LED blink code that was added in commit (24943498e611649a540d98406288dd6d4889851d) made the JTAG communication unstable, see http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commitdiff;h=24943498e611649a540d98406288dd6d4889851d . The USB Blaster dongle would properly detect the IDCODE, but would later fail when trying to read/write the DPACC ARM JTAG registers. Not surpringly, this is because the blink code resets the out_value, which keeps track of the state of the JTAG pins. In my tests, disabling or blinking the LED flag made JTAG communication very unstable. This flag needs to be permanently enabled for proper operation. I have attached a patch to this email that fixes these problems, and officially supports the USB Blaster clones. Regards, Domien Nowicki. Thanks. This problem is typically coming from the use of bad BIT BANG control on a dedicated port :-( ! Laurent http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Fri, 24 Jun 2011 16:32:54 +, Tomek CEDRO wrote: Cool, I will add new field into layout structure that will indicate forbidden bits to bitbang, this field will be zero by default so all bits are allowed, driver author can add some value of this field to the specific layout - that value AND port mask to set/bitbang will be checked in ft2232_bitbang(), if non-zero then error will be returned as user tried to access restricted port pins. Should be simple, elegant and safe enough..? Thank you Tomek for understanding the importance of bitbang filter mechanism implemented at low level. That's a great news Tomek ! This will do the bitbang safe, and now I can accept your idea having TCL bitbang features. Have a nice week-end. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 USB JTAG CABLE with 4 status LEDs This update should appear in my fork repository after weekend.. soo have a great weekend! :-) Best regards :-) Tomek ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
The best is to standardize at a lower level ... and to forget the idea to have the possibility to bitbang from the TCL of the openocd. / //That's as for the SWD, we have to standardize some function call in the ft2232, and avoiding bitbang access from higher-level. // //That's not simple to dev, but safe for end-user. // // /It is necessary to expose the feature though TCL. Otherwise it is not possible to use it as the telnet TCL interface is the primary (only?) way for you to control OpenOCD. Furthermore, this is the interface to use if you want to use OpenOCD from another program. Hi, Please do not confuse. I am not talking about to remove the TCL itself, but I talking to avoid the possibility to bitbang the ft2232 port from TCL in a non safe way ! It is really not the same. Please read all my comments. The bitbang of the ft2232 via TCL MUST pass via a filter in the ft2232.c associated to the layout. The filter must mask the ft2232 inputs related to the layout. The filter must apply the mask when the bitbang try to write these ft2232 input. If this mechanism is integrated in ft2232.c by Tomek, then yes, and only in this case we can bitbang the ft2232 via TCL user interface. If Tomek want to provide the bitbang from TCL, he must first provide the filter mechanism . Actually the filter bitbang filter mechanism is not implemented in ft2232.c . That's all. Again, what happen if the RTCK input is driven low or high from TCL bitbang, by the end-user. You have lot of chance to break he ft2232 or the buffer (between the ft2232 and the target) or the target, since you have chance to generate a short-circuit of the RTCK wire ;-( . That's the same for all the ft2232 Input . That's why I have write a big DANGEROUS ! I do not understand the opposition to making OpenOCD more flexible by reducing the need to modify the source and re-building to achieve some functionality. You can already do plenty of unsafe things with OpenOCD like erasing the entire flash of your target. I am not opposed to make the OpenOCD more flexible. But I do not want to see OpenOCD as dangerous for the hardware signal/wire for the target and/or the adapter. Yes, we can do unsafe things with OpenOCD. But the actual unsafe thing are not related to the JTAG / SWD hardware / signal / wire, but related to the how we use upper debug protocol and that's really not the same. Phil Regards, Laurent http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
Steve Bennett wrote: On 21/06/2011, at 5:22 PM, Steve Bennett wrote: On 21/06/2011, at 5:18 PM, Laurent Gauch wrote: Steve Bennett wrote: On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote: On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. It is a long thread but I was able to reproduce the error. http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html I think the latest d2xx library needs some fix from the OpenOCD side or from the d2xx side. It is more difficult to ask FTDI for a fix so it may better to fix this from OpenOCD side. Therefore I think the patch should be accepted. When FTDI fixes D2xx, then probably the patch can be reverted. I have reported the problem to FTDI, but in my experience we can not expect a response soon, if ever. I think there are two options, either apply the patch as a workaround (note that the returned value is *never* used), or remove support for D2XX. Thank you Steve, If you do not get any reply on next Monday, please let me know I will ask them. Amontec has good contacts to FTDI team. Will do. Please apply the patch as a workaround. It is on the list. Perhaps some kind maintainer will do so. But if the returned value is never used, there are no reason to give a warning ! Agreed. But it seemed less of a step from fatal error to warning than ignoring it completely. I take it all back! I got a very prompt reply from FTDI with a new version of the D2XX driver to test (1.0.5) which resolves this problem. Hopefully this version will become generally available soon. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 Great to know this. Great to know it is coming from d2xx itself, but resolved in a newer version. So, your first idea to add warning instead the fatal error, is the way to go. This will become transparent with newer d2xx driver. To maintainer : please merge the Steve patches. Regards, Laurent http://www.amontec.com Amontec JTAGkey-2 USB JTAG CABLE for ARM processors ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
/ On Thu, Jun 23, 2011 at 1:03 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // On 23/06/2011, at 8:59 PM, Øyvind Harboe wrote: // // I don't think this is sufficient, as it will put up warnings on some // other platforms unless you use the macros that expand to the // correct formatting string. // // See C99 section: // // http://en.wikipedia.org/wiki/Printf // // Can you provide an example of a platform which produces warnings? // I don't see how. // // I haven't followed this(big discussions), but I've seen on the list // in the past that casting is frowned upon and using these // macros is cheered... Anyway... I'm happy to follow the path // of using these macros, I certainly don't want to become an // expert! :-) / We do not ask maintainers, as you, to be experts. I guess I'm not quite sure what you want. Feel free to apply a modified patch if you want, as long as it removes the warnings. I do not understand too ! Please explain us exactly what you want, or please merge the steve's patch asap. Note: I really think we need some sub-maintainers, specialized in specific part of the project. Cheers, Steve Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 HIGH-SPEED USB JTAG CABLE ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Simple and true :-) Each interface has its own config file anyway, so this file can contain also signal definition for that interface. If interface has no signals defined, no signals will be defined, so there is no worry. Here we have to select between Simple and Safe ! We know that a large part of TCL are copy past from tcl examples to end-user dedicated TCL file (That's not what we really want, but the TCL is the end-user interface). My experience tell me that a lot of users are copy pasting to one file for the specifc use. What happen if a user force a '0' or '1' to RTCK input of the interface, using your bitbang TCL. The problem with your bitbang approach via TCL, is a REAL risk for the end user to copy paste your TCL signal definition specific to a layout and copy it for an other layout. You will tell me, the user needs to know what he do ... Anyway, you have to implement a mechanism to filter the bitbang in the ft2232. Please provide first a mechanism allowing to filter/mask the access of the ft2232 IO port for each specific layout. Then we can test and see if the bitbang port from TCL are enough safe to be merged. User can define his/hers own signals by hand, but it is then his/hers choice :-) There can be some standard signals to be used by general TCL scripts as signals are recognised by name string :-) The best is to standardize at a lower level ... and to forget the idea to have the possibility to bitbang from the TCL of the openocd. That's as for the SWD, we have to standardize some function call in the ft2232, and avoiding bitbang access from higher-level. That's not simple to dev, but safe for end-user. Best regards! :-) Tomek Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 USB JTAG CABLE ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
/My objective is not to block feature.Never,never,never ... But we have //to avoid any trouble in generic ft2232 driver regarding specific layout. //That's all. //Your TCL bitbang will control the port of the FTDI from an higher level //than FT2232.c. OK but you TCL bitbang is specific to the layout used. //How do you accept or not the use of the TCL procedure, if you do not //have the notion of layout in this function ??? //You have two solutions: You need to write a specifc driver (), or you //need to filter the TCL bitbang action in the ft2232 generic driver. The //filter must be specifc to the open layout ... //The same is for SRST TRST control. The ft2232.c driver has specific //functions for SRST TRST regarding layout used ... we have to do this for //ANY other specific layout signal in the ft2232.c or write a specific //driver. // //I think there is an misunderstanding here. My reading of Tomek's emails indicates there is a layout specific mechanism to filter which pins can be bitbanged. The interface config file will define which pins can be bitbanged and how. /Is this correct? It should be, but it is not actually implemented. Tomek, please confirm. The bitbang filter mechanism is my suggestion, to avoid any bad io port configuration. To make the thing robust, the bitbang filter mechanism must be implemented in the ft2232.c and related to the layout enabled at onpenocd initialization. The filter must not be a simple TCL itself, since the selected layout at initialization can be bypassed. Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 USB JTAG Dongles Phil ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
Steve Bennett wrote: On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: / // / On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // // On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: // // // On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // // Instead, just produce a warning // // // Why? // // // It merits a comment at least? // // // Seems self-evident to me. // // Why should it be fatal just because a value couldn't be read? // // Doesn't stop anything from working. // // // Why should we support broken hardware or drivers? // // // Better the user is told to toss his busted dongle / hardware than to tangle // // with subtle followon errors? // / // Nothing to do with hardware. It's a problem with the driver. // See http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html // // / / // Objection ! // // If we cannot read this value back, this means we reach trouble with driver or device somewhere. // Also, this trouble could affect following access ... // This is why we stop with fatal error. / OK. So what alternative solution would you suggest to make this driver work? What version of the driver do you use. If it really come from the driver and if this is the last official driver, then ask the writer of the driver to correct. If no correction are done quickly by the writer of the driver, then yes, you may just produce a warning. http://www.ftdichip.com/Drivers/D2XX.htm Latest version, 1.0.4. Same behaviour on both MacOSX and Linux. Sure. I'll ask if they would like to fix this problem. I will let you know what useful response I get. Great. But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. Regards, Laurent Gauch http://www.amontec.com Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
Xiaofan Chen wrote: On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. It is a long thread but I was able to reproduce the error. http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html I think the latest d2xx library needs some fix from the OpenOCD side or from the d2xx side. It is more difficult to ask FTDI for a fix so it may better to fix this from OpenOCD side. Therefore I think the patch should be accepted. When FTDI fixes D2xx, then probably the patch can be reverted. Yes, right. I revert my objection. We can merge this patch and we will revert it lately. Regards, Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
Steve Bennett wrote: On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote: On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. It is a long thread but I was able to reproduce the error. http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html I think the latest d2xx library needs some fix from the OpenOCD side or from the d2xx side. It is more difficult to ask FTDI for a fix so it may better to fix this from OpenOCD side. Therefore I think the patch should be accepted. When FTDI fixes D2xx, then probably the patch can be reverted. I have reported the problem to FTDI, but in my experience we can not expect a response soon, if ever. I think there are two options, either apply the patch as a workaround (note that the returned value is *never* used), or remove support for D2XX. Thank you Steve, If you do not get any reply on next Monday, please let me know I will ask them. Amontec has good contacts to FTDI team. Please apply the patch as a workaround. But if the returned value is never used, there are no reason to give a warning ! Laurent http://www.amontec.com Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
only one transport option; autoselect 'jtag' interface_signal list interface_signal list Interface Signal Name |Mask| Value -- interface_signal add led 8000 interface_signal add led 8000 There are no signals defined yet. interface_signal list interface_signal list Interface Signal Name |Mask| Value -- led | 0x8000 | 0x8000 bitbang led=lo bitbang led=lo ftdi_write_data: USB device unavailable Unable to write signal: led in procedure 'bitbang' bitbang led bitbang led ftdi_write_data: USB device unavailable Unable to read signal: led in procedure 'bitbang' Does OpenOCD need to handle this kind of bitbang fonction from TCL ? For me, it does not, because it is too DANGEROUS for both the dongle and target ... PLEASE COMMENT The problem is that the result of a bit-bang procedures will be dongle and layout specific. There are too many chances for the end-user to create short-circuit in the dongle or on the dongle port to the target board. Also, we should not use and/or provide the possibility to the end-user to manage himself the bitbang of the dongle port, from TCL or from any other access. This is JUST not the JOB of openocd but the job of other pieces of software (as manufacturer post-production test program ...). ALL dongle port access should be controlled and checked in the FT2232.c. The FT2232 should not give to higher layer the possibility to have an direct access to the dongle port. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 : HIGH SPEED USB JTAG CABLE ADAPTER DONGLE DRIVER ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Sergey Lapin wrote: On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch laurent.ga...@amontec.com wrote: only one transport option; autoselect 'jtag' interface_signal list interface_signal list Interface Signal Name |Mask| Value -- interface_signal add led 8000 interface_signal add led 8000 There are no signals defined yet. interface_signal list interface_signal list Interface Signal Name |Mask| Value -- led | 0x8000 | 0x8000 bitbang led=lo bitbang led=lo ftdi_write_data: USB device unavailable Unable to write signal: led in procedure 'bitbang' bitbang led bitbang led ftdi_write_data: USB device unavailable Unable to read signal: led in procedure 'bitbang' Does OpenOCD need to handle this kind of bitbang fonction from TCL ? For me, it does not, because it is too DANGEROUS for both the dongle and target ... PLEASE COMMENT The problem is that the result of a bit-bang procedures will be dongle and layout specific. There are too many chances for the end-user to create short-circuit in the dongle or on the dongle port to the target board. Also, we should not use and/or provide the possibility to the end-user to manage himself the bitbang of the dongle port, from TCL or from any other access. This is JUST not the JOB of openocd but the job of other pieces of software (as manufacturer post-production test program ...). ALL dongle port access should be controlled and checked in the FT2232.c. The FT2232 should not give to higher layer the possibility to have an direct access to the dongle port. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 : HIGH SPEED USB JTAG CABLE ADAPTER DONGLE DRIVER I don't think this is heavily an issue here. As you say, this feature is not a issue. But I send a BIG WARNING HERE ! This functionality might be disabled by default and not recommended for inclusion in distributions. WE HAVE TO MAKE SURE TO DO NOT *release* ANY OPENOCD WITH THIS FEATURE ENABLED !!! CEDEROM, do you have add an explicit define to enable this feature at compilation. If not please send a patch. But easy way to write drivers for custom dongles in config files heavily reduces costs of development and production. True, for development prototyping. False, for production. I am certain this kind of bitbang TCL features, as it is now, will make the OpenOCD unstable at long term, since it bypass layout specification at higher software level. There are big differences between the How to bitbang the FT2232 and How to bitbang a specific dongle layout-port. Yes, it is easy but NOT SAFE for the end-user. S. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 : HIGH SPEED USB JTAG CABLE ADAPTER DONGLE DRIVER ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: // // On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // Instead, just produce a warning // // Why? // // It merits a comment at least? // // Seems self-evident to me. // Why should it be fatal just because a value couldn't be read? // Doesn't stop anything from working. // // Why should we support broken hardware or drivers? // // Better the user is told to toss his busted dongle / hardware than to tangle // with subtle followon errors? / Nothing to do with hardware. It's a problem with the driver. See http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html / / Objection ! If we cannot read this value back, this means we reach trouble with driver or device somewhere. Also, this trouble could affect following access ... This is why we stop with fatal error. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 USB JTAG INTERFACE ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Hi Øyvind Harboe, Please refrain from shouting(using uppercase). It's more likely that people will ignore your email than read it. Thank you for the advice. As a maintainer, I'm not terribly excited about bitbanging and other non-CPU related protocols. Projects like UrJTAG pursue this sort of avenue. I'd like to see OpenOCD focusing on CPUs. Yes, you're right and I join you. I'd like to see openocd as an on-chip debugger, as a robust software implementing jtag swd trace solution. I'd like to see urjtag as a universal jtag solution, as a robust software implementing boundary scan solution. I'd not like to see openocd nor urjtag as a generic software allowing the users to bitbang an usb io port. That's the better way to have long term issues, and more support for nothing usable. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-Speed USB JTAG. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, 20 Jun 2011 16:37:32 +, Tomek CEDRO wrote: Laurent, 1. If you create cable that have ADC onboard (like KT-LINK) then it is easier to write simple TCL script to read ADC than rewrite whole driver in the source code. Yes, easy but dangerous, because you are layout specific !!! 2. If you need to program I2C, SPI, or other kind of memory, you simply write simple TCL script to do so, no need to rewrite source code from scratch. Again, layout specific 3. If you care not to short-cirtuit your internal buffers, put 27R resistor in series between FT2232 and buffer output. 27R as protection is not enough ... U=RI P=UI ... at 5V ??? 27R are as serial resistor termination not protection ... do not confuse. 4. No interface has hardcoded signals by default, Wrong ... it is depending on the configuration of the ft2232 UART or FIFO ... so noone is obligated to use ANY pin configuration for their device. This functionality is meant to be placed inside interface configuration, or work on generic signals defined by the interface configuration (ie LED, RnW, MOSI, MISO, CLK, ...), so yes in fact external scripts also can work with interface-specific configuration :-) Yes ... 5. I see no reason that non-aware users should block functionalities for people that need them and know how to use them, otherwise we need no development. My objective is not to block feature.Never,never,never ... But we have to avoid any trouble in generic ft2232 driver regarding specific layout. That's all. Your TCL bitbang will control the port of the FTDI from an higher level than FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you accept or not the use of the TCL procedure, if you do not have the notion of layout in this function ??? You have two solutions: You need to write a specifc driver (), or you need to filter the TCL bitbang action in the ft2232 generic driver. The filter must be specifc to the open layout ... The same is for SRST TRST control. The ft2232.c driver has specific functions for SRST TRST regarding layout used ... we have to do this for ANY other specific layout signal in the ft2232.c or write a specific driver. If you have any additional questions of doubts feel free to ask :-) How does the ADC controlled from K T ? Regards, Tomek Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Tomek CEDRO wrote: On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch amotec-laurent_ga...@mail.axianet.ch wrote: Your TCL bitbang will control the port of the FTDI from an higher level than FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you accept or not the use of the TCL procedure, if you do not have the notion of layout in this function ??? Let's assume we want to use our specific interface to quickly flash the SPI memory because we have no time to get familiar with source code and complex program internals... You say yourself : a specific interface. The specific interface, for a ft2232 based dongle is in the layout. some_very_specific_interface.cfg: (..) interface_signal MOSI 0x01 interface_signal MISO 0x02 interface_signal SCK 0x04 interface_signal EN 0x08 interface_signal SPI0 TCL script then can check if signal SPI is defined (no mask value, so no pin is driven, it is only informational), if so check if other signals are defined and proper value, if so work the SPI operation, if not return error because interface does not define/support necessary signals. If no such signals are defined by interface configuration file, there is no option to drive those signals on that specific interface, so there is no worry anything get broken. Again - signals are to be defined inside interface configuration file, so the signals are also layout specific. This is far more better solution than hardcoding them into source code... Better for what ? Yes, for a easy bitbanged pin access, but this will be dangerous for end-user, and you bypass the ft2232.c where the specific layout is controlled. And, you have to check the signal interface ??? Btw. I have to add signal check interface to TCL command :-) How to make tcl command return some value that can be used for later calculation (i.e. interface_signal mask returns 0 for SPI signal, 1 for MOSI, 2 for MISO, ...) ? Again, you have a notion of check ... that you should do hardcoded in the source code. How does the ADC controlled from K T ? It is connected somehow to free IO pinf on the FT2232H port. So it is specific to a given layout ... but you do no let know which pin to the end-user ... Best regards! :-) Tomek Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-swd merging
On Wed, Jun 15, 2011 at 11:06 PM, Rodrigo Rosa rodrigorosa.lg at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / i'm not sure i'm getting this right, i think i know very little about // how this stuff works... // // i had modified ft2232.c // in ft2232_execute_queue, instead of doing layout-blink was using some // mpsse commands to set/clear read/write gpio pins available on the // ft2232, which are not used by jtag. / SWD and other transports will use bitbang() and transfer() new interface methods to work on the bus. queue_flush() / execute_queue() is jtag only function and should not be used for transports other than jtag, as it is too jtag-only as it works on commands queued on CMD_CTX, but these are jtag only. BAD ! and WHY it is too JTAG-ONLY? For me the queue_flush and execute_queue should be the mechanism to be used for ALL transport, JTAG and new one as SWD. As you can see, the queue management is done in the DRIVERs, since it is dongle specific. I remember when I helped Dominic Rath, the author of openocd, about to enqueue command for having a better download speed. OpenOCD start with JTAG transport, but the mechanism of queue should be present for any king of transport. If not, we will degrade the transport speed. We ALL know the pure bitbang is really bad when we talk about USB-x-transport due to the latency of the USB. There are ways to have both SWD and JTAG passed in a queue of command, and the same queue. By definition, a queue of commands is not related to any transport. The command queue just pack the command bytes to have a better speed, larger byte packets. the idea is to become transport independent, so the context and queue will be now part of given transport. SWD is specific data transport protocol as the JTAG, as the I2C, as the 1-WIRE.. If libswd is transport independent, why do you call it libswd. Or do you want to provide libjtag libswd libi2c lib1wire. In this case openocd has jtag.c why not a swd.c ? libswd for instance has swd_ctx holding all settings and queue, each libswd function works on this context, so there may be many different contexts in use with no collisions. this swd_ctx will be hold by void pointer in transport structure (void so any other context can be used as well). / i need is some way to type my_function_in_ft2232.c some_arg in the // telnet interface so that the function my_function in ft2232.c gets // called... // i managed to make the chip do what i needed without using swd. // maybe i can get around with some patch on ft2232.c and jtag interface... // // how are you testing stuff without the jtag command in the cfg files? / target operations are not yet ready. jtag functions are jtag only. agree there is a mess because i am using some functions or structures having jtag in their name only because some time ago noone considered other transports than jtag, so instead oocd_interface there is jtag_interface etc. Why did you not copy/paste and rename the the JTAG_ by SWD_ and call the SWD_ from you libswd, instead to call JTAG functions from you libswd. OK, this will duplicate the code in the driver, but that's will help to introduce the SWD API. this must be fixed after transport is functional, This should be a priority. i wanted to rename this stuff before but it took too much time, so i decided to first make transport working and later reorganize openocd interals as time is limited... OK, time is limited. But, the bad thing is that the SWD API is not yet specified. With Dominic Rath, we have specified the JTAG API before implementing the specific driver ... ft2232 specifc comment: The ft2232.c must have specific SWD functions, but we cannot write it before we specify the SWD API. We cannot imagine to have a libswd making itself a kind of specifc bitbang calls, just because a specific ft2232 layout (K T Link) needs to tristate the SWD TMSIO signal, by bitbangging the ft2232. The how we tristate the TMSIO is not the job of the libswd, but is the job of the specific driver. Or your libswd should be called libswdmpssebitbangkt. As first step, the openocd should have a swd.c (maybe something like your libswd) as we have jtag.c, with a well defined API. Then each specific driver, as the ft2232, should integrate the SWD API calls. For the ft2232.c, the SWD will certainly be coupled with the specifc layout. Example, the Amontec JTAGkey-3 will come with an other layout than k T Link, so there will be specific SWD transfer for each layout. More, the Amontec JTAGkey-3 will not need to bitbang the FT2232 to tristate the SWD TMSIO, but will use pure mpsse shift only :-) .) Maybe my comments could be again a little bit negative to you, sorry. But I try to be objective and to help the discussion. Regards, Laurent Gauch http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 HIGH-SPEED USB JTAG INTERFACE ADAPTERS CABLES Best regards! :-) Tomek
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
Hello Laurent! :-) On Thu, Jun 9, 2011 at 6:21 AM, Laurent Gauch laurent.gauch at amontec.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / But before to close the handle we should still be able : // -1- to tristate signal High-Z via all the out enable signals used in the // specific layout, BUT BUT BUT ONLY if we have entered in the MPSSE mode. / The whole driver works in MPSSE mode... WRONG ! The driver put the ft2232 in MPSSE in the init . And this is real not the same. / (If you have a Amotnec JTAGkey-2 you may verifiy this by checking the // external yellow LED. This LED should be OFF after any quit/shutdown) // As I explained with the TRST and OMAP in previous message ... / I have created simple quit() that sets all port pins high and as input (mpsse command 0x80 0x82) but that did not shut down the yellow led :/-( / You do something wrong. With the sebastien patch 5/5. It works. But we have done a specific jtagkey layout deinit. Do you have any other ideas on what should be done on ft2232_quit() except rtck, hi-z, div5..? I can prepare a patch, or Peter will as I can see he is already working out the subject :-) reset bitbang MPSSE mode and quit the MPSSE mode :-) :-) :-) :-) Best regards :-) Tomek Laurent Gauch http://www.amontec.com/jtagkey.shtml GENERIC USB JTAG Interface ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/5] ft2232: Refactor ft2232_init_*() into ft2232_initone()
On Thu, Jun 9, 2011 at 10:57 PM, Andreas Fritiofson
andreas.fritiofson at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ ft2232_init really refers to init of the openocd driver, while
// ft2232_init_{libftdi,ftd2xx} refers to init of the ftdi subsystem including
// hardware (using either of the libraries). Different inits, hence one and
// all is not the suitable distinction. How about ft2232_init_ftdi that could
// be interpreted as initializing the ftdi library, the ftdi chip or the ftdi
// handle, all of which are true?
/
The current organization for me is okay - there is a standard
ft2232_init() function that call ft2232_init_ftdi() if the program was
built with libftdi or ft2232_init_ftd2xx() if the program was built
with libftd2xx. There is no need to complicate this behavior as
exactly the complication was the problem with previous patches.
Please let //ft2232_init_{libftdi,ftd2xx} .
Maybe we will have D2XX open source in next future :-) , and the both
libftdi and d2xx could be loaded dynamically.
//
Please remember guys also to properly fix the ft2232_quit() as Laurent
proposed, this is also necessary to bring interface to default state
on quit :-)
And not only the specific layout, but the mpsse must be reseted.
We have to make sure to put the dongle at is initial state as if it was
just plugged in the computer.
Gotos are okay in presented case where avoiding gotos bring
unnecessary complication.
Go with goto ... it is only code style :-)
Best regards! :-)
Tomek
Laurent
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 making JTAG a snap
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Thu, Jun 9, 2011 at 10:17 PM, Tomek CEDRO tomek.cedro at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Hello Laurent! :-) // // On Thu, Jun 9, 2011 at 6:21 AM, Laurent Gauch laurent.gauch at amontec.com https://lists.berlios.de/mailman/listinfo/openocd-development // wrote: // But before to close the handle we should still be able : // -1- to tristate signal High-Z via all the out enable signals used in the // specific layout, BUT BUT BUT ONLY if we have entered in the MPSSE mode. // // The whole driver works in MPSSE mode... // // (If you have a Amotnec JTAGkey-2 you may verifiy this by checking the // external yellow LED. This LED should be OFF after any quit/shutdown) // As I explained with the TRST and OMAP in previous message ... // // I have created simple quit() that sets all port pins high and as input // (mpsse command 0x80 0x82) but that did not shut down the yellow led // :-( // / Since the suitable setting depends on the mapping of the GPIOs and the surrounding electronics, the quit function would probably need to be layout specific, as Laurent mentioned. That's will be better ... and as we will have specific init based layout we will have specific deinit based layout ... we come back again to the Sebastien patch where open, init deinit, close are decoupled ... I think you are beginning to understand :-) / Do you have any other ideas on what should be done on ft2232_quit() // except rtck, hi-z, div5..? I can prepare a patch, or Peter will as I // can see he is already working out the subject :-) / What problem is setting pins to a default state on exit supposed to solve? Are we sure this is what we want? If I make openocd pull the reset line and then quit openocd, I'd expect the target to remain in reset. If I quit openocd while the target is running, I'd expect it to keep on running. How would that work if we make this change? What do you mean by PULL? If you close the openocd, we have to put both SRST and TRST in High-Z . That's the normal case, any other case are specific to a custom debug procedure. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-speed USB JTAG DEBUGGER PROGRAMMER Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
/ Hello Andreas :-) // // On Thu, Jun 9, 2011 at 11:30 PM, Andreas Fritiofson // andreas.fritiofson at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // I have created simple quit() that sets all port pins high and as input // (mpsse command 0x80 0x82) but that did not shut down the yellow led // :-( // // Since the suitable setting depends on the mapping of the GPIOs and the // surrounding electronics, the quit function would probably need to be // layout // specific, as Laurent mentioned. // // I think setting all pint as input create Hi-Z for them, so his is the // safest choice and _should_ produce situation as if the interface was // not connected at all... unless interface use some buggy buffer // construction where high impedance would cause output to be active. I // thought that was what Laurent mentioned... it sounds sensible, but // maybe I did some error somewhere... // / Setting the FTDI pins to Hi-Z is not necessarily the same as setting the pins in the JTAG connector to Hi-Z. There is arbitrary dongle-specific interface logic between the FTDI chip and the connector. Yes, true. That's why we need specific deinit function on the specific layout . The Layout deinit is specific, the how-to close the MPSSE is generic. Regards, Laurent http://www.amontec.com Amontec JTAGkey USB JTAG interface ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Thu, Jun 9, 2011 at 11:46 PM, Andreas Fritiofson andreas.fritiofson at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Setting the FTDI pins to Hi-Z is not necessarily the same as setting the // pins in the JTAG connector to Hi-Z. There is arbitrary dongle-specific // interface logic between the FTDI chip and the connector. / Not true. Good example here can be KT-LINK SWD+JTAG buffers [1] configuration designed by Krzyszfot Kajstura - all signals can be electrically disconnected from target and they are in default configuration (after powerup). This is really nice design, also the first open SWD+JTAG for FT2232H chip. Interface can also offer additional signals such as various resets and control that also should be disconnected, especially for other transports. Upcoming SWD framework make use of existing ft2232 code, also the ft2232_quit() function, so there is a default possible behavior common to all ft*232-based devices. Thats not that complicated, isn't it? [1] http://sourceforge.net/apps/mediawiki/stm32primer2swd/index.php?title=File:Ktlink-buffers.png Best regards, Tomek You say Not True and you refer to a specific dongle layout ? Strange. For our Amontec JTAGkey, putting all FT2232 Channel A in HIGH-Z during MPSSE will be enough as the KT, but it will be much stronger if we have specific deinit function for each layout, as we have a specific init function for each layout ... Regards, Laurent http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Fri, Jun 10, 2011 at 12:35 AM, Andreas Fritiofson andreas.fritiofson at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / What are you talking about? Not all ftdi dongles are wired like this = // there is no universal default setting suitable for all dongles. / Uhm, I read bad at 3am :-) You told that not always setting Hi-Z on FT chip equals Hi-Z on JTAG connector.. right? This is obvious and I told that there might be strange buffer design where Hi-Z activates its outputs (not LOW as should). I gave you and example of good design of buffer design allowing FT chip also to work with SWD and possibly any other transport. For this kind of good design there _is_ universal behavior (read more below) :-) Also note what Laurent told: On Tue, Jun 7, 2011 at 9:34 AM, Laurent Gauch laurent.gauch at amontec.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Without doing something within deinit, we still have strange openocd // inter-session phenomena (as TRST still driven instead to be TRISTATE ... // really important for debugging TI OMAP ! ) / Not sure if OUTPUT-HIGH for FT2232 means Hi-Z but most buffers you mention in those interfaces are tri-state buffers from what I have seen on ~5 different devices. Tri-state buffers are active-low, so setting pins to input (Hi-Z) should give Hi-Z on connector in most cases... strange designs may require layout-specific quit function but this is trivial to add :-) For OpenOCD, the important is not to know if a dongle has active-low or active-high buffer ... The important is to deinit correctly. 1. deinit the specific layout if needed 2. put mppse in default configuration 3. put Channel X pins of FTDI in initial state 3. reset the bitbang mode Then close the handle. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
/ / Do you have any other ideas on what should be done on ft2232_quit() // // except rtck, hi-z, div5..? I can prepare a patch, or Peter will as I // // can see he is already working out the subject :-) // / // // What problem is setting pins to a default state on exit supposed to // solve? Are we sure this is what we want? If I make openocd pull the // reset // line and then quit openocd, I'd expect the target to remain in reset. // If I // quit openocd while the target is running, I'd expect it to keep on // running. // How would that work if we make this change? // What do you mean by PULL? // If you close the openocd, we have to put both SRST and TRST in High-Z // . That's the normal case, any other case are specific to a custom // debug procedure. /Why *do* we have to do that? If I quit OpenOCD, I expect the target to stay in the same state as before. If it was in reset, I expect it to stay in reset and not start some code uncontrolled. cu Michael When you launch OpenOCD or any other software, they do not know the state of your target . When you quit OpenOCD or any other software, by default, you do not know in what state to let the target. That's why, by default, the Donlge must have all output High-Z before a quit of OPENOCD! Laurent http://www.amontec.com Amontec JTAGkey-2 HIGH-SPEED USB JTAG ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] use one configuration for all JTAGkey devices.
Jean-Christophe PLAGNIOL-VILLARD wrote: On 08:42 Thu 09 Jun , Laurent Gauch wrote: On 15:25 Tue 07 Jun , Laurent Gauch wrote: / // /If our ft2232.c patches are not merged quickly, Amontec Team will certainly // // come with a new specific jtagkey.c API driver instead of the ft2232.c JTAG // // driver. // // The advantage with a specific Amontec JTAGkey API driver in openocd, will be // // to see our patches merged in the minute, instead to wait 1 to 2 months ... // // also the ft2232.c will still be usable for the JTAGkey. // / // This is the solution, you will have your own driver to manage then :-) // But you will then create another DRIVER not API as the interface API // is already set :-) // Yes, a specific jtagkey driver with a wrapper for the existing // openocd API ! Yes, that's the idea. // The user will be able to use the classic ft2232.c or the specific // jtagkey.c as a jlink.c! // Maybe that's the road to follow if our patches take so long time to // be merged on ft2232.c. /except on jlink we have a 100% different API All specific dongle interface (DRIVER) are based on the same API (known as JTAG API). API - DRIVER - DONGLE my key point the Amontec are based on ft2232 the jlink on the sam7 they do have 100% different API to deal with the chip/firmware Maybe we do not talk the same when we talk API and Driver. Segger JLINK are based on sam7 and Amontec JTAGkey on ft2232 (for now). Yes. Both dongles have different DRIVERs. Yes. Both DRIVERs are controlled by the same JTAG API, in OpenOCD. The JTAG API and the specific DRIVERS are a HAL construction (Hardware Abstraction Layer). so as a Maintainer I NACK duplicate code as there is no good reason to do so exception for short term such a cleanup in progress or code refactoring Yes, you're right. But I never said, jtagkey.c will be a code duplication of ft2232.c. but your proposal is not this as at all, it's to do it on long therm which is not acceptable That's why we still provide amelioration ideas and patches for ft2232.c. Best Regards, J. Laurent http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
Am 06/10/2011 09:33 AM, schrieb Laurent Gauch: / // / Do you have any other ideas on what should be done on ft2232_quit() // // except rtck, hi-z, div5..? I can prepare a patch, or Peter will as I // // can see he is already working out the subject :-) // / // // What problem is setting pins to a default state on exit supposed to // solve? Are we sure this is what we want? If I make openocd pull the // reset // line and then quit openocd, I'd expect the target to remain in reset. // If I // quit openocd while the target is running, I'd expect it to keep on // running. // How would that work if we make this change? // What do you mean by PULL? // If you close the openocd, we have to put both SRST and TRST in High-Z // . That's the normal case, any other case are specific to a custom // debug procedure. /Why *do* we have to do that? If I quit OpenOCD, I expect the target to stay in the same state as before. If it was in reset, I expect it to stay in reset and not start some code uncontrolled. Yes you're right Michael regarding the state of the TARGET. Did you already have needed to have SRST to be assert low at the end of the openocd to force the SYSTEM RESET on the target board ? If yes, putting systematically all signal to High-Z at the output of the dongle could be a trouble. But I am not sure it is the 95% of debugging/programming case. Regards, Laurent cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
/ // I suggest to drop this patch and merge a simpler fix for the problem // adressed by this patch. Only a few lines of code would need to change. // // /Attached is such a patch. The benefit over Tomek's patch is that it frees not only the allocated buffer but also closes the ftdi handle (as was done in the original patch). Plus I'm not very fond of the infinite-loop-that's-not-actually-a-loop-at-all along with the extra indentation. This patch doesn't use gotos either but another (perhaps even more) neglected construct, like it or not. :) Hi Andreas, Looks OK to me ! (And you did not use the goto, nice.) But before to close the handle we should still be able : -1- to tristate signal High-Z via all the out enable signals used in the specific layout, BUT BUT BUT ONLY if we have entered in the MPSSE mode. -2- (to deactivate the RTCK if it was activated, put the frequency divisor in it initial value ...) -3- to reset the MPSSE bitbang mode, BUT BUT BUT ONLY if we have entered in the MPSSE mode. NOTE: The point -2- is not really important. But, it is really important to let all JTAG SWD signal HIGH-Z before closing the interface, this avoid openocd or other programm to have inter-session troubles. (If you have a Amotnec JTAGkey-2 you may verifiy this by checking the external yellow LED. This LED should be OFF after any quit/shutdown) As I explained with the TRST and OMAP in previous message ... (This is not only important for the coming Amontec JTAGkey-3 with SWD support, but for ALL the actual device based FTx232 ) . To do this I still will do the job with a mechanism as proposed by Sebastien patch (separation of the how-to open/close the device and how-to int/deinit it), with : open(hanlde) init (device layout) deinit (device layout) close(handle) But we can go with your patch first, and change later, or find an other mechanism to be able to close the device robustly :-) For Amontec, the objective is to have something clean, but we are not sensible to the code style nor the mechanism used to resolve the problem. I am happy to have activated the rework on ft2232.c :-) Thank you all for your time and work on this. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 Generic High-SPEED USB JTAG CABLE interface. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232: fix memory leak in ft2232_large_scan()
Free the buffer before return. Also check the malloc return value.
Perhaps it's not a good idea to exit() on error, but it's in line with the
rest of the function.
Strange thing with this function is that the allocated buffer doesn't seem
to be used for anything. The data read into it doesn't go anywhere. Maybe
the entire function is flawed, or is the data really supposed to be
discarded?
Signed-off-by: Andreas Fritiofson andreas.fritiofson at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development
---
src/jtag/drivers/ft2232.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index a3b87c3..9fb4d48 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -1142,6 +1142,12 @@ static int ft2232_large_scan(struct scan_command* cmd,
enum scan_type type, uint
int retval;
int thisrun_read = 0;
+ if (!receive_buffer)
+ {
+ LOG_ERROR(failed to allocate memory);
+ exit(-1);
+ }
+
if (cmd-ir_scan)
{
LOG_ERROR(BUG: large IR scans are not supported);
@@ -1341,6 +1347,8 @@ static int ft2232_large_scan(struct scan_command* cmd,
enum scan_type type, uint
receive_pointer += bytes_read;
}
+ free(receive_buffer);
+
return ERROR_OK;
}
Good to me.
Regards,
Laurent
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 Generic High-SPEED USB JTAG CABLE interface.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] use one configuration for all JTAGkey devices.
On 15:25 Tue 07 Jun , Laurent Gauch wrote: / // /If our ft2232.c patches are not merged quickly, Amontec Team will certainly // // come with a new specific jtagkey.c API driver instead of the ft2232.c JTAG // // driver. // // The advantage with a specific Amontec JTAGkey API driver in openocd, will be // // to see our patches merged in the minute, instead to wait 1 to 2 months ... // // also the ft2232.c will still be usable for the JTAGkey. // / // This is the solution, you will have your own driver to manage then :-) // But you will then create another DRIVER not API as the interface API // is already set :-) // Yes, a specific jtagkey driver with a wrapper for the existing // openocd API ! Yes, that's the idea. // The user will be able to use the classic ft2232.c or the specific // jtagkey.c as a jlink.c! // Maybe that's the road to follow if our patches take so long time to // be merged on ft2232.c. /except on jlink we have a 100% different API All specific dongle interface (DRIVER) are based on the same API (known as JTAG API). API - DRIVER - DONGLE sorry but duplicate code is wrong and will never help the maintainnce if no-one reply to your for some times the maintainer will have to take a decision, as a Maintainer I do simple if it looks good and the code make I apply it. If it break something we can fix it or revert it later / I think project needs more support in cleanup and maintenance at the // moment, as there are some doubts on even more changing or complicating // existing code, creating your separate playground for testing new // features seems sensible. // You're right. // Also if you want to make a release, make it // happen, do not expect other to do the job for you. Please note that // this is not against your ideas, the project simply needs to be cleaned // up and restructurized because it gets more and more complex with new // functionality that is still growing and can get out of control soon. // // This is all kept koherent by only one (?) person that does not take // money for all this time and effort to keep things organized. // OpenOCD should accept more maintener, with different maintener right // levels (layers). /yes that could be a solution but a ft2232 maintainer MUST tkae care of other hw design not be focused on one design only Best Regards, J. Regards, Laurent http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 Generic High-SPEED USB JTAG CABLE interface. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
Hi Michael, Am 06/06/2011 02:10 PM, schrieb Laurent Gauch: / Yes, this is to decouple the open and init (open the handle, init // the associated specific layout). / Is there case where open is used without init, or init without open? Actually no. But in the ft2232.c we could have the possibility to only re-init a device+layout without the need to close open the handle. Sure this will be useful when the ft2232.c will provide the possibility to init for 'JTAG only' or init for 'SWD only' on a already opened handle of the device. No ? Otherwise, this is just unnecessarily complex. / (more smaller function ... as good OO coding !) // // The ft2232_init_sub(void) and ft2232_init() could be merged again in a // ft2232_open if needed // // But yes, we have all different point of view regarding what is open // what is init ... // // The objective is to have something like : // // open // init // deinit // close // // and not as the actual // init // quit / open/close instead of init/quit is OK with me, but what is the advantage of the 4-function API instead of the old 2-function API? Now I understand . You are thinking we want to change the API of the interface. NO NO NO . We just want to decouple the open close handle and the init deinit device + layout INSIDE the ft2232.c. See the patch, we do not rename the quit() init(), we do not touch the API concept ! cu Michael Laurent http://www.amontec.com http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
Hi Tomek, First, thank you for giving objective comments on the patch. Much appreciated from you. (Much better than the Student code galore from Peter) Hello Laurent, Sorry if my comment seems not meritoric, I am not mentioning about coding style because this leaves a lot to tell in case of all program source tree. I am not advanced OpenOCD developer, I am learning code internals for some time and I have some grasp on it already (enough to recognize the function we are talking about without looking at the code because I have already worked on it). Please take a look at my explanation why I think this patch is not that good ant try to convince me (maybe others?) that I am wrong :-) I reply on your text, maybe I can convince you. 1. The reason to propose this patch was improper error handling. OpenOCD works in a manner where functions return ERROR_OK or ERROR_FAIL, all additional/verbose information are provided by LOG_* messages. This is also the case in ft2232_init(), so no need to change. If you change this all other interfaces will behave different, so the code gets dirty and unpredictable. This is a standard behavior for all of the code. Yes, right. But the patch do not touch the error mechanism, which one is good enough. 2. The malloc() problem can be solved in a simple way as demonstrated by my patch. No need to complicate things, no need to add other functions that makes code less readable. The patch resolve it. 3. All interfaces have init() and quit() functions. If you change this for one type of driver the code will get dirty as one drivers will behave other than another interfaces. This should be avoided. Yes, the patch do not touch the API. We still have the init and quit for the high layer acceding the ft2232 interface. 4. What is the real benefit of implementing/splitting open() and init() for interface? Interface is a platform for further program operation. Without interface program cannot work properly, so what would you like to do with interface that is opened but unusable/uninitialized? The current behavior is simple - interface initialization failed, so will other things, retry or quit, don't go futher. Interface init() checks if interface is connected and sets up its state, this is enough for one function, why you want to split it? Again the goal is to have INSIDE the ft2232.c something like : open(open the ft2232 handle) init(init the ft2232 device) deinit(deinit the ft2232 device) close(close the ft2232 handle) From the JTAG INTERFACE API (higher layer point of view) we still have the only two functions init (init the interface) quit (quit the interface) Globally we have: init (init the interface) open(open the ft2232 handle) init(init the ft2232 device) deinit(deinit the ft2232 device) close(close the ft2232 handle) quit (quit the interface) The objective is to provide at middle term a better code and more comprehensible code for the FT2232.c. From the higher level, you still init and quit the interface. But in the ft2232 interface, we separate open / close the handle and the init / deinit the device. In the open and close we should only process the ft2232 handle In the init and deinit, we initialize and deinitialize the ft2232 device ( the MPSSE mode and the specific layout with specific function (as jtagkey_init) ) Actually the deinit is not implemented and it should be done quickly. The deinit should first deinitialize the specific layout (as a jtagkey_deinit), then disable the MPSSE / bitbang mode for any USB JTAG based ft2232. Objective is to let see the ft2232 device as if it was just plugged (after a power-off - power-on). After the deinit of the ft2232 device is done, we can close the ft2232 handle ... Without doing something within deinit, we still have strange openocd inter-session phenomena (as TRST still driven instead to be TRISTATE ... really important for debugging TI OMAP ! ) If you have a Amontec JTAGkey-2 you can see the yellow LED stays active ON after a shutdown of openocd. The yellow LED on Amontec JTAGkey-2 let know the users that one of the TRST_OE_N SRST_OE_N JTAG_OE_N are/is still asserted. This mean, actually, the openOCD did not correctly deinit the jtagkey layout nor the MPSSE nor the bitbang mode, before closing the handle ... in other term : We do not deinit the device before closing the handle ... That's make troubles in inter-session of openocd ... So the deinit is really important, but was never implemented. The patch will help to quickly integrate the deinit of a specific layout and deinit of the MPSSE mode. (Sebastien is ready to send patch concerning the deinit) Also, you can see the importance of decoupling the : open / close of the FT2232 handle init / deinit of the FT2232 device 5. There is a transport layer above interface, transport has select() and init() - maybe this is the place you should place your code? Transport select() function sets up interface and
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
/ Please just use goto to handle errors. // // /*When we talk coding style with students, the first comment I have is : // DO NEVER USE GOTO STATEMENT BUT USE IF ELSE IF ... / I'm afraid that's not only doing your students a disservice, but also their future employers. Sorry, but I prefer to use structured approach where neither /goto/ nor multiple /returns/ are needed. But if readability is only your concern, GOTO is not so bad. / Sometimes goto is still used in complicated function to simplify // the jump ... But the better should be to split your complicated // function in sub functions ... / Creating sub functions is a good workaround in languages where goto is missing, but in C that is not the case. Again; please just use goto to handle errors. Have a look at the Linux kernel, they do this well over there. Yes, I am sure goto is used somewhere in the big Linux kernel source code . And that's not a problem for me. But my experience say me that /using goto/ is a symptom of a bigger set of problems ... That's only code style, nothing else ;-) //Peter I do not like to code spaghetti using goto statement , but I like to eat spaghetti! Regards, Laurent http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-speed USB JTAG dongle ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
Hi Andreas, Thank you for your comment. It doesn't build. Leftover variable no longer used. minor issue Apart from that it seems OK from my limited review. I could agree with the others that it looks like a needlessly complex fix for a simple missing free. Maybe there's a bigger picture here but I don't get the open/init deinit/close separation or why it's needed (Why would you want to open without initializing?). Haven't given it much thought though. Is the mentioned followup patch already posted? The mentioned patches are not posted, but ready to. As asked by maintainer's, we want to have small and precise patches. We only posted the patch 1/5 . https://lists.berlios.de/pipermail/openocd-development/2011-May/019176.html We want to have it merged before to give the 2..5/5. The 2..5/5 will be depending of the acceptation of 1/5 ... --- We do not want to open without init, but we want to init or re-init an already opened device handle :-) In the same way, we want to deinit without having to close the device handle ! In an other way, we want to be able to force deinit and close or close only without having to have a interface quit() call from the upper layer, in case something wrong during open init or others. We want to make sure any USB JTAG SWD adapters based ft2232 (as jtagkey) are correctly deinitialized at any shutdown of openocd (as via jtagkey_deinit). (Actually nothing is done during the quit except close the handle ... but we have to make sure deassert JTAG PORT AND TRST SRST IO (and to deassert SWD mode), to reset the MPSSE, to go away the bit-bang mode, and only then close the handle) If we split this to a deinit() close() we will produce a much better code. Having open init deinit close well separated IN the ft2232.c will help us to make the ft2232 interface more robust and more clean. But remember, the open init deinit close ARE NOT ON THE INTERFACE API, Regards, Laurent http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-speed USB JTAG dongle ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] use one configuration for all JTAGkey devices.
/If our ft2232.c patches are not merged quickly, Amontec Team will certainly // come with a new specific jtagkey.c API driver instead of the ft2232.c JTAG // driver. // The advantage with a specific Amontec JTAGkey API driver in openocd, will be // to see our patches merged in the minute, instead to wait 1 to 2 months ... // also the ft2232.c will still be usable for the JTAGkey. / This is the solution, you will have your own driver to manage then :-) But you will then create another DRIVER not API as the interface API is already set :-) Yes, a specific jtagkey driver with a wrapper for the existing openocd API ! Yes, that's the idea. The user will be able to use the classic ft2232.c or the specific jtagkey.c as a jlink.c! Maybe that's the road to follow if our patches take so long time to be merged on ft2232.c. I think project needs more support in cleanup and maintenance at the moment, as there are some doubts on even more changing or complicating existing code, creating your separate playground for testing new features seems sensible. You're right. Also if you want to make a release, make it happen, do not expect other to do the job for you. Please note that this is not against your ideas, the project simply needs to be cleaned up and restructurized because it gets more and more complex with new functionality that is still growing and can get out of control soon. This is all kept koherent by only one (?) person that does not take money for all this time and effort to keep things organized. OpenOCD should accept more maintener, with different maintener right levels (layers). But you are right, before doing this, the different layers should be reorganized in the way to accept new debug concepts. This is my personal opinion, maybe other people think different, but there might be a point where new people won't be able to add new features at all in sensible time soon. I can tell this as a new person here, it took me few months to get familiar with the code. I expected things to be more clear, readable and organized. Adding more complex code that does no more than old simpler code is not a good developlment practice. If you still only want to push things forward, create your separate piece of code and experiment right there without affecting general organization - I can understand this approach - if others dont maybe creating working-copy fork for testing stuff is also a good solution, git helps managing things like this and you have full source code access. But then you would have to manage it yourself to see it is not that trivial task as it might look/seems. To be on topic - on my FreeBSD box using libftdi it seems not to be possible to use one configuration for all interfaces, it does not work, there is a slight difference in ft2232_device_desc, but the vid/pid is the same. Creating separate driver that can handle that on multiple OS should do the job :-) If you try an older openocd 06xx you will be able to open any jtagkey dongle via only the specific VID PID The difference is what function from libftdi you use to open the device. 1. only by PID VID 2. by PID VID Description 3. by PID VID Serial Number ... With older openocd version and with libusb libftdi, we open with 1. , and now we open with 2. . The 3. is used when serial number is present in the .cfg. ;-) Regards, Laurent http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-speed USB JTAG dongle Best regards :-) Tomek ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
Hello again :-)
I have reviewed the patch.
The old source code had 3 functions ft2232_init() that can call
ft2232_init_libftdi() or ft2232_init_ftd2xx() depending on a ft2232
ftdi communication library available. This is pretty simple and
coherent.
Yes simple, but bugged !!!
The new source code (after patching) have 6 functions doing almost
the same: ft2232_init_ftd2xx(), ft2232_open_ftd2xx(),
ft2232_init_libftdi(), ft2232_open_libftdi(), ft2232_init_sub(void),
ft2232_init() and the header update ;-)
Yes, this is to decouple the open and init (open the handle, init the
associated specific layout).
(more smaller function ... as good OO coding !)
The ft2232_init_sub(void) and ft2232_init() could be merged again in a
ft2232_open if needed
But yes, we have all different point of view regarding what is open what
is init ...
The objective is to have something like :
open
init
deinit
close
and not as the actual
init
quit
As I understand the problem is with the ft2232_buffer=malloc() within
ft2232_init() that can fail after malloc causing function return
without ft2232_buffer=free().
The current behavior is as follows: Program returns error and finish
execution because it cannot run without interface. Operating system
makes memory page free on process termination.
The proposed solution is to free() allocated memory before
ft2232_init() returns.
I can understand that leaving allocated memory is bad. However there
is a simpler solution to the problem (patch attached) by only changing
few lines of existing code and leaving driver infrastructure/layout
common for all source code:
ft2232_buffer_size = 0;
ft2232_buffer = malloc(FT2232_BUFFER_SIZE); -- this is the bad malloc
* for (;;){
*if (layout-init() != ERROR_OK) break; -- we jump out on failure
if (ft2232_device_is_highspeed())
{
#ifndef BUILD_FT2232_HIGHSPEED
#if BUILD_FT2232_FTD2XX == 1
LOG_WARNING(High Speed device found - You need a newer
FTD2XX driver (version 2.04.16 or later));
#elif BUILD_FT2232_LIBFTDI == 1
LOG_WARNING(High Speed device found - You need a newer
libftdi version (0.16 or later));
#endif
#endif
/* make sure the legacy mode is disabled */
* if (ft2232h_ft4232h_clk_divide_by_5(false) !=
ERROR_OK) break;
}
buf[0] = 0x85; /* Disconnect TDI/DO to TDO/DI for Loopback */
if ((retval = ft2232_write(buf, 1, bytes_written)) !=
ERROR_OK)
{
LOG_ERROR(couldn't write to FT2232 to disable
loopback);
* break;
}
#if BUILD_FT2232_FTD2XX == 1
retval = ft2232_purge_ftd2xx();
#elif BUILD_FT2232_LIBFTDI == 1
retval = ft2232_purge_libftdi();
#endif
* if (retval != ERROR_OK) break;
* return ERROR_OK; -- do not run infinite loop, return ok if no error
}
*free(ft2232_buffer); -- and land here with freeing bad memory
*return ERROR_JTAG_INIT_FAILED;
In my opinion patch brings only unnecessary confusion and source code
complication, sorry, there is simpler solution. This program does not
need doubling function number and making code even more difficult to
read and understand as it is already enough complicated. Using more
function(void) and global structures only make things worst :-(
%./openocd -f interface/kt-link.cfg -f board/stm3210b_eval.cfg
Open On-Chip Debugger 0.5.0-dev-00895-g796086c-dirty (2011-06-01-20:16)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : max TCK change to: 3 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b,
part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020,
part: 0x6410, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
%./openocd -f interface/jtagkey2p.cfg -f board/stm3210b_eval.cfg
Open On-Chip Debugger 0.5.0-dev-00895-g796086c-dirty (2011-06-01-20:16)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : max TCK change to: 3 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b,
part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020,
part: 0x6410, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
^C
It would be nice however to add Ctrl+C signal capture to gracefully
shutdown the program with proper deinitialization... maybe simple tcl
quit mapping would do the job :-)
The shutdown at upper level already exist and works great, but the
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
Tomek CEDRO wrote:
/ The new source code (after patching) have 6 functions doing almost
// the same: ft2232_init_ftd2xx(), ft2232_open_ftd2xx(),
// ft2232_init_libftdi(), ft2232_open_libftdi(), ft2232_init_sub(void),
// ft2232_init() and the header update ;-)
/
Student code galore.
Did you read the patch comment, explaining the why we split the
functions, or did you just comment the comment ...
Please comment the patch instead to give out-of-topic 'gratis' comment !
/ I can understand that leaving allocated memory is bad. However there
// is a simpler solution to the problem (patch attached) by only changing
// few lines of existing code and leaving driver infrastructure/layout
// common for all source code:
//
// ft2232_buffer_size = 0;
// ft2232_buffer = malloc(FT2232_BUFFER_SIZE); -- this is the bad malloc
//
// * for (;;){
//
// *if (layout-init() != ERROR_OK) break; -- we jump out on failure
/
Please just use goto to handle errors.
/*When we talk coding style with students, the first comment I have is :
DO NEVER USE GOTO STATEMENT BUT USE IF ELSE IF ...
if( condition 1 )
statement1;
else if( condition 2 )
statement2;
else if( condition 3 )
statement3;
else
statement4;
The goto was for the unstructured languages ( as BASIC was ).
Sometimes goto is still used in complicated function to simplify the
jump ... But the better should be to split your complicated function in
sub functions ...
Anyway, this is out-of-topic .*/
//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On Wed, Jun 1, 2011 at 9:23 PM, Peter Stuge peter at stuge.se
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Indeed what you get with good use of goto. The rule is basically to
// only goto in the forward direction within a function. It's very
// simple, and it can make code *tremendously* more readable.
//
// int thing(params) {
// if (error)
//goto handle_errors;
//
// if (other_error)
//goto handle_errors;
//
// if (third_error)
//goto handle_errors;
//
// /* all conditions have been checked, it's safe to do the thing */
//
// for (num = 0; num times; num++)
//do_thing();
//
// return 0;
//
// handle_errors:
// clean_up();
// return 1;
// }
/
I tend to agree on this. This method is used many times and seems like
very good coding practice to me and one of the very rare examples
where gotos are actually useful.
I would stick to this whenever possible. Except that I would declare
one status variable in the beginning, int rc = SUCESS, and then change
it during the function. In case of the error I would do rc = FAILURE;
goto handle_errors; and then instead of :
/ handle_errors:
// clean_up();
// return 1;
// }
/
I'd do :
handle_errors:
clean_up();
return rc;
}
It depends, off course.
BR,
Drasko
out - of - topic.
Sorry, but please comment the patch instead to talk about coding style,
or please start a new thread.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compilation errors
Hi Spen, I just checked the compile again on windows 7 32bits / 64bits. mingw build work for me / tested on 32 bits and 64 bits :-) cygwin build work for me / tested on 32 bits only :-) Great ! Note: as noted on my previous comment, the troubles regarding the configure (April) are gone :-) Regards, Laurent Spencer Oliver wrote: On 27/05/2011 16:51, Laurent Gauch wrote: Hi, You're right, the last version from git cannot be compiled from my mingw too, but can be compiled with my cygwin ;-) But with mingw, i do not have the same error as you, but related to tclsh, strange . just tested a cygwin and msys build - both working fine. Is this s 64bit issue? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compilation errors
I will try again today, but esterday I compiled openocd d2xx on cygwin and on mingw for 32bits and 64bits without any error. Everything fine ! Note: the problem we meet during April is now gone - thank you Spencer Oliver. Regards, Laurent http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-Speed USB JTAG - 1.4V to 5.5V IOS - RTCK support Hi! I'm trying to compile new OpenOCD source (from git) in my crosscompilation setup but I see these errors: / /../../src/rtos/'`rtos.c // libtool: compile: i686-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../../src/rtos -I../.. -I../../../src -I../../src -DPKGDATADIR=\/usr/local/share/openocd\ -I../../../jimtcl -I../../jimtcl -Wno-sign-compare -g -O2 -D__USE_MINGW_ANSI_STDIO -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT librtos_la-rtos.lo -MD -MP -MF .deps/librtos_la-rtos.Tpo -c ../../../src/rtos/rtos.c -o librtos_la-rtos.o // cc1: warnings being treated as errors // ../../../src/rtos/rtos.c: In function ‘gdb_thread_packet’: // ../../../src/rtos/rtos.c:147: error: unknown conversion type character ‘l’ in format // ../../../src/rtos/rtos.c:147: error: too many arguments for format // ../../../src/rtos/rtos.c:223: error: unknown conversion type character ‘l’ in format // ../../../src/rtos/rtos.c:223: error: too many arguments for format // ../../../src/rtos/rtos.c:320: error: unknown conversion type character ‘l’ in format // ../../../src/rtos/rtos.c:320: error: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int64_t *’ // ../../../src/rtos/rtos.c:320: error: too many arguments for format // ../../../src/rtos/rtos.c:473: error: unknown conversion type character ‘l’ in format // ../../../src/rtos/rtos.c:473: error: too many arguments for format // ../../../src/rtos/rtos.c:497: error: unknown conversion type character ‘l’ in format // ../../../src/rtos/rtos.c:497: error: too many arguments for format / Any hints for solving that? Should I try to use a different setup for compiling OpenOCD for Windows (both 32- and 64-bit) - if yes, what do you use? Currently I use i686-w64-mingw32 and x86_64-w64-mingw32 - is there a better option using up-to-date compilers? I had to comment out dlerror definition in jim-win32compat.h but that was simple to fix. The sscanf()s that cause errors look pretty wild... Thx for help! 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compilation errors
Hi, You're right, the last version from git cannot be compiled from my mingw too, but can be compiled with my cygwin ;-) But with mingw, i do not have the same error as you, but related to tclsh, strange . Regards, Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 - how to read/write from/to gpio
Hi Rodrigo, There are nothing really difficult here ! If you get a look at the jtagkey init , you may see how to drive the SRST and TRST as gpio. Do the same for a read ;-) ! The SRST and TRST are controlled from an higher level than the low jtag driver layer :-) Best regards, Laurent http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 High-Speed USB JTAG from 1.4V to 5.5V auto-sense with 32 ma output drivers. Hi, When using channel A of the ftdi 2232H as JTAG there are spare pins available as GPIO. I want to be able to read/write to these pins. I've managed to this by modifying ft2232.c (i'm not planning to change the driver, just wanted to verify it was possible). I would like to have a command i can manually execute (such as halt, resume, etc) to read/write to the gpio pins. What I need is similar to getting a command to manually blink the leds on a given layout (execute layout-blink @ ft2232.c). The difference would be that i want to send/receive parameters. I've been looking around, but everything at levels higher than the driver seems to only use jtag... Any tips/ideas on how to do this? Thanks! -- Rodrigo. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches
Yes, there are patches. Please merge the Sebastien's patch. Now about 4-weeks this patch wait to be merged. Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches
Øyvind Harboe wrote: Please repost the patch. https://lists.berlios.de/pipermail/openocd-development/2011-April/018780.html Merge it ! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches
Øyvind Harboe wrote: Loose the attitude. What ? On Mon, May 16, 2011 at 9:14 AM, Laurent Gauch laurent.ga...@amontec.com wrote: Øyvind Harboe wrote: Please repost the patch. https://lists.berlios.de/pipermail/openocd-development/2011-April/018780.html Merge it ! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches
Øyvind Harboe wrote: https://lists.berlios.de/pipermail/openocd-development/2011-April/018780.html I see that this is not actually formulated as sequence of git patches. Please formulate it as a patch and repost it. That will improve your chances of a review. http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob_plain;f=HACKING;hb=HEAD What is your REAL problem with the patch? Except the rebase, the patch follows the rules in http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob_plain;f=HACKING;hb=HEAD ... If we rebase and send you the same corresponding patch, do you merge it ? - or do you ask again to wait on a review and ask us to rebase again since no review come after 4-5weeks ... Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Multi-core platform support
On 11/05/11 13:54, Laurent Gauch wrote: / Hi Sébastien, // // Amontec is working on the SWD CTJTAG support on JTAGkey-3 generation. // // Could you please let me know where did you get the info : // // TMS is used as a clock while holding TCK at '1' really needs to be // added. // // // Best regards, // Laurent Gauch // http://www.amontec.com / Hello Laurent, You can find this info in the IEEE 1149.7 standard, in the RSU Escape detection section. The RSU is mandatory for the T3 class of TAP controllers (where the star topology is supported). Kind regards, Sébastien. OK I see on IEEE 1149.7 standard specification Figure 11-13 — TAPC parking-state creation with a deselection Escape/Standard Protocol We were on IEEE 1149.7 CJTAG T4 for now (the two wire version) . We have now to see about the CJTAG T3 Escape/Standard Protocol with our new JTAGkey. /Best regards, //Laurent Gauch //http://www.amontec.com http://www.amontec.com/jtagkey.shtml / ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] adapter speed: require init script setting and centralize activation from drivers to core.c
/ +# The chip may run @ 32khz, so set a really low JTAG speed // +adapter_khz 8 // this is the wrong place it's not board specific but soc specific // // tcl/target/at91rm9200.cfg // // Perhaps jtag_rclk 8 should be used, i.e. use RCLK if it is supported // and fall back to 8 khz. Of course post reset init jtag_rclk's fallback // frequency could be increased. /jtalg_rclk 0 I think is better then If the board need to overwrite it the do it after the source of the soc file Best Regards, please respect the 1/6 (Processor frequency / JTAG frequency) in case the RTCK is not present, not featured by the device by the board or not supported by the JTAG interface. please use jtag_rclk 5 in your case. If the RTCK mechanism is supported by your device / your board / your JTAG interface, the JTAG will start generating TCK edges at the maximum frequency featured by the JTAG interface ( as 30MHZ for a Amontec JTAGkey-2 ). The frequency will be controlled by the target via the RTCK signal. So no need to be worry about the frequency of the processor, regarding post init reset procedure ... Laurent Gauch http://www.amontec.com/ Amontec JTAGkey-2 : High speed USB JTAG interface with RTCK / 24mA output driver / auto-sense 1.4V to 5.5V ! http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix: Correctly exit function: ft2232_init when an error occurred
Hello Drasko,
The end goal it's to have a safe state of the used JTAG adapter at the
end of the executable file.
With this patch = Fix: Correctly exit function: ft2232_init when an
error occurred
I wish correct the status at the end of ft2232_init function when an
error occured.
At this moment, in function: ft2232_init the JTAG handle is acquire
with the funtion: ft2232_init_ftd2xx or ft2232_init_libftdi and 131072
bytes are allocate for the variable: ft2232_buffer.
But when an error occured, the JTAG handle isn't free and all allocate
bytes aren't free.
To correct this on the layer ft2232, it's better to clarify the
function: ft2232_init.
And for the end goal, I follow that as speack Laurent:
Open
Init
Deinit
Close
Open it's to acquire the JTAG handle.
Init it's to set all parameters and the pinning of the JTAG adapter.
Deinit it's to be on a safe state with the JTAG adapter.
Close it's to free the JTAG handle.
With this first patch, I have only divided functions and add the part
to close handle and free the bytes of the variable: ft2232_buffer when
an error occured.
So I have take the first part of the function: ft2232_init_ftd2xx and
put to the function: ft2232_open_ftd2xx (from line: 2118 to line: 2230)
And I have remove the unnecessary variables.
The second part of the function: ft2232_init_ftd2xx stay on this
function (from line: 2231 to line: 2278)
I have add the necessary variables.
It's the same work with the function: ft2232_init_libftdi.
So I have take the first part of the function: ft2232_init_libftdi and
put to the function: ft2232_open_libftdi (from line: 2296 to line: 2332)
And I have remove the unnecessary variables.
The second part of the function: ft2232_init_libftdi stay on this
function (from line: 2333 to line: 2366)
I have add the necessary variables.
To not make a lot of change on the function: ft2232_init, I have only
divide the function on two parts and add the part to close handle and
free the bytes of the variable: ft2232_buffer when an error occured.
So the first part of the function: ft2232_init stay on this function
(from line: 2421 to line: 2466)
I have remove the unnecessary variables.
I have change the functions: ft2232_init_ftd2xx and ft2232_init_libftdi
by the functions: ft2232_open_ftd2xx and ft2232_open_libftdi (because
it's the first part of the functions: ft2232_init_ftd2xx and
ft2232_init_libftdi)
I have take the second part of the function: ft2232_init and put to the
function: ft2232_init_sub (from line: 2467 to line: 2508)
I have add the necessary variables.
I have add the call of functions: ft2232_init_ftd2xx and
ft2232_init_libftdi (because it's the second part of these functions)
And to identify the case of an error occured before the JTAG handle be
acquire, I have add:
if (retval != ERROR_OK)
return retval;
(Because if an error occured during the acquire of the JTAG handle, I
think that the JTAG handle stay free.)
To correctly free the JTAG handle and free the bytes of the variable:
ft2232_buffer when an error occured. I have add:
retval = ft2232_init_sub();
if (retval != ERROR_OK)
{
#if BUILD_FT2232_FTD2XX == 1
FT_Close(ftdih);
#elif BUILD_FT2232_LIBFTDI == 1
ftdi_usb_close(ftdic);
ftdi_deinit(ftdic);
#endif
if(ft2232_buffer)
free(ft2232_buffer);
ft2232_buffer = NULL;
return retval;
}
(That is the content of the function: ft2232_quit (from line: 3231 to
line: 3242))
The little modification of the free for the variable: ft2232_buffer,
it's to only free the memory when is necessary (and possible).
--
Regards,
Sébastien Farquet
http://www.amontec.com/
Amontec JTAGkey-2 : High speed USB JTAG interface
3 weeks, no comment.
Please merge the Sebastien'patch.
Regards,
Laurent
http://www.amontec.com/
Amontec JTAGkey-2 : High speed USB JTAG interface
http://www.amontec.com/jtagkey.shtml http://www.amontec.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour
I've noticed strange behaviour in initialization with TI OMAP4430 and
Freescale iMX53 using Amontec JTAGKEY. Even typing keys on OpenOCD shell
was very very slow.
I didn't investigate too much the causes. Anyway this patch fix it.
Signed-off-by: Luca Ellero lroluk at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development
---
src/jtag/core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/jtag/core.c b/src/jtag/core.c
index 4c5d37a..ad662ef 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -1369,12 +1369,12 @@ int adapter_init(struct command_context *cmd_ctx)
}
int retval;
+ jtag = jtag_interface;
retval = jtag_interface-init();
if (retval != ERROR_OK)
{
return retval;
}
- jtag = jtag_interface;
/* LEGACY SUPPORT ... adapter drivers must declare what
* transports they allow. Until they all do so, assume
--
1.6.4.4
We do not have any TI OMAP 4430 in our lab, but your note is interesting since
Amontec Team is working on making the the ft2232 interface more robust,
( see last message of Sebastien).
The main problem is ft2232.c using a jtag_get_speed fn at the init stage ...
I was with the opinion to set a default frequency when initializing any jtag
adapter (long discussion somewhere last months), instead to call a upper jtag
layer fn as with jtag_get_speed (the big spaghetti). For the story.
But in an other way, as you use TI OMAP 4430 supporting JTAG RTCK feature, you
should try with an Amontec JTAGkey-2 supporting JTAG RTCK feature.
The main advantage to use a JTAG RTCK for Cortex-Ax is to have the JTAGkey-2 synchronized with the TI OMAP X frequency - you do not need to be worry about the JTAG frequency, since the OMAP will give the tempo via the RTCK :-)
If you already have a Amontec JTAGkey, evaluate the Amontec JTAGkey-2 OEM
(coming without the cable, but at low cost )
---
Your patch is OK for me !
Regards,
Laurent
http://www.amontec.com/
Amontec JTAGkey-2 : High speed USB JTAG interface
http://www.amontec.com/jtagkey.shtml
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour
I'm not looking for something that works in all circumstances. I just want it to be the *same* across all interfaces. The correct long term solution would be to have *no* default speed and just put up an error message if the script doesn't specify it. IMHO. For me the correct is : 1. -init- fix the adapter jtag interface to a default frequency as 100kHz. 2a. close the JTAG interface if the scripts did not surcharge the JTAG frequency, or set the new frequency wanted by the script. 2b. try to detect the maximum working frequency and continue the JTAG interface. With this, we do not need to call any JTAG_ fn (upper level) from the adapter JTAG driver (lower level). Also, this avoid tones of big spagethi and make the all more robust. Also, we could think to add the JTAG frequency when initializing the JTAG interface as JTAG_interface-init(100); / So I think having no default and forcing the user to specify a value // might be the way to go. / Agreed. If we could have that patch first and not go the detour of a fixed default across all interfaces, then that would be my choice too. The JTAG adapter do not need to know if the core.c is happy or not with the JTAG frequency coming from a script or from anywhere. The JTAG adapter just want to know what JTAG frequency to work on. Patch anyone? Regards, Laurent http://www.amontec.com/ Amontec JTAGkey-2 : High speed USB JTAG interface http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour
/ I'm not looking for something that works in all circumstances. I just // want it to be the *same* across all interfaces. // // The correct long term solution would be to have *no* default speed // and just put up an error message if the script doesn't specify it. // IMHO. /For me the correct is : 1. -init- fix the adapter jtag interface to a default frequency as 100kHz. 2a. close the JTAG interface if the scripts did not surcharge the JTAG frequency, or set the new frequency wanted by the script. 2b. try to detect the maximum working frequency and continue the JTAG interface. With this, we do not need to call any JTAG_ fn (upper level) from the adapter JTAG driver (lower level). Also, this avoid tones of big spagethi and make the all more robust. ... at the initialization of the adapters ;-) Also, we could think to add the JTAG frequency when initializing the JTAG interface as JTAG_interface-init(100); / // / So I think having no default and forcing the user to specify a value // // might be the way to go. // / // Agreed. If we could have that patch first and not go the detour of // a fixed default across all interfaces, then that would be // my choice too. /The JTAG adapter do not need to know if the core.c is happy or not with the JTAG frequency coming from a script or from anywhere. The JTAG adapter just want to know what JTAG frequency to work on. / Patch anyone? / Regards, Laurent http://www.amontec.com/ Amontec JTAGkey-2 : High speed USB JTAG interface http://www.amontec.com/jtagkey.shtml Regards, Laurent http://www.amontec.com/ Amontec JTAGkey-2 : High speed USB JTAG interface http://www.amontec.com/jtagkey.shtml ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix: Correctly exit function: ft2232_init when an error occurred
A tip that might be applicable: break the patch apart in multiple patches. The first patch would rearrange the code, but essentially leave the entire execution and behavior unchanged(bugs included). The Sebastien's patch is already very small and is the 'rearrange the code' part. There are no need to make it smaller and multiply the patches. This patch leaves the entire execution and behavior unchanged. The second patch would fix the problem. One or two other patches will come for providing the close of the ft2232 dongle more robust. Your chances of having the code reviewed will be much higher as it will be less effort and clearer what you really are changing. Are you serious ? Did you read the patch ? I think it is really SIMPLE to see what are changing by reading the patch, without any kind of effort ? Give precise comments or merge. Regards, Laurent http://www.amontec.com Amontec JTAGkey-2 : High-Speed USB JTAG cable interface ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix: Correctly exit function: ft2232_init when an error occurred
Øyvind Harboe wrote: Did you read the patch ? No. I'll leave it to others to work on the ft2232 driver. So if you did not read the patch, why did you comment it ! I'm just trying to give him some general advice on how to best solicit the review / help from others on the list as he was concerned about why he didn't see any yet. You already gave him this kind of advice ... when we were on core.c patch ... I want to see a review of this change to ft2232 by someone who spends time on this driver before I commit it. The ft2232 is used by a lot users out there, so more speed and less haste is good here. Perhaps the patch is fine as is and someone will review it. And what if nobody else review/comment it ? Tip: you'll catch more bees with a drop of honey, than a gallon of bile. woow ! Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] To correctly close the JTAG adapter handle in any cases
Sounds like an awfully complicated solution to what's going on all the time in terms of a cleanup problem. Right, this is not the IDEAL solution. But openocd mechanism concerning jtag adapter init and jtag adapter init/quit is not IDEAL too ! The better case for jtag adapter would be to have .open .init .xxx-interface-me-xxx .deinit .close .open and .close the handle of the jtag adapter .init and deinit the jtag adapter itself. But the actual openocd only knows the .init and .quit, and we have to do with. If we go with .open .init .deinit .close, it will make a lot of more work on all the specific jtag driver. - could be modified on a second step ... THE REAL PROBLEM : -- During the actual .init we open the handle of the jtag adapter and we init the jtag adapter (in the specific jtag adapter driver). The problem is the actual .init only know FAILED if the open and/or the init failed. The solution of Sebastien is GREAT since it allows upper layer to know 1. if the .init failed because there are not handle to open 2. or if the handle was open and the init of the jtag adapter fail itself ... by just adding a new code error. After knowing this information, we can close correctly the jtag interface by 1. bypassing .quit (no handle to close) 2.quit (deinit and close the handle) As Sebastien's patch works only on the code error, there are no impact on other JTAG adapter drivers. But each developer can use this mechanism to make the quit of their JTAG adapter more robust. Perhaps we should stop relying so much on the jtag global pointer? Could you point out in source code a bit more where the problem is? See the Sebastien's reply. Thanks. Laurent http://www.amontec.com Amotnec JTAGkey-2 : High-Speed USB JTAG cable interface -- Øyvind Harboe Can Zylin Consulting help on your project ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] To correctly close the JTAG adapter handle in any cases
Øyvind Harboe wrote: On Wed, Apr 13, 2011 at 2:57 PM, Laurent Gauch laurent.ga...@amontec.com wrote: If someone else on the list looks at your patch and thinks it is a good solution to the problem then that would help too. Yes, this is a good solution. So, you can merge it. I'll wait for more feedback or time to look at this more closely for now. I'd rather do this correctly and cleanly than prematurely. Ok wait until the end of the week for some feedbacks. But as this is specific to how we close openocd I think we will have few feedbacks :-) We will see how many feedback we get ... This patch is essential to deinit and close the jtag adapter correctly. Users will see immediate results when the adapter stays connected to the host running openocd and when they connect /disconnect a new target to the JTAG adapter and start a new openocd session ... (ex.: this will remove some really old troubles when connecting and disconnecting a TI ARM CORTEX OMAP with the TRST attached ...) This patch will allow better openocd 'inter-sessions' ... Laurent http://www.amontec.com Laurent http://www.amontec.com Amontec JTAGkey-2 : High-Speed USB JTAG cable interface 1.3V to 5.5V with RTCK ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] compiling from openocd root dir
The immediate work-around: remove the ; from your configure file at line 14208 - 14245 - 14315 - 14348 - 14698 - 14726 or the like! Laurent http://www.amontec.com Rodrigo Rosa wrote: o cloned from git, and then i ran these commands: ./bootstrap ./configure --enable-mantainer-mode --enable-ft2232-libftdi --disable-werror make and i get the error i mentioned. i'm disabling werror because i'm still cleaning the code, there's unused stuff floating around. -- Rodrigo. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] compiling from openocd root dir
https://lists.berlios.de/pipermail/openocd-development/2011-April/018646.html Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] field.in_value = NULL - general question
/ drasko.draskovic at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
// Hi all,
// I have one general question regarding OpenOCD scans.
//
// What happens when we set some field.in_value = NULL, and in reality
// there are some bits that re shifted out on the scan chain ? Are they
// just ignored ? Does that pose the problem ?
//
// This tells the JTAG drivers to throw away the bits that are clocked in
// (read from the TAP). The target hardware/TAP does not see a difference.
//
// To give a concrete example, in the mips_ejtag.c we have something like :
//
///* fastdata 1-bit register */
//fields[0].num_bits = 1;
//fields[0].out_value = spracc;
//fields[0].in_value = NULL;
//
///* processor access data register 32 bit */
//fields[1].num_bits = 32;
//fields[1].out_value = t;
//
//if (write_t)
//{
//fields[1].in_value = NULL;
//buf_set_u32(t, 0, 32, *data);
//}
//else
//{
//fields[1].in_value = (uint8_t *) data;
//}
//
// So, no values are received (because fields[0].in_value = NULL and
// fields[1].in_value = NULL), but in reality MIPS EJTAG shifts out 33
// bits (one SPrAcc and 32 bits of DATA) upon this operation.
//
// My question is, in general, could not accepting these bits lead to
// some problems or collisions on data lines (or USB bus) ?
//
// The bits are simply ignored rather than stored in memory. The
// protocol or target hardware is not affected as such.
/
Thanks Øyvind,
this is what I thougth...
Is there a special reason why not ignoring one bit, like :
fields[0].in_value = spracc_in instead fields[0].in_value = NULL in
previos example gives :
downloaded 361540 bytes in 182.220215s (1.938 KiB/s) in the place of
previous downloaded 361540 bytes in 182.220215s (1.938 KiB/s) when
fields[0].in_value was ignored (NULL) ?
both 361540 bytes in 182.220215s ??? please correct.
If you do not need to read TDO please use fields[0].in_value = NULL , ever !
If you use fields[0].in_value = spracc_in instead fields[0].in_value = NULL, the communication USB to Amontec JTAGkey dongles could
be slower, because the TDO must be returned back to host computer, and more USB access will be generated.
Laurent Gauch
http://www.amontec.com
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 : Hi-Speed USB JTAG Cable
BTW. I use Amontec D2XX because otherwise libftdi dies when I change
from fields[0].in_value = NULL to fields[0].in_value = spracc.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] field.in_value = NULL - general question
Drasko DRASKOVIC wrote:
On Thu, Apr 7, 2011 at 1:09 PM, Laurent Gauch laurent.ga...@amontec.com wrote:
/ drasko.draskovic at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
// Hi all,
// I have one general question regarding OpenOCD scans.
//
// What happens when we set some field.in_value = NULL, and in reality
// there are some bits that re shifted out on the scan chain ? Are they
// just ignored ? Does that pose the problem ?
//
// This tells the JTAG drivers to throw away the bits that are clocked in
// (read from the TAP). The target hardware/TAP does not see a
difference.
//
// To give a concrete example, in the mips_ejtag.c we have something
like :
//
///* fastdata 1-bit register */
//fields[0].num_bits = 1;
//fields[0].out_value = spracc;
//fields[0].in_value = NULL;
//
///* processor access data register 32 bit */
//fields[1].num_bits = 32;
//fields[1].out_value = t;
//
//if (write_t)
//{
//fields[1].in_value = NULL;
//buf_set_u32(t, 0, 32, *data);
//}
//else
//{
//fields[1].in_value = (uint8_t *) data;
//}
//
// So, no values are received (because fields[0].in_value = NULL and
// fields[1].in_value = NULL), but in reality MIPS EJTAG shifts out 33
// bits (one SPrAcc and 32 bits of DATA) upon this operation.
//
// My question is, in general, could not accepting these bits lead to
// some problems or collisions on data lines (or USB bus) ?
//
// The bits are simply ignored rather than stored in memory. The
// protocol or target hardware is not affected as such.
/
Thanks Øyvind,
this is what I thougth...
Is there a special reason why not ignoring one bit, like :
fields[0].in_value = spracc_in instead fields[0].in_value = NULL in
previos example gives :
downloaded 361540 bytes in 182.220215s (1.938 KiB/s) in the place of
previous downloaded 361540 bytes in 182.220215s (1.938 KiB/s) when
fields[0].in_value was ignored (NULL) ?
both 361540 bytes in 182.220215s ??? please correct.
Whoops, sorry...
Without reading in SPrAcc bit (fields[0].in_value = NULL) I can obtain
up to : 182.220215s (1.938 KiB/s).
However, when I read it in (fields[0].in_value = spracc_in) I get :
downloaded 361540 bytes in 12.489729s (28.269 KiB/s)
without reading 182s, you sure ???
Note that jtag_execute_queue() is called in both cases.
And the same number of time ?
Not calling jtag_execute_queue() (which also implies ignoring the
SPrAcc bit) get us bigger throughput (but this is expected and no
surprise :
downloaded 361540 bytes in 4.989900s (70.756 KiB/s)
So, as you see, my main interest is the difference between 12.489729s
when in_value ignored and 182.220215s when it is clocked in memory.
This difference is way too big.
Now it is ok.
While jtag_execute_queue() latency can not be avoided if we want to do
the status check on the shifted-out bit, this additional latency just
to write shifted-out bit in memory is really suprising for me...
If you do not need to read TDO please use fields[0].in_value = NULL , ever !
Yes, off course. It can prevent segfaults, unless you correctly
allocated placeholder in the moment of queue execution. I just tried
here to do the tests. BTW. SPrAcc bit should be read, if we want
robust implementation.
If you use fields[0].in_value = spracc_in instead fields[0].in_value =
NULL, the communication USB to Amontec JTAGkey dongles could be slower,
because the TDO must be returned back to host computer, and more USB access
will be generated.
Difference is pretty big - 12s versus 182s. Is this normal and expected ?
Right, 15x slower is really surprising - I would say 3x to 5x could be
understandable .
Regards,
Laurent
http://www.amontec.com
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Actual configure file corrupted
Last GIT has configure file corrupted. ; at line 14208 - 14245 - 14315 - 14348 - 14698 - 14726 do you need patch ? Regards, Laurent http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 : low-cost High-Speed USB JTAG cable interface ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ULINK driver: firmware license questions
/ The EZ-USB gives access to USB but not to the ULINK interface. Right ? / The ULINK consists of the EZ-USB microcontroller, an SRAM, an EEPROM and level shifters. There's even a schematic floating around the net: http://www.mikrocontroller.net/attachment/51828/ULink.pdf Keil is just using the digital I/O of the EZ-USB to read/write the JTAG signals, quite simple actually. On Wed, 2011-04-06 at 18:58 +0200, Michael Schwingen wrote: / BUT the PROBLEM is to support ULINK interface protocol in OpenOCD, // since the ULINK protocol specification is not public, but copyrighted // by KEIL Inc.. // // He wrote that he has written his own firmware, so that would probably // use a different protocol but just run on the ULINK hardware - that would // be perfectly acceptable. / Exactly. I have designed my own protocol and implemented it in my custom firmware. I've also written a demo program in C++ that can erase/program flash, read/write fuses, ... in various Atmel AVR (8-bit) devices with my ULINK firmware. So, ULINK hardware is only used as board platform :-) So, you have your own protocol. I hope you have your own USB VID/PID too. Finally, if you include your own protocol driver in openocd, please do not call it ULINK. Since it is not ULINK protocol. This will avoid tones of confuses for other users !!! / However, if his own firmware needs to be linked against a proprietary // (which we must assume, since no license is given) library, the resulting // firmware binary can not be included in/with OpenOCD. / Currently, this is the case. I'll look into alternatives. / However, if the ULINK is basically an EZ-USB chip which downloads its // code via USB, using the ULINK protocol would also mean we would have to // use Keil's firmware, as it needs to be downloaded every time the ULINK // adapter is powered on. / Upon power-up, the blank EZ-USB chip registers itself with a VID/PID it reads from the EEPROM on the ULINK board. Then, it can at any time be loaded with the firmware program via standard USB control requests, so at no point in time Keil's ULINK protocol needs to be used. Nice idea. I understand yet. Laurent Gauch http://www.amontec.com On Wed, 2011-04-06 at 18:23 +0200, Øyvind Harboe wrote: / If you want the community to accept your patch, then not only // do you need to pass all the GPL hurdles, but the community // must be comfortable maintaining your patches and you'll probably // have to do all the work and then some. / That is what I'm trying to achieve :) Best regards, Martin ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Actual configure file corrupted
On Thu, Apr 7, 2011 at 5:19 PM, Peter Stuge peter at stuge.se https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Laurent Gauch wrote: // Last GIT has configure file corrupted. // ; at line 14208 - 14245 - 14315 - 14348 - 14698 - 14726 // // do you need patch ? // // If you send a patch you are contributing more efficiently. You never // have to ask if a change should be sent as a patch, just send the // patch directly. :) // // If you expect someone else to create the patch for you, then you may // of course be severely disappointed, if noone has the time or noone // cares about the change as much as you do. // // If you send a patch yourself you increase the chances that the change // is included sooner. // // // //Peter / I did not look, but I had an impression from e-mail that Laurent thought that the file needs revert (being correct in previous revisions). If correct version is already versioned no need for the patch, simple revert would do. BR, Drasko Exactly Drasko, We cannot patch this file, since the 'configure' is generated at compilation :-)! But I actually do not find the source of the error ! Maybe something wrong with the last Spencer's patch https://lists.berlios.de/pipermail/openocd-development/2011-April/018609.html Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] in GDB, FT2232D can work at TCK 6MHz, but FT2232H can only work at 3MHz
The target board is s3c2440. the log is: (gdb) monitor jtag_khz 3000 3000 kHz (gdb) load u-boot Loading section .text, size 0x2044c lma 0x33f8 Loading section .rodata, size 0x1d54 lma 0x33fa044c Loading section .rodata.str1.4, size 0x7cb7 lma 0x33fa21a0 Loading section .data, size 0x1558 lma 0x33fa9e58 Loading section .got.plt, size 0xc lma 0x33fab3b0 Loading section .got, size 0x4 lma 0x33fab3bc Loading section .u_boot_cmd, size 0x4c8 lma 0x33fab3c0 Start address 0x33f8, load size 178311 Transfer rate: 81 KB/sec, 11144 bytes/write. (gdb) monitor jtag_khz 6000 6000 kHz (gdb) load u-boot Loading section .text, size 0x2044c lma 0x33f8 Load failed (gdb) the log of openocd is: 3000 kHz 6000 kHz Warn : Bad value '0004' captured during DR or IR scan: Warn : check_value: 0x0009 Warn : check_mask: 0x0009 Error: JTAG error while reading cpsr openocd is 0.4 Please send me your configuration files at laurent.gauch-AT-amontec.com. I am currious to see it. Our Amontec JTAGkey is base ft2232d and our Amontec JTAGkey-2 is based on ft2232h. Both JTAGkey and JTAGkey-2 works at 6MHz and the JTAGkey-2 can up to 30MHz. The end maximum frequency of your JTAG chain is not only depending of the ft2232 type, but is depending on the type de layout and buffer used. The Amontec JTAGkey-2 have ultra-high-speed buffers with large output current as 32mA. Having a strong output driver current help a lot to reach high frequency on the JTAG Chain. Regards, Laurent http://www.amntec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] in GDB, FT2232D can work at TCK 6MHz, but FT2232H can only work at 3MHz
Hi Andy, Thank you. Have a nice day. Regards, Laurent http://www.amontec.com Andrew Lyon wrote: Hey Laurent, The url in your sig is wrong, just thought I'd let u know. Andy On 06/04/2011, Laurent Gauch laurent.ga...@amontec.com wrote: The target board is s3c2440. the log is: (gdb) monitor jtag_khz 3000 3000 kHz (gdb) load u-boot Loading section .text, size 0x2044c lma 0x33f8 Loading section .rodata, size 0x1d54 lma 0x33fa044c Loading section .rodata.str1.4, size 0x7cb7 lma 0x33fa21a0 Loading section .data, size 0x1558 lma 0x33fa9e58 Loading section .got.plt, size 0xc lma 0x33fab3b0 Loading section .got, size 0x4 lma 0x33fab3bc Loading section .u_boot_cmd, size 0x4c8 lma 0x33fab3c0 Start address 0x33f8, load size 178311 Transfer rate: 81 KB/sec, 11144 bytes/write. (gdb) monitor jtag_khz 6000 6000 kHz (gdb) load u-boot Loading section .text, size 0x2044c lma 0x33f8 Load failed (gdb) the log of openocd is: 3000 kHz 6000 kHz Warn : Bad value '0004' captured during DR or IR scan: Warn : check_value: 0x0009 Warn : check_mask: 0x0009 Error: JTAG error while reading cpsr openocd is 0.4 Please send me your configuration files at laurent.gauch-AT-amontec.com. I am currious to see it. Our Amontec JTAGkey is base ft2232d and our Amontec JTAGkey-2 is based on ft2232h. Both JTAGkey and JTAGkey-2 works at 6MHz and the JTAGkey-2 can up to 30MHz. The end maximum frequency of your JTAG chain is not only depending of the ft2232 type, but is depending on the type de layout and buffer used. The Amontec JTAGkey-2 have ultra-high-speed buffers with large output current as 32mA. Having a strong output driver current help a lot to reach high frequency on the JTAG Chain. Regards, Laurent http://www.amntec.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
Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)
Drasko DRASKOVIC wrote: Hi all, based on EJTAG spec, can somebody explain the difference between FASTDATA competition and not competition modes : During a Fastdata access, the Fastdata register value shifted in specifies whether the Fastdata access should be completed or not. The value shifted out is a flag that indicates whether the Fastdata access was successful or not (if completion was requested). Shifting in a zero value requests completion of the Fastdata access. The PrAcc bit in the EJTAG Control register is overwritten with zero when the access succeeds. (The access succeeds if PrAcc is one and the operation address is in the legal dmseg segment Fastdata area.) When successful, a one is shifted out. Shifting out a zero indicates a Fastdata access failure. Shifting in a one does not complete the Fastdata access and the PrAcc bit is unchanged. Shifting out a one indicates that the access would have been successful if allowed to complete and a zero indicates the access would not have successfully completed. So my questions are : 1) If we demand completion, when do we do shift-out of the SPrAcc bit to check status : First, you have to be sure to be in FASTDATA MODE (set the MODE in the TAP instruction REGISTER) see Table 6-1 TAP Instruction Overview Second, do not confuse PrAcc CONTROL register bit and sPrAcc FLAG added in the shift registers In FASTDATA mode: --- For a processor MIPS 32-bits DATA register becomes 33bits in FASTDATA mode. from EJTAG spec., see Figure 6-6 TDI to TDO Path when in Shift-DR State and FASTDATA Instruction is Selected The LSB (bit 32) is your sPRAcc. Are you sure you are shiffting in and shifting out 33bits and not 32bits before coming back to the IDLE TAP STATE ? a) We shift in SPrAcc, we shift it out, we check it if it is 1 - that would say You can send in data it will pass OK, and then we shift in data or see Table 6-11 Fastdata Register Field Description Every thing is here 1.make sure to shift-in 1 in SPrAcc 2. check the shit-out of SPrAcc - must be one 3. check the PrAcc CONTROL regsiter - must be one if SPrAcc shifted-out value is one and PrAcc is one then the FASTDATA acccess succeeds else failure For me that's all ! b) We shift in SPrAcc, we shift in data, we shift out SPrAcc and check if if it is 1 - in this case check comes after data shift-in and it would say something like Data shifted in were well written ? Based on this : During Fastdata uploads and downloads, the processor will stall on accesses to the Fastdata area. The PrAcc (processor access pending bit) will be 1 indicating the probe is required to complete the access. Both upload and download accesses are attempted by shifting in a zero SPrAcc value (to request access completion) and shifting out SPrAcc to see if the attempt will be successful (i.e., there was an access pending and a legal Fastdata area address was used). Downloads will also shift in the data to be used to satisfy the load from the dmseg segment Fastdata area, while uploads will shift out the data being stored to the dmseg segment Fastdata area. I would say that it is case b) - pre-check SPrAcc and then shift-in data... But I am not sure. I do not know at which point to check. No sense, since your SPrAcc is in the shift regsiter itself ! For me, you are misunderstanding the SPrAcc flag and PrAcc bit. Hoping to help. Regards, Laurent Gauch http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec USB JTAG Cable solutions Amontec JTAGkey Amontec JTAGkey-2 Amontec JTAGkey-2P BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)
Drasko DRASKOVIC wrote: On Wed, Apr 6, 2011 at 3:04 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: 1.make sure to shift-in 1 in SPrAcc Yes, this is done. 2. check the shit-out of SPrAcc - must be one Whe to check - before of after shifting in data ? 3. check the PrAcc CONTROL regsiter - must be one Yes, this is done in mips32_pracc.c, before calling mips_ejtag_fastdata_scan() (refer to attached patch) if SPrAcc shifted-out value is one and PrAcc is one then the FASTDATA acccess succeeds else failure Just one important point to clarify over here, do we : 1) first check PrAcc in CONTROL reg *before* initiating FASTDATA acc (like I implemented), or do we 2) try FASTDATA transfer without first checking PrAcc in CONTROL reg, then check shifted-ot SPrAcc, and then in the end check PrAcc in CONTROL, like you suggested ? Basically, do we check PrAcc in CONTROL reg before or after FASTDATA transaction ? BR, Drasko Before. Reading Figure 6-16 Write Processor Access Example, the PrACC must be checked first. Regards, Laurent Gauch http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec USB JTAG Cable solutions Amontec JTAGkey Amontec JTAGkey-2 Amontec JTAGkey-2P ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)
Drasko DRASKOVIC wrote: In a SPrAcc vs PrAcc debate, one thing accured to me : can it be that SPrAcc is actualy shifted-out value of PrAcc from CONTROL register (i.e. same internaly hard-wired value). Is this mechanism maybe provided by MIPS to easily and fast check PrAcc value during FASTDATA access - i.e. checking chifted out SPrAcc is sufficient (because it is exactly the same thing that is in PrAcc) ? Specification is the mess... BR, Drasko Yes, there are some mechanism between SPrAcc and PrACC. But, not internaly hard-wired value from Table 6-11 Fastdata Register Field Description Shifting in a zero value requests completion of the Fastdata access. The PrAcc bit in the EJTAG Control register is overwritten with zero when the access succeeds. (The access succeeds if PrAcc is one and the operation address is in the legal dmseg segment Fastdata area.) When successful, a one is shifted out. Shifting out a zero indicates a Fastdata access failure. Shifting in a one does not complete the Fastdata access and the PrAcc bit is unchanged. Shifting out a one indicates that the access would have been successful if allowed to complete and a zero indicates the access would not have successfully completed. Regards, Laurent Gauch http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec USB JTAG Cable solutions Amontec JTAGkey Amontec JTAGkey-2 Amontec JTAGkey-2P ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ULINK driver: firmware license questions
Hi! I'm currently working on a driver for the Keil ULINK adapter. I have developed a custom firmware for the ULINK's Cypress EZ-USB microcontroller during the last six months and recently began implementing the OpenOCD driver. Of course, I'd like to contribute both the driver and the custom firmware to OpenOCD. The firmware currently needs to be linked to the EZ-USB library available here: http://www.danielclemente.com/placa_pi/index.en.html#toc11 The library source code is a modified version of the original source from Keil, which does not contain any license information. Can these files be included in the OpenOCD repository or will I have to find a replacement that is compatible with the GPL license? Best regards, Martin For the EZ-USB library it should not be a problem. The EZ-USB gives access to USB but not to the ULINK interface. Right ? BUT the PROBLEM is to support ULINK interface protocol in OpenOCD, since the ULINK protocol specification is not public, but copyrighted by KEIL Inc.. I think we will never be able to include ULINK interface in OpenOCD. Sorry. First you have to call Keil and to ask about to publish their ULINK protocol. After what we may integrate the ULINK in OPEN SOURCE PROJECT as openocd. See http://embdev.net/topic/129290 from an other Martin. Regards, Laurent Gauch http://www.amontec.com http://www.amontec.com/jtagkey.shtml Amontec High-Speed USB JTAG Cable solutions Amontec JTAGkey JTAGkey-2 JTAGkey-2P ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)
On Mon, Apr 4, 2011 at 7:51 PM, Øyvind Harboe oyvind.harboe at zylin.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Any objections to merging 1,2 and 4? // // I think #3 needs more discussion or cool-off. My objection is // that we don't know why this makes things better and it certainly // seems to hit performance hard. / OK, I will open the discussion by question : when do we use jtag_execute_queue() ? Based on the answer from Øyvind I had before, I could conclude that it serves to clock the data back in, while jtag_add_dr_scan() just puts them in the queue to be shifted out at some point. jtag_add_xxx function will add new commands in the command queue. Note, the command queue could be auto-executed, depending on the mechanism/ressource of the JTAG adapter. The jtag_execute_queue function force the execution of the command queue, and process the response data coming back from the JTAG adapter. Before comparing a TDO vector, you MUST do a jtag_execute_queue. So, if this is correct, then we can avoid using jtag_execute_queue() when we have no data to shift in. But what happens when the TAP will send us bit as a response to FASTDATA, and we are completely ingnoting it ? Will it lead to some collision on the data bus and make ftdi freak out ? The JTAG layer only scan in and scan out the shift registers, and control the TAP FSM. The TAP will only return data if you do a scan . Here is EJTAG spec on FASTDATA : Both upload and download accesses are attempted by shifting in a zero SPrAcc value (to request access completion) and shifting out SPrAcc to see if the attempt will be successful (i.e., there was an access pending and a legal Fastdata area address was used). Actually, two solutions : a) checking the SPrAcc 1.send command to shift in zero to SPrAcc (jtag_add_scan) 2.send command to shift out SPrAcc (jtag_add_scan) 3.execute (jtag_execute) 4.compare SPrAcc returned value 5. if SprAcc not 0 goto 2. 6. send command to shift in your DATA - goto to 1. b) unchecking the SPrAcc, but adding specific delay 1.send command to shift in zero to SPrAcc (jtag_add_scan) 2.wait for x delay allowing your specific hardware to accept SPrAcc 3.send command to shift in your DATA - goto to 1. Note: b)2. the wait could be done by soft, or adding delay in the command queue or ... A) will be the most secure B) could be very fast, but should be avoid for generic implementation (not safe) Laurent http://www.amontec.com Amontec JTAGkey-2 from 1.5V to 5V auto-sense USB JTAG interface Where do we shift out SPrAcc after the R/W operation (error check) ? I would say nowhere. Can this lead to errors, and can this be an explanation why jtag_execute_queue() is necessary ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)
Drasko DRASKOVIC wrote: On Tue, Apr 5, 2011 at 9:01 AM, Laurent Gauch laurent.ga...@amontec.com wrote: On Mon, Apr 4, 2011 at 7:51 PM, Øyvind Harboe oyvind.harboe at zylin.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Any objections to merging 1,2 and 4? // // I think #3 needs more discussion or cool-off. My objection is // that we don't know why this makes things better and it certainly // seems to hit performance hard. / OK, I will open the discussion by question : when do we use jtag_execute_queue() ? Based on the answer from Øyvind I had before, I could conclude that it serves to clock the data back in, while jtag_add_dr_scan() just puts them in the queue to be shifted out at some point. jtag_add_xxx function will add new commands in the command queue. Note, the command queue could be auto-executed, depending on the mechanism/ressource of the JTAG adapter. The jtag_execute_queue function force the execution of the command queue, and process the response data coming back from the JTAG adapter. Before comparing a TDO vector, you MUST do a jtag_execute_queue. So, if this is correct, then we can avoid using jtag_execute_queue() when we have no data to shift in. But what happens when the TAP will send us bit as a response to FASTDATA, and we are completely ingnoting it ? Will it lead to some collision on the data bus and make ftdi freak out ? The JTAG layer only scan in and scan out the shift registers, and control the TAP FSM. The TAP will only return data if you do a scan . Here is EJTAG spec on FASTDATA : Both upload and download accesses are attempted by shifting in a zero SPrAcc value (to request access completion) and shifting out SPrAcc to see if the attempt will be successful (i.e., there was an access pending and a legal Fastdata area address was used). Actually, two solutions : a) checking the SPrAcc 1.send command to shift in zero to SPrAcc (jtag_add_scan) 2.send command to shift out SPrAcc (jtag_add_scan) 3.execute (jtag_execute) 4.compare SPrAcc returned value 5. if SprAcc not 0 goto 2. 6. send command to shift in your DATA - goto to 1. b) unchecking the SPrAcc, but adding specific delay 1.send command to shift in zero to SPrAcc (jtag_add_scan) 2.wait for x delay allowing your specific hardware to accept SPrAcc 3.send command to shift in your DATA - goto to 1. Note: b)2. the wait could be done by soft, or adding delay in the command queue or ... A) will be the most secure B) could be very fast, but should be avoid for generic implementation (not safe) Hi Laurent, this sounds very interesting, and I'd say that in current mips_ejtag_fastdata_scan() implementation we are doing something similar to B), but not quite - we never add the delay. However, this delay is undefined, and might come because of architecture of some dongles, so we may have situation that somewhere it works, and somewhere it does not, right ? The jtag_execute_queue maybe generate enough delay in some case. But not safe, since in the case of USB JTAGkey the latency delay added is 1ms, and in the case of USB JTAGkey-2 the latency delay added is 125us ... It is much better to work on stable TAP state and generate some CLK periods. Can you please paste here to versions of mips_ejtag_fastdata_scan(), A) (with shifting out SPrAcc) and B) (with added delay) as you described them, so I can try them both and test the results. Not so many time today, but I would try to out something before the end of the week. I would change the code by myself but for A) I do not know - should we use separate field, or SPrAcc can be return in the same field when sent, like this : /* fastdata 1-bit register */ fields[0].num_bits = 1; fields[0].out_value = spracc; fields[0].in_value = r; But this does not work. I have to see again MIPS TAP,. Are you sure about the fields[0].num_bits = 1; Does the register not longer, and need to check one bit ??? And for B) I do not know which function we can use for delay ? Maybe jtag_add_clocks() ? The best thing would be here if you can paste these two variants, and I will integrate them, test them and report the results. Best regards, Drasko Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: mourning the loss of David Brownell
Amontec Team thoughts are with David's family. We had a lot of great technical support with David. Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Set of MIPS patches (big endian, FASTDATA, error propagation, optimizations...)
Well done. Regards, Laurent Gauch http://www.amontec.com Drasko DRASKOVIC wrote: Hi all, here is a set of patched (separeted by the logical changes they introduce) that : 1) Correct endianess for big endian targets 2) Correct while(1) loop waiting for PrAcc to be 1 3) Change FASTDATA operation, forcing the shift out to prevent ft2232 buffer size reached errors 4) Add optimizations similar to ones introduced by Øyvind recently With these patches I was able to obtain decent performances and correct functioning for my big endian MIPS-M14Kc based target. I see no more problems with libftdi of type : Error: couldn't read enough bytes from FT2232 device (0 5) Current stable version of libftdi can be used, no need for closed D2XX files nor for development branches of libusb-1.0 I also have no more problems with GDB synchronisation - ELF can be correctly downloaded and executed from GDB. Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD does not call .quit when error was notified ...
The openocd server does NOT close the handles after an error was detected. (ft2232 handle) This makes the future session of openocd not working, or returning other message like error: couldn't read enough bytes from FT2232 device (0 xxx) :-( Also, this kind of message is close to the one detected by *Drasko on MIPS target.* Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 jtag mips performance
Hi Drasko, Hi Andy, thank you for these tests, it is very helpful. The problem you have can be easily solved by applying David Claffey's patches. I see that mips32_pracc_fastdata_xfer() works well for you - I'll take a look why it does not work for me and elaborate on the list. Also, I can see that you are not facing the problem which I have : Error: couldn't read enough bytes from FT2232 device (0 5) Error: couldn't read from FT2232 Error: register read failed Since Laurent from Amontec is capable of reproducing the same problem, it might be something related to Amontec dongle I am using, but there is small chance. I did not reproduce your trouble, but we already see couldn't read enough bytes from FT2232 device , when we started with the JTAGkey-2 (FT2232H), but is was coming from a too old driver, bugged with the FT2232H part. But this should not be your trouble, since you work with updated drivers. Also, the JTAGkey-2 is not your trouble since everything else is stable for you (other target board ... jtag chain detection ...), and since you do not use RTCK ... Question: -- Do you run openocd on 64bits or 32bits host machine ? ( Amontec Team is seeing some troubles with 64bits host machine running openocd this week , STM32 flash error and others errors. Regards, Laurent http://www.amontec.com Which dongle are you using ? Best regards, Drasko On Fri, Mar 25, 2011 at 11:52 AM, Andrew Lyon andrew.lyon at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / On Thu, Mar 24, 2011 at 11:01 AM, Drasko DRASKOVIC // drasko.draskovic at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // Hi Andy, // I am very surprised that OpenOCD works for big endian MIPS. // // I am currently working on this and I am preparing the patch that will // fix some of the issues. // // What I currently observed is : // // 1) mips_m4k_write_memory() and mips_m4k_read_memory() do not handle // endianess at all. Since these functions are used by mww and mdw // commands to set up SDRAM controller, most probably your configuration // is wrong. Can you check this by reading SDRAM controller configuration // registers and comparing to that configuration you expect ? I'd be very // suprised that it works. // // 2) Only mips_m4k_bulk_write_memory() handles endianess, but it is // called on 128 byes blocks (becaus it uses FASTDATA, and size of // FASTDATA area is 16 words). Bottom line is that by my observation // confirmed that mips32_pracc_fastdata_xfer() called internaly does not // work either, and I do not think that it works for little endian // targets also, missing some FASTDATA instructions. So, it would be very // important if you can answer us the question I asked in the first mail // : is mips32_pracc_fastdata_xfer() function called, and does it // succeeds, or it falls back to simple mips_m4k_write_memory() ? I would // expect to fail and fallback to mips_m4k_write_memory(), which as I // explaind, do not handle endianess at all. // // So please send us the report on following 3 things : // 1) Is SDRAM configured OK (i.e. does mww commands work well for you) // // Hi Drasko, // // You are absolutely right there are endianness issues with mips // bigendian, on the board I am using the memory controller is already // configured by the onboard firmware but reading back the values I can // see they are bitswapped: // // mdw 0xbf8011d0 1 // 0xbf8011d0: 932d // Correct Value: 0xbf8011d0 0x2D93 // // mdw 0xbf8011e0 1 // 0xbf8011e0: 3582 // Correct Value: 0xbf8011e0 0x8235 // // 2) Is mips32_pracc_fastdata_xfer() exiting with error // // No, I checked the debug logs and it works successfully: // // Debug: 219 25550 target.c:1251 target_write_buffer(): writing buffer // of 57344 byte at 0x8600 // Debug: 220 25550 mips_m4k.c:984 mips_m4k_bulk_write_memory(): address: // 0x8600, count: 0x3800 // Debug: 221 25551 target.c:1072 target_alloc_working_area(): MMU // disabled, using physical address for working memory 0xa060 // Debug: 222 25551 target.c:1134 target_alloc_working_area(): allocated // new working area at address 0xa060 // Debug: 228 28508 mips32_pracc.c:971 mips32_pracc_fastdata_xfer(): // mips32_pracc_fastdata_xfer using 0xa060 for write handler // // Debug: 230 28711 ft2232.c:1685 ft2232_execute_scan(): ft2232 buffer // size reached, sending queued commands (first_unsent: 0xb74f3008, cmd: // 0xb7411fe8) // User : 232 29125 command.c:539 command_print(): 57344 bytes written at // address 0x8600 // User : 233 29126 command.c:539 command_print(): downloaded 57344 bytes // in 3.576233s (15.659 kb/s) // // // 3) Dump the loaded image and inspect it - is it well loaded in memory ? // // I think fastdata may be loading it correctly, but reading it back it // is clearly bitswapped: // // hexdump of original file: // // 000 000b 1000 // 010 688c 688c 312e 312e
Re: [Openocd-development] MIPS and Big Endian
Drasko DRASKOVIC wrote: Hi Laurent, did you have some time to inspect this problem ? Here is what I noticed : 1) mips32_pracc_fastdata_xfer() does not work well, so FASTDATA will not work. I am very surprised that it worked for whoever commited, because there are some things that are not consistent with MIPS EJTAG Specification document. I have it working and will send patch soon. good ! 2) With this fix I am able to do FASTDATA bulk write, but the problem I had persists : Error: couldn't read enough bytes from FT2232 device (0 5) Error: couldn't read from FT2232 Error: register read failed I already get some time on this, but not found the why yet. However, this problem is not blocking, as I can load whole eCos image and run it without problem (i.e. image is well loaded in the SDRAM). I noticed that playing with the value of jtag_add_clocks(5); in mips32_pracc.c file can sometimes lead to disparation of this problem, but this function rests completely mysterious to me, as I did not saw any explanation. Really strange since the jtag_add_clocks only add bytes in the output buffer, and nothing need to be read from input buffer ... The jtag_add_clocks() is used to generate some delay. This must be used in stable state only. You understand now why jtag_add_clocks and adapter_khz are linked ! at 100ns jtag clock period : jtag_add_clocks(5) : delay = 500ns at 200ns jtag clock period : jtag_add_clocks(5) : delay = 1000ns So, does anybody have an idea why we add these extra 5 clocks and how we can fine-tune this as it seems to depend on adapter_khz option also ? Extra clocks delay could be added to make sure the processor can get new data again ... But if you change the jtag frequency, the clocks delay should be updated to. And this delay could be different on a PIC32MX or other MIPS with the same eJTAG interface... ;-) Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey-3 coming soon ! Generic USB JTAG CJTAG SWD SWO serial wire debug interface 1.5V 1.8V 2.5V 3.3V 5V auto-sense protected IOs With RTCK support maximum 30Mhz JTAG TCK frequency All I have found is this : https://lists.berlios.de/pipermail/openocd-development/2009-April/005277.html where indeed potential problems with FTDI 2232are mentioned, but I do not get it well. I hope that it will make more sense for Laurent or some other expert in this field. Best regards, Drasko On Fri, Mar 18, 2011 at 12:17 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: I have : 1) Amotnec JTAGkey-2 and 2) Amontec JTAGkey Tiny BR, Drasko On Fri, Mar 18, 2011 at 12:14 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Drasko DRASKOVIC wrote: Hello Laurent, I have trouble compiling your driver in static (I copied libe from build/i386 to stati_lib): checking whether standard drivers can be built... yes checking uninstalled ftd2xx distribution... -L/home/ddraskovic/sandbox/libftd2xx_laurent/libftd2xx1.0.4/static_lib /home/ddraskovic/sandbox/libftd2xx_laurent/libftd2xx1.0.4/static_lib/libftd2xx.a checking whether ftd2xx library works... configure: error: Cannot build run test program using ftd2xx.lib [1]22996 exit 1 ./configure --disable-werror --enable-verbose --enable-verbose-jtag-io [ddraskovic@lardos:/home/ddraskovic/sandbox/openocd-0.5.0/openocd]ls /home/ddraskovic/sandbox/libftd2xx_laurent/libftd2xx1.0.4/static_lib/libftd2xx.a /home/ddraskovic/sandbox/libftd2xx_laurent/libftd2xx1.0.4/static_lib/libftd2xx.a [ddraskovic@lardos:/home/ddraskovic/sandbox/openocd-0.5.0/openocd] When compiled shared, I run into this standard libftd2xx compiling error produced by libtool shuffling of libs order, but this can be fixed as explained here : http://albertoembedded.wordpress.com/2010/03/16/openocd-with-amontec-jtagkey2-support/ http://andrey.mikhalchuk.com/2009/06/03/solving-libopenocdso-undefined-reference-to-ft_getlatencytimer-problem-during-openocd-compilation.html Finally, when I run OpenOCD with this driver I am getting : Debug: 168 19 command.c:364 register_command_handler() 103584: registering 'ocd_reset_nag'... Debug: 169 19 ft2232.c:2433 ft2232_init() 104216: ft2232 interface using shortest path jtag state transitions Debug: 170 19 ft2232.c:2133 ft2232_init_ftd2xx() 104216: 'ft2232' interface using FTD2XX with 'jtagkey' layout (0403:cff8) Error: 171 34 ft2232.c:2239 ft2232_init_ftd2xx() 137400: unable to get latency timer: 4 Debug: 172 84 command.c:638 run_command() 137336: Command failed with error code -100 I however compiled OpenOCD with official libftd2xx0.4.16 - it compiles quite fine both static and shared (for shred there is mentioned problem in the end). When run with this driver, there are no problems with latency timer. However, problem : couldn't read enough bytes from FT2232 device (0 5) still persist. Can you point me how to override the problems with compilation with Amontec driver ? Best regards, Drasko On Thu, Mar 17, 2011 at 5:23 PM, Laurent Gauch laurent.ga
Re: [Openocd-development] MIPS and Big Endian
Drasko DRASKOVIC wrote: Hello Laurent, I have trouble compiling your driver in static (I copied libe from build/i386 to stati_lib): checking whether standard drivers can be built... yes checking uninstalled ftd2xx distribution... -L/home/ddraskovic/sandbox/libftd2xx_laurent/libftd2xx1.0.4/static_lib /home/ddraskovic/sandbox/libftd2xx_laurent/libftd2xx1.0.4/static_lib/libftd2xx.a checking whether ftd2xx library works... configure: error: Cannot build run test program using ftd2xx.lib [1]22996 exit 1 ./configure --disable-werror --enable-verbose --enable-verbose-jtag-io [ddraskovic@lardos:/home/ddraskovic/sandbox/openocd-0.5.0/openocd]ls /home/ddraskovic/sandbox/libftd2xx_laurent/libftd2xx1.0.4/static_lib/libftd2xx.a /home/ddraskovic/sandbox/libftd2xx_laurent/libftd2xx1.0.4/static_lib/libftd2xx.a [ddraskovic@lardos:/home/ddraskovic/sandbox/openocd-0.5.0/openocd] When compiled shared, I run into this standard libftd2xx compiling error produced by libtool shuffling of libs order, but this can be fixed as explained here : http://albertoembedded.wordpress.com/2010/03/16/openocd-with-amontec-jtagkey2-support/ http://andrey.mikhalchuk.com/2009/06/03/solving-libopenocdso-undefined-reference-to-ft_getlatencytimer-problem-during-openocd-compilation.html Finally, when I run OpenOCD with this driver I am getting : Debug: 168 19 command.c:364 register_command_handler() 103584: registering 'ocd_reset_nag'... Debug: 169 19 ft2232.c:2433 ft2232_init() 104216: ft2232 interface using shortest path jtag state transitions Debug: 170 19 ft2232.c:2133 ft2232_init_ftd2xx() 104216: 'ft2232' interface using FTD2XX with 'jtagkey' layout (0403:cff8) Error: 171 34 ft2232.c:2239 ft2232_init_ftd2xx() 137400: unable to get latency timer: 4 Debug: 172 84 command.c:638 run_command() 137336: Command failed with error code -100 I however compiled OpenOCD with official libftd2xx0.4.16 - it compiles quite fine both static and shared (for shred there is mentioned problem in the end). When run with this driver, there are no problems with latency timer. However, problem : couldn't read enough bytes from FT2232 device (0 5) still persist. Can you point me how to override the problems with compilation with Amontec driver ? Best regards, Drasko On Thu, Mar 17, 2011 at 5:23 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Try with d2xx Linux driver attached. Compile with d2xx support Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey-3 coming soon ! Generic USB JTAG CJTAG SWD SWO serial wire debug interface 1.5V 1.8V 2.5V 3.3V 5V auto-sense protected IOs With RTCK support maximum 30Mhz JTAG TCK frequeny Drasko DRASKOVIC wrote: On Thu, Mar 17, 2011 at 4:53 PM, Laurent Gauch laurent.ga...@amontec.com wrote: I am waiting on the log using the Amontec JTAGkey d2xx WHQL certified driver . Maybe we will see something different, in this case it is a trouble in the libftdi . If the same some trouble in the higher JTAG level in openocd source. It is only Windows driver right ? That would say that I must find now Windows machine and compile latest OpenOCD for Windows... This will take some time. BR, Drasko For the driver, I will see this afternoon. What JTAGkey dongle do you have ? Generation - 2 Amotnec JTAGkey-2 Amontec JTAGkey-2P Generation - 1 Amontec JTAGkey Amontec JTAGkey Tiny If you have a JTAGkey or JTAGkey Tiny do you get the problem : couldn't read enough bytes from FT2232 device (0 5), as with the JTAGkey-2 ? Regards, Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS and Big Endian
Hi Mathias K., You have this command buffer 4b 02 01 39 02 00 00 c0 04 3b 06 80 6b 01 81 4b 02 03 4b 02 01 / TMS shift no read 39 02 00 00 c0 04 / IN OUT 3 bytes read 3b 06 80 / IN OUT 1 byte read 6b 01 81 / TMS shift 1 byte read 4b 02 03 / TMS shift no read This command buffer should return 5 bytes data. There are no reason here the Amontec JTAGkey-2 do not send back the 5 bytes, except if you have RTCK return clock enabled !!! But a bad previous command buffer could corrupt the JTAGkey-2 ft2232 mpsse interface. Please send me the complet debug file . Also, could you please try the same with Amontec JTAGkey D22X WHQL certified driver you found at http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey-3 coming soon ! Generic USB JTAG CJTAG SWD SWO serial wire debug interface 1.5V 1.8V 2.5V 3.3V 5V auto-sense protected IOs With RTCK support wrote: Hello, the send buffer looks okay. Maybe this is a timeout problem. Do you use the d2xx or ftdi library? Regards, Mathias Am 17.03.2011 13:14, schrieb Drasko DRASKOVIC: 3174056 Debug: 3174389 188209 ft2232.c:809 ft2232_send_and_recv(): write buffer (size 18): 3174057 Debug: 3174390 188209 ft2232.c:784 ft2232_debug_dump_buffer(): 4b 02 01 39 02 00 00 c0 04 3b 06 80 6b 01 81 4b 3174058 Debug: 3174391 188209 ft2232.c:790 ft2232_debug_dump_buffer(): 02 03 3174059 Error: 3174392 192209 ft2232.c:584 ft2232_read(): couldn't read enough bytes from FT2232 device (0 5) 3174060 Error: 3174393 192209 ft2232.c:839 ft2232_send_and_recv(): couldn't read from FT2232 3174061 Error: 3174394 192209 mips_ejtag.c:115 Errors repeat later : 5759736 Debug: 5760353 334312 ft2232.c:809 ft2232_send_and_recv(): write buffer (size 27): 5759737 Debug: 5760354 334312 ft2232.c:784 ft2232_debug_dump_buffer(): 4b 03 03 1b 03 0a 4b 02 03 4b 02 01 39 02 00 00 5759738 Debug: 5760355 334312 ft2232.c:790 ft2232_debug_dump_buffer(): c0 00 3b 06 80 6b 01 81 4b 02 03 5759739 Error: 5760356 338311 ft2232.c:584 ft2232_read(): couldn't read enough bytes from FT2232 device (0 5) 5759740 Error: 5760357 338311 ft2232.c:839 ft2232_send_and_recv(): couldn't read from FT2232 5759741 Error: 5760358 338311 mips_ejtag.c:115 mips_ejtag_drscan_32(): register read failed ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS and Big Endian
On Thu, Mar 17, 2011 at 2:50 PM, Laurent Gauch laurent.gauch at amontec.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / Hi Mathias K., // // You have this command buffer // // 4b 02 01 39 02 00 00 c0 04 3b 06 80 6b 01 81 4b 02 03 // // 4b 02 01 / TMS shift no read // 39 02 00 00 c0 04 / IN OUT 3 bytes read // 3b 06 80 / IN OUT 1 byte read // 6b 01 81 / TMS shift 1 byte read // 4b 02 03 / TMS shift no read // // This command buffer should return 5 bytes data. / Thanks a lot Laurent for this dissecting. / // There are no reason here the Amontec JTAGkey-2 do not send back the 5 bytes, // except if you have RTCK return clock enabled !!! / RTCK is not enabled, I double-checked. JTAG speed is : adapter_khz 1000. CPU freq should be around 12MHz, so this speed should be quite OK. SDRAM initialization sequence and smaller files writes works quite right at these speeds. Larger images writes have this error. If you do not use RTCK feature, there are really no reason it is coming from the JTAGkey-2 mpsse interface hardware. / // But a bad previous command buffer could corrupt the JTAGkey-2 ft2232 mpsse // interface. // // Please send me the complet debug file . /Hmm... I'll have to see how I can do this. The file is almost gigabyte in size. Maybe you can point me what to look for in the log, or which parts would be significant ? I do not need the complete debug log file for sure :-) but try to cut it with 2 to 4 command queue execute before your trouble. I am thinking of a corrupted mpsse command just before your send the command buffer we are talking about. Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey-3 coming soon ! Generic USB JTAG CJTAG SWD SWO serial wire debug interface 1.5V 1.8V 2.5V 3.3V 5V auto-sense protected IOs With RTCK support / // Also, could you please try the same with Amontec JTAGkey D22X WHQL certified // driver you found at // http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip / I'll try these and keep you informed. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS and Big Endian
It is not a trouble regarding the JTAG Frequency here. If you ask the Amontec JTAGkey-2 to scan in/out it will scan in/out at the frequency you provided. If you provided a too high TCK frequency, without the RTCK enabled, the data returned will be not correct, but will be EVER present and EVER complete (at 30Mhz TCK frequency or at 1MHz TCK frequency ). The problem here is regrading the number of returned bytes, and not on which frequency Drasko run the scan. I am waiting on the log using the Amontec JTAGkey d2xx WHQL certified driver . Maybe we will see something different, in this case it is a trouble in the libftdi . If the same some trouble in the higher JTAG level in openocd source. Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey-3 coming soon ! Generic USB JTAG CJTAG SWD SWO serial wire debug interface 1.5V 1.8V 2.5V 3.3V 5V auto-sense protected IOs With RTCK support Mathias K. wrote: I think you should reduce your clock speed first. Am 17.03.2011 16:27, schrieb Drasko DRASKOVIC: clock speed 6000 kHz ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS and Big Endian
Drasko DRASKOVIC wrote: On Thu, Mar 17, 2011 at 3:19 PM, Laurent Gauch laurent.ga...@amontec.com wrote: I do not need the complete debug log file for sure :-) but try to cut it with 2 to 4 command queue execute before your trouble. I am thinking of a corrupted mpsse command just before your send the command buffer we are talking about. Hi Laurent, here are the logs that hopefully shows more information about the error. Please find them below. All was tested with libftdi, and not with Amontec driver. First group of error that appears only sometimes during the init phase, Error: 244 4321 ft2232.c:584 ft2232_read(): couldn't read enough bytes from FT2232 device (0 81), is not systematic and I think that it is not dangerous. But this Error: 244 is not normal anyway, and I would like to understand this before going to Error: 4163129 The Error: 244 is coming really quickly when we try to detect the IDCODEs of the chain ... This is really bad already. I would to see this is coming from the kernel driver. (we already see couldn't read enough bytes from (0 xx) when we started with the JTAGkey-2 based FT2232H ... updating the driver was resolving the trouble) Please let me know the result with Amontec JTAGkey d2xx WHQL certified driver . Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey-3 coming soon ! Generic USB JTAG CJTAG SWD SWO serial wire debug interface 1.5V 1.8V 2.5V 3.3V 5V auto-sense protected IOs With RTCK support Other errors like this : Error: 4163129 274107 ft2232.c:584 ft2232_read(): couldn't read enough bytes from FT2232 device (0 5) are something that is systematic, appears every time and I think they are main problem during the write. I hope that these logs give more information. I will try the same tests with Amontec driver and keep you informed of results. BR, Drasko Debug: 132 43 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_init Debug: 133 43 command.c:151 script_debug(): command - init ocd_init Debug: 135 43 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_target init Debug: 136 43 command.c:151 script_debug(): command - ocd_target ocd_target init Debug: 138 43 target.c:911 handle_target_init_command(): Initializing targets... Debug: 139 43 command.c:364 register_command_handler(): registering 'ocd_target_request'... Debug: 140 44 command.c:364 register_command_handler(): registering 'ocd_trace'... Debug: 141 44 command.c:364 register_command_handler(): registering 'ocd_trace'... Debug: 142 44 command.c:364 register_command_handler(): registering 'ocd_fast_load_image'... Debug: 143 44 command.c:364 register_command_handler(): registering 'ocd_fast_load'... Debug: 144 44 command.c:364 register_command_handler(): registering 'ocd_profile'... Debug: 145 44 command.c:364 register_command_handler(): registering 'ocd_virt2phys'... Debug: 146 44 command.c:364 register_command_handler(): registering 'ocd_reg'... Debug: 147 44 command.c:364 register_command_handler(): registering 'ocd_poll'... Debug: 148 44 command.c:364 register_command_handler(): registering 'ocd_wait_halt'... Debug: 149 44 command.c:364 register_command_handler(): registering 'ocd_halt'... Debug: 150 44 command.c:364 register_command_handler(): registering 'ocd_resume'... Debug: 151 44 command.c:364 register_command_handler(): registering 'ocd_reset'... Debug: 152 44 command.c:364 register_command_handler(): registering 'ocd_soft_reset_halt'... Debug: 153 44 command.c:364 register_command_handler(): registering 'ocd_step'... Debug: 154 44 command.c:364 register_command_handler(): registering 'ocd_mdw'... Debug: 155 44 command.c:364 register_command_handler(): registering 'ocd_mdh'... Debug: 156 44 command.c:364 register_command_handler(): registering 'ocd_mdb'... Debug: 157 44 command.c:364 register_command_handler(): registering 'ocd_mww'... Debug: 158 44 command.c:364 register_command_handler(): registering 'ocd_mwh'... Debug: 159 44 command.c:364 register_command_handler(): registering 'ocd_mwb'... Debug: 160 44 command.c:364 register_command_handler(): registering 'ocd_bp'... Debug: 161 44 command.c:364 register_command_handler(): registering 'ocd_rbp'... Debug: 162 44 command.c:364 register_command_handler(): registering 'ocd_wp'... Debug: 163 44 command.c:364 register_command_handler(): registering 'ocd_rwp'... Debug: 164 44 command.c:364 register_command_handler(): registering 'ocd_load_image'... Debug: 165 44 command.c:364 register_command_handler(): registering 'ocd_dump_image'... Debug: 166 44 command.c:364 register_command_handler(): registering 'ocd_verify_image'... Debug: 167 44 command.c:364 register_command_handler(): registering 'ocd_test_image'... Debug: 168 44 command.c:364 register_command_handler(): registering 'ocd_reset_nag'... Debug: 169 44 ft2232.c:2433 ft2232_init(): ft2232 interface using shortest path jtag state transitions Debug: 170 44 ft2232.c:2306 ft2232_init_libftdi(): 'ft2232' interface
Re: [Openocd-development] [PATCH] jtag: clean up jtag_sleep, handle short sleeps correctly via usleep
---
src/jtag/core.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/jtag/core.c b/src/jtag/core.c
index d7e1cce..68c1257 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -871,9 +871,16 @@ static int jtag_reset_callback(enum jtag_event event, void
*priv)
return ERROR_OK;
}
+/* sleep at least us microseconds. When we sleep more than 1000ms we
+ * do an alive sleep, i.e. keep GDB alive. Note that we could starve
+ * GDB if we slept for 1000ms many times.
+ */
void jtag_sleep(uint32_t us)
{
- alive_sleep(us/1000);
+ if (us 1000)
+ usleep(us);
+ else
+ alive_sleep((us+999)/1000);
}
/* Maximum number of enabled JTAG devices we expect in the scan chain,
--
1.7.0.4
But I think the mechanism itself is not so good.
We should not have to touch JTAG level to keep GDB connection alive !.
Also, the jtag_sleep should be exclusively used to sleep the JTAG in
stable JTAG STATE, by running some TCK to generate the corresponding
delay we want.
Regards,
Laurent
Amontec JTAGkey-2 HIGH-SPEED USB JTAG USB SPI 1.5V 1.8V 2.5V 3.3V 5V
auto-sensing IO
http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag: clean up jtag_sleep, handle short sleeps correctly via usleep
Øyvind Harboe wrote:
On Thu, Mar 3, 2011 at 3:29 PM, Laurent Gauch laurent.ga...@amontec.com wrote:
---
src/jtag/core.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/jtag/core.c b/src/jtag/core.c
index d7e1cce..68c1257 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -871,9 +871,16 @@ static int jtag_reset_callback(enum jtag_event event,
void *priv)
return ERROR_OK;
}
+/* sleep at least us microseconds. When we sleep more than 1000ms we
+ * do an alive sleep, i.e. keep GDB alive. Note that we could starve
+ * GDB if we slept for 1000ms many times.
+ */
void jtag_sleep(uint32_t us)
{
- alive_sleep(us/1000);
+ if (us 1000)
+ usleep(us);
+ else
+ alive_sleep((us+999)/1000);
}
/* Maximum number of enabled JTAG devices we expect in the scan chain,
--
1.7.0.4
But I think the mechanism itself is not so good.
We should not have to touch JTAG level to keep GDB connection alive !.
That's a valid, but orthogonal objection. It would pretty much require
multithreading of OpenOCD.
Dear Harboe,
Yes, you're totally right.
Also, the jtag_sleep should be exclusively used to sleep the JTAG in stable
JTAG STATE, by running some TCK to generate the corresponding delay we want.
This should be enforced today by pathmove requiring start/end
state to be stable states.
Yes, right. But the how we come in stable state is an other story, you
know ...
Anyway, adding delays on JTAG level should be corresponding to
generating some TCK in stable state, EVER.
We never should have to add ANY 'software' delay in the JTAG level , if
we do (and I think we do) this is the better way to get instable ISP.
Regards,
Laurent
Amontec JTAGkey-2 HIGH-SPEED USB JTAG USB SPI 1.5V 1.8V 2.5V 3.3V 5V
auto-sensing IO
http://www.amontec.com http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag: clean up jtag_sleep, handle short sleeps correctly via usleep
Øyvind Harboe wrote: Anyway, adding delays on JTAG level should be corresponding to generating some TCK in stable state, EVER. We never should have to add ANY 'software' delay in the JTAG level , if we do (and I think we do) this is the better way to get instable ISP. the delay is typically used to wait for SRST to float back up and the sorts. JTAG can be gated during these operations. JTAG gated and waiting an external event ! wait-for-event So this should be more like a JTAG_pause() command than a JTAG_sleep(us) command. Short delays, when possible, are better to implement as clocking out ticks. Yes, using TCK in a STABLE STATE. Regards, Laurent Amontec JTAGkey-2 HIGH-SPEED USB JTAG USB SPI 1.5V 1.8V 2.5V 3.3V 5V auto-sensing IO http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Why removing a lot of code ?
As :
static int jtagkey_init(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x1b;
/* initialize low byte for jtag */
- buf[0] = 0x80; /* command set data bits low byte */
- buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
- buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO =
in, nOE = out */
- LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
- if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 with 'JTAGkey' layout);
return ERROR_JTAG_INIT_FAILED;
Please explain?
Regards,
Laurent
http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Hi Mathias,
Yes, you're right and your patch works.
We can merge it.
Also, your patch make the code source smaller. ;-)
Regards,
Laurent
http://www.amontec.com
K. wrote:
Hello,
the mpsse buffer preparation and send functionality is done in:
ft2232_set_data_bits_low_byte
ft2232_set_data_bits_high_byte
You only need to deliver the port value and direction to this functions. Thats
all.
Regards,
Mathias
Am 14.02.2011 10:36, schrieb Laurent Gauch:
Why removing a lot of code ?
As :
static int jtagkey_init(void)
{
-uint8_t buf[3];
-uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x1b;
/* initialize low byte for jtag */
-buf[0] = 0x80; /* command set data bits low byte */
-buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
-buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO = in,
nOE = out */
-LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
-if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 with 'JTAGkey' layout);
return ERROR_JTAG_INIT_FAILED;
Please explain?
Regards,
Laurent
http://www.amontec.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
Re: [Openocd-development] stm32f2xxx flash support
Everything I've tried works well... Individual sector erase, multiple sector erase up to the full device, image writes, image writes with auto-erase, gdb debugging through Eclipse. Thanks for your work on this! Mike Lake What version of OpenOCD do you use ? Regards, Laurent Gauch http://www.amontec.com Amontec JTAGkey-3 Generic USB JTAG on the road and coming with bus transport bonus as CJTAG SWD SWV I2C 1-wire ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
Here I have objection. Adding delay by flushing queue is not a good implementation, since the flush of the queue will have different timing regarding the JTAG probe used: - With Amontec JTAGkey USB full-speed a flush will be around 1-2ms - With Amontec JTAGkey-2 USB High-speed a flush will be around 125us - 250us. - With the coming Amontec Smart JTAGkey-x (running openocd on the JTAGkey) a flush will be around 100ns - 200ns. ... For JTAG the best to add delay will be to use a run tck in IDLE state. Regards, Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
