Re: [Openocd-development] [BUG] Driver for USB-Blaster (partially) broken
/ But it seems to be very slow. I got a lot of packet errors, when loading a binary... I will check my configuration files tomorrow and try to get a binary loaded and debugged. /yep - I discovered the same problem. It seems that it takes in the range of ms (USB Poll interval?) between single commands. I got a TCK speed of about 100-300 Hz with LIBFTDI. It becomes significantly faster if more than one byte is sent to libftdi in one call. So there IMHO this calls for aggregation of data before passing it to the interface. Are there similar issues with comparable USB Devices? Hi Felix, They are two major troubles with the Altera USB Blaster : 1. This one could be corrected in the Openocd source : I remember when Dominic (the creator / author of OpenOCD) ask me about speed on december 2004 ... yes, 2004 ! I replied to Dominic to queue a maximum of commands before sending to the Amontec JTAGkey ( http://www.amontec.com ). This was what we done on begin of 2005 in the OpenOCD ft2232 API driver. So if you want to accelerate the Altera USB Blaster you have to queue the commands in the API driver and then send a sequence of command to the device. 2. This one cannot be corrected/modified in the OpenOCD source ( Blaster hardware issues): A debug session of a ARM or ARM Cortex processor need to have control of SRST (System Reset) and sometimes TRST (TAP Reset). The Altera USB Blaster do not provide these signals by default and this will be a potential source of error when connecting to your target. Also, the RTCK (Return Clock) is not supported by the USB Blaster. The RTCK is really important to have on ARM7tdmi-s or the newer Cortex-A9 (Ax) ... to name a few. The RTCK helps to synchronize the JTAG Emulator with the target frequency. The JTAG frequency of the Blaster is difficult to manage. It is OK for programming a FPGA, but troubleshooting when debugging a ARM ! Regards, Laurent Gauch http://www.amontec.com Amontec USB JTAG Cable JTAGkey Series Amontec JTAGkey-2 hardware key features : backward compatible with Amotnec JTAG key SRST TRST RTCK signal support JTAG frequency software programmable from 500Hz to 30Mhz maximum 30MHz JTAG JTAG IOs auto-sense from 1.3V to 5.5V UHS buffers providing 32mA output on each JTAG IO s Hi-speed USB 2.0 480MHz SRST and TRST programmable as push-pull or open-drain SRST can be monitored VREF can be monitored USB plug-and-play JTAG hot-plug four (4x) on-board LEDs windows WHQL certified drivers (from wondows 2000 to windows win 7 32 bits and 64 bits) Linux driver MAC OSx driver ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [BUG] Driver for USB-Blaster (partially) broken
Hi Laurent, They are two major troubles with the Altera USB Blaster : [...] So if you want to accelerate the Altera USB Blaster you have to queue the commands in the API driver and then send a sequence of command to the device. I realized that and I'm currently working on it. Also I have an idea how to implement a speed reduction (sometimes the 3 MHz provided by the blaster are too much). 2. This one cannot be corrected/modified in the OpenOCD source ( Blaster hardware issues): A debug session of a ARM or ARM Cortex processor need to have control of SRST (System Reset) and sometimes TRST (TAP Reset). The Altera USB Blaster do not provide these signals by default and this will be a potential source of error when connecting to your target. Well, the blaster does have 2 unused GPIOs which can be used for this. I already implemented a command to assign these GPIOs to SRST and/or TRST including also the possibility to use inverted logic (nSRST/nTRST). Also, the RTCK (Return Clock) is not supported by the USB Blaster. The RTCK is really important to have on ARM7tdmi-s or the newer Cortex-A9 (Ax) ... to name a few. The RTCK helps to synchronize the JTAG Emulator with the target frequency. The JTAG frequency of the Blaster is difficult to manage. It is OK for programming a FPGA, but troubleshooting when debugging a ARM ! At the moment it seems as it will work for my Cortex-M3, everything beyond that does not bother me at the moment. I think there is a possibility to include the RTCK feature, but this would need a hardware mod to the blaster and maybe adaption of the CPLD code. But as I said, this does not bother me right now :) regards, Felix ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [BUG] Driver for USB-Blaster (partially) broken
Hi Laurent, / They are two major troubles with the Altera USB Blaster : /[...] / So if you want to accelerate the Altera USB Blaster you have to queue // the commands in the API driver and then send a sequence of command to // the device. /I realized that and I'm currently working on it. Also I have an idea how to implement a speed reduction (sometimes the 3 MHz provided by the blaster are too much). It should be good to be able to reduce downto 4KHz (32Khz / 6 or 8) for the startup of some ARM7 ! / 2. This one cannot be corrected/modified in the OpenOCD source ( Blaster // hardware issues): // A debug session of a ARM or ARM Cortex processor need to have control of // SRST (System Reset) and sometimes TRST (TAP Reset). The Altera USB // Blaster do not provide these signals by default and this will be a // potential source of error when connecting to your target. /Well, the blaster does have 2 unused GPIOs which can be used for this. I already implemented a command to assign these GPIOs to SRST and/or TRST including also the possibility to use inverted logic (nSRST/nTRST). great to know ! This is a good point for Blaster ! doc doc doc ... / Also, the RTCK (Return Clock) is not supported by the USB Blaster. The // RTCK is really important to have on ARM7tdmi-s or the newer Cortex-A9 // (Ax) ... to name a few. The RTCK helps to synchronize the JTAG Emulator // with the target frequency. // The JTAG frequency of the Blaster is difficult to manage. It is OK for // programming a FPGA, but troubleshooting when debugging a ARM ! /At the moment it seems as it will work for my Cortex-M3, everything beyond that does not bother me at the moment. I think there is a possibility to include the RTCK feature, but this would need a hardware mod to the blaster and maybe adaption of the CPLD code. But as I said, this does not bother me right now :) regards, Felix 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] Linux application debugging(run mode) using DCC driver
I just saw a driver that adds DCC as a serial driver. My thinking is that gdbserver could be hooked up to this serial port and with a few tweaks to OpenOCD the DCC channel could be forwarded to a TCP/IP port. From there one could connect using GDB to do application debugging. For devices that do not have a spare serial/ethernet port, this could be useful for application space debugging. Thoughts? What other ways are there to do this? Any thoughts on how the user would upload applications to the Linux target before starting gdbserver? DCC serial driver: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/92400 -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Linux application debugging(run mode) using DCC driver
On 10/6/2010 4:23 PM, Øyvind Harboe wrote: Any thoughts on how the user would upload applications to the Linux target before starting gdbserver? SLIP or PPP over DCC :-) -duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
