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
Re: [Openocd-development] [BUG] Driver for USB-Blaster (partially) broken
Hi, a little change... a great effect... I just tested your changes on a local copy of openocd and now I get my Altera USB-Blaster at work. Now it's possible to detect the jtag tap of my device. (without the patch i got errorss like all ones and zeros...) 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. Best regards! Stefan Zitat von Felix dg1...@gmx.de: Can you git bisect to find the problem commit? After having a look at the git commits, it seems that the first commit from 2009-12-29 already has the broken version. The sane version I was referring to, was passed to the mailing list by Catalin Patulea (cat at vv.carleton.ca) on Sun Dec 20 09:25:38 CET 2009 (http://lists.berlios.de/pipermail/openocd-development/2009-December/013731.html). I thought this to be the same version that was committed s initial version, but unfortunatly it wasnt. Maybe I can help out with this patch (I'm quit new to git, I hope I didnt mess up something ;) ) index 1679040..b0df7d3 100644 --- a/src/jtag/drivers/usb_blaster.c +++ b/src/jtag/drivers/usb_blaster.c @@ -234,7 +234,7 @@ usb_blaster_buf_read(uint8_t *buf, unsigned size, uint32_t *bytes_read) #define NCE(1 2) #define NCS(1 3) #define TDI(1 4) -#define LED(1 5) +#define LED_OE (1 5) #define READ (1 6) #define SHMODE (1 7) #define OTHERS ((1 2) | (1 3) | (1 5)) @@ -277,6 +277,9 @@ static void usb_blaster_write(int tck, int tms, int tdi) if (tdi) out_value |= TDI; + // enable output of CPLD + out_value |= LED_OE; + usb_blaster_write_data(); } ___ 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] [BUG] Driver for USB-Blaster (partially) broken
Hi, 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? kind regards Felix ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [BUG] Driver for USB-Blaster (partially) broken
Hi, the driver for the Altera USB-Blaster and compatibles in version 0.4.0 (and up to the current git snapshot) is (at least partially) broken. Somewhere in the merge process, the bit which enables the output (and the LED in the original altera usb blaster) must have got lost. It was included in the first version supplied to the mailing list in december 2009. At the moment the output of the CPLD which drives the JTAG (and the GPIO) pins just stays in tristate (at least with the original USB Blaster, maybe some clones dont use this functionality and provide always-enabled outputs) and does not do anything. After fixing this bug I ran into some speed issues (maybe a problem of libftdi). JTAG communication basically works, but is incredibly slow (TCLK about 100 Hz - not kHz). So its not really usable for debugging in this way (as I said, maybe this is related to libftdi). I'll try to provide a patch for that if no one else is working on it. 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
Can you git bisect to find the problem commit? Felix dg1...@gmx.de wrote: Hi, the driver for the Altera USB-Blaster and compatibles in version 0.4.0 (and up to the current git snapshot) is (at least partially) broken. Somewhere in the merge process, the bit which enables the output (and the LED in the original altera usb blaster) must have got lost. It was included in the first version supplied to the mailing list in december 2009. At the moment the output of the CPLD which drives the JTAG (and the GPIO) pins just stays in tristate (at least with the original USB Blaster, maybe some clones dont use this functionality and provide always-enabled outputs) and does not do anything. After fixing this bug I ran into some speed issues (maybe a problem of libftdi). JTAG communication basically works, but is incredibly slow (TCLK about 100 Hz - not kHz). So its not really usable for debugging in this way (as I said, maybe this is related to libftdi). I'll try to provide a patch for that if no one else is working on it. Felix ___ 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] [BUG] Driver for USB-Blaster (partially) broken
Can you git bisect to find the problem commit? After having a look at the git commits, it seems that the first commit from 2009-12-29 already has the broken version. The sane version I was referring to, was passed to the mailing list by Catalin Patulea (cat at vv.carleton.ca) on Sun Dec 20 09:25:38 CET 2009 (http://lists.berlios.de/pipermail/openocd-development/2009-December/013731.html). I thought this to be the same version that was committed s initial version, but unfortunatly it wasnt. Maybe I can help out with this patch (I'm quit new to git, I hope I didnt mess up something ;) ) index 1679040..b0df7d3 100644 --- a/src/jtag/drivers/usb_blaster.c +++ b/src/jtag/drivers/usb_blaster.c @@ -234,7 +234,7 @@ usb_blaster_buf_read(uint8_t *buf, unsigned size, uint32_t *bytes_read) #define NCE(1 2) #define NCS(1 3) #define TDI(1 4) -#define LED(1 5) +#define LED_OE (1 5) #define READ (1 6) #define SHMODE (1 7) #define OTHERS ((1 2) | (1 3) | (1 5)) @@ -277,6 +277,9 @@ static void usb_blaster_write(int tck, int tms, int tdi) if (tdi) out_value |= TDI; + // enable output of CPLD + out_value |= LED_OE; + usb_blaster_write_data(); } ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
