From Terasic Wiki
To install the driver for your USB Blaster cable, follow the instruction for your particular operating system.
For Windows 10, do the following:
- Plug the USB-Blaster into your PC.
- Open the Device and Printers (Control Panel | Devices and Printers).
- Under Unspecified, USB Blaster should be listed. Right mouse click on this and then select Properties.
- Select the Hardware tab and select Properties.
- A new window should pop up with the General tab already selected. Select Change Settings.
- Again a new window should pop up with the General tab already selected. Select Update.
- Select Browse my computer for driver software.
- Find <Path to Quartus II installation>quartusdrivers
This forum discuss about how to JTAG different devices. Subforums: JTAG (NT) on Cable Boxes, JTAG on dct2500/dct700, JTAG on DVI3000, DCT64XX,DCT34XX, JTAG ON DCH boxes, USB JTAG (NT) on SurfBoard Modems, JTAG (NT) Modem newbie, SB5XXX, SB4XXX, WiFi modem, SB6XXX, Other modems, JTAG on Dish Receivers., USB JTAG NT on XBOX, USB JTAG (NT) on VOIP. Connect the USB Debug Adapter’s 10-pin ribbon cable to the JTAG or Debug connector on the target board. Connect one end of a standard USB cable to the USB connector on the USB Debug Adapter. Connect the other end of the USB cable to a USB Port on the PC. Power the target board.
This videos will describe how use and debug the USB Blaster interface to configure Intel FPGAs.For technical questions, contact the Intel Community: https://. If you want to use UrJTAG with a JTAG cable attached to the USB port, actual cable drivers have to be installed beside UrJTAG itself. Usually, the cable vendor will provide the drivers. For example, drivers for Altera USB-Blaster come with their Quartus software.
- (Note 1: Your altera file is located at the location you selected when you first installed quartus. The location listed in this document is the default location)
- (Note 2: Stop at the drivers folder, i.e., do NOT go deeper by opening a folder within the drivers folder)
- Select OK. Make sure the proper path was selected then select Next.
- If the Windows security window pops up Check the Always trust software from “Altera Corporation”box and select Install.
For Windows 7 and Windows 8, do the following:
- Plug the USB-Blaster download cable into the PC. The following will appear on the screen: Device driver software was not successfully install. Select Click here for details.
- Select Change settings…
- Now cancel this (probably by selecting Cancel)
- Open the Device Manager (Windows Key | Control Panel | Device Manage)
- Under Other devices, USB Blaster should be listed. Right mouse click on this and then select Update Driver Software…
- Select Browse my computer for driver software
- Find <Path to Quartus II installation>quartusdrivers, then select Next; (Note: Stop at this folder, i.e., do NOT go deeper by opening a folder within the drivers folder)
- Check the Always trust … box and then select Install
For Windows Vista, do the following:
- Plug the USB-Blaster download cable into the PC. The Found New Hardware dialog box appears.
- Select Locate and install driver software (recommended).
- Select Don't search online.
- When you are prompted to Insert the disc that came with your USB-Blaster, select I don’t have the disc. Show me other options.
- Select Browse my computer for driver software (advanced) when you see the Windows couldn’t find driver software for your device.
- Click Browse... and browse to the <Path to Quartus II installation>driversusb-blaster directory. Click OK.
- Select the Include subfolders option and click Next.
- If you are prompted Windows can’t verify the publisher of this driver software, select Install this driver software anyway in the Window Security dialog box.
- The installation begins.
- When The software for this device has been successfully installed appears, click Close.
For Windows XP, do the following:
- Plug the USB-Blaster download cable into the PC. The Found New Hardware dialog box appears.
- Select Locate and install driver software (recommended).
- Select Don't search online.
- When you are prompted to Insert the disc that came with your USB-Blaster, select I don’t have the disc. Show me other options.
- Select Browse my computer for driver software (advanced) when you see the Windows couldn’t find driver software for your device.
- Click Browse... and browse to the <Path to Quartus II installation>driversusb-blaster directory. Click OK.
- Select the Include subfolders option and click Next.
- If you are prompted Windows can’t verify the publisher of this driver software, select Install this driver software anyway in the Window Security dialog box.
- The installation begins.
When The software for this device has been successfully installed appears, click Close. If you are running Windows in 64-bit mode, you MUST boot your computer as following both when installing the USB-Blaster driver AND when using Quartus to program your PLD.
- During boot up of the computer, continuously press F8 (but do NOT hold it down).
- Scroll down to “Disable Driver Signature Enforcement,” then hit Enter.
You must set up the driver before programming your PLD (CPLD or FPGA)
Driver
Reference
Cable drivers
Link drivers
TAP drivers
Chain drivers
Bus drivers
Flash drivers
Commands
Cable-specific drivers are those which are visible to the user throughthe 'jtag' command shell. They’re listed in response to the 'help cable'command. Each driver has to provide the following functions:
connect(), init() - Initialization
done(), cable_free(), disconnect() - Cleaning up
set_frequency() - set bitrate for shifting data through the chain
clock(), get_tdo(), transfer() - immediate JTAG activities
flush() - internally used to actually perform JTAG activities
help() - a help text to be displayed by the jtag command shell
After allocating a 'cable_t' structure, a pointer to it and furtherparameters (as strings) have to be passed first to the selected cable’sconnect() function.
Following that, the init() function is called via cable_init(). If cable_init()returns a zero value, all is fine and the cable is ready for use.
4.2.1.2. Cleaning upThere are two functions for actual cleanup:
done() is responsible for driving the hardware to a safe and consistent state.
cable_free() then can be used to clean up eventually extra allocated memory etc.
Both are usually called from chain_disconnect().
An additional mechanism allows to clean up if a disconnection was detected bythe low level driver (e.g. USB or parallel port driver). A cable has to providea disconnect() function for this purpose:
Low level (e.g. parport) driver calls cable driver→disconnect()
cable driver→disconnect() calls chain_disconnect()
chain_disconnect() calls cable driver→done()
chain_disconnect() then calls cable driver→cable_free()
After return from chain_disconnect() to cable driver→disconnect(), the cable_tstructure has been freed and must not be accessed anymore.
4.2.1.3. JTAG ActivitiesCurrently the API provides five different functions for performing operationsat the JTAG interface on the low level signal level (using the four signalsTMS, TCK, TDI, and TDO).
clock(tms,tdi,n) takes values for TMS and TDI output as its parameters, ensures that actual cable signals are set accordingly, and does a 0-1 transition on TCK (n times)
get_tdo() returns the current value at the TDO input.
set_trst(x) sets the TRST signal and returns the current value.
get_trst() returns the current value of the TRST signal.
For many JTAG adapters, there’s almost no delay when doing alternating clock()and get_tdo(). Writing and reading happens immediately and the result isavailable immediately as well. This is the case with most parallel portadapters (but not when attached to USB-to-parallel adapters or USB dockingstations) and memory mapped IO (e.g. general purpose I/O pins ofmicrocontrollers).
But there are adapters, especially USB and Ethernet based adapters, whichexhibit a rather long delay between the initiation of reading a bit and thedelivery of the value of the bit. It is at least 1 millisecond with USB,which would limit the transfer rate to 1 kHz. One way to workaround thisis to transmit bits compacted into bytes and chunks of bytes, which ispossible with the transfer() function.
transfer(in, out)
The transfer() function does a series of TCK pulses, with data for TDI read asbytes from memory. The bytes are automatically serialized. TMS is set to zeroduring transfer()s. Optionally, prior to each bit shifted out to the interface,TDO input can be read into memory (deserialized into a byte array of the samesize as the input array).
It still doesn’t yield much improvement if the operation consists of many readand write transitions (e.g. repeatedly writing an instruction and some dataregister values, then reading from the data register, as it is necessary formemory access). For that reason, the above functions are also available invariants that don’t cause immediate activity, but rather schedule it for later.In the API, they’re visible as
cable_defer_clock()
cable_defer_get_tdo()
cable_defer_set_trst()
cable_defer_get_trst()
cable_defer_transfer()
These functions aren’t implemented in the cable driver (but currently insrc/tap/cable.c). The cable driver just has to provide a flush() function toactually execute the queued activity in some cable-specific optimal way, andto store the results of get_tdo() and transfer() activity. The caller latercan pick up the results using these functions (implemented in cable.c):
cable_get_tdo_late()
cable_get_trst_late()
cable_transfer_late()
As an example, consider the following sequence of activities:
clock()
get_tdo()
clock()
get_tdo()
If the result of the first get_tdo() isn’t absolutely required before thesecond clock(), the sequence can be optimized into the following sequence (if
defer_clock()
defer_clock()
flush()
get_tdo_late()
get_tdo_late()
The next sections explain the queueing mechanism and its limits in detail.
4.2.1.4. When flushing occursThe cable_flush() function is used to flush the queue towards the cable. Ittakes one additional argument, 'how_much', which may be one of
OPTIONALLY: The cable driver may flush if it’s reasonable (e.g. if the queue has been filled so that some buffer limit for the cable interface is reached). It would be wise to flush early to keep the queue small, if there is no point in queueing up more items because the transfer to the cable would have to be split into smaller chunks anyway. This is used by UrJTAG immediately after adding items to the queue.
TO_OUTPUT: The cable driver should at least flush as much so that one output becomes available in the output queue. If there’s already something in the output queue, this should be interpreted similar to OPTIONALLY. This is used by UrJTAG immediately before it wants to use that output.
COMPLETELY: The cable driver has to flush the queue completely. This is used by UrJTAG immediately before actions that circumvent the queueing such as calls to the legacy clock/get_tdo functions. It could also be used by application code to ensure that some action is actually done in time.
The source in src/tap/cable.c provides to important functions to access thetwo queues 'todo' (with activity to be done) and 'done' (with results):
cable_add_queue_item
cable_get_queue_item
In src/tap/cable/generic.c you’ll find two implementations of dequeueingalgorithms, i.e. implementations of the flush() function. These could be usedby any new cable driver unless it provides a more sophisticated algorithmitself:
generic_flush_one_by_one() simply calls the 'classic' functions one after another. The performance of the cable driver using this implementation will be the same whether the immediate or defer variants of the functions are used.
generic_flush_using_transfer() tries to optimize as many clock() and get_tdo() by transforming them into calls to transfer() instead. This can give a slight advantage.
The generic implementations also serve as a template for new cable-specificimplementations.
4.2.1.6. Generic implementationsAs a reference and in many cases completely sufficient for new cables, take alook at the code in src/tap/cable/generic.c, which contains generic routines,suitable for parallel port based cables (and some for other types of cables aswell).
4.2.2. Link driversLink drivers like the 'parport' driver collection provide the basis forcommunication between cable driver and actual JTAG adapter. The openwince JTAGtools supported only parallel port links with the 'parport' drivers. UrJTAGintroduced support for USB links, but in the early releases the drivers forthese just mimic the parallel port links.
The basic functions provided by all link drivers are
connect(), to called from cable driver connect()
open(), to actually connect to the device during cable driver init()
close(), to disconnect from the device during cable driver done()
free(), to free all resources, called from cable driver free()
Currently there are parport drivers for direct access to the parallel port on aPC using I/O addresses (direct.c), and for using ppdev on Linux or ppi on FreeBSD.
In addition, there are 'ftdi' and 'ftd2xx' parport drivers that actually are forcommunication with USB cables based on FTDI chips. They cannot be used forconnecting old parallel port cables through parallel to USB adapters with FTDIchips, and probably soon will be rewritten as 'usbconn' drivers instead.
All parport drivers present a common API for setting and reading signals.
4.2.2.2. usbconnThe usbconn drivers provide a common API to search for and connect with USBdevices. At the moment, there are drivers for libusd, libftdi and FTD2XX(e.g. to communicate with FTDI chip based cables through libftdi and/orFTD2XX, to communicate with Cypress FX2 using EZUSB.SYS or CyUSB.sys, andmore).
4.2.3. Bus driversBus drivers translate read and write operations on a bus into JTAG commandsand methods. A bus in this context is neither restricted to a processor bus,nor to memory. Any system component that can be read from and written to couldbe seen as attached to a bus. I.e. external or internal memory (RAM, ROM,Flash) and peripherals connected to a processor or simply an FPGA with 1:1connections.
The available bus drivers are listed in response to 'help initbus'. Eachdriver has to provide the following functions:
bus_new() - Initialization
bus_free() - Cleaning up
bus_printinfo() - Short description
bus_prepare() - Preparation
bus_area() - Description of the bus geometry
bus_read_start() - Initiate reading
bus_read_next() - Read access
bus_read_end() - Finish reading
bus_read() - Atomic reading
bus_write() - Write access
Address parameters to the functions listed above specify alwaysbyte locations, independent of the actual data width. The bus driver has toadjust the address on its own if required.
4.2.3.1. CreationUpon calling of its bus_new() function, the driver allocates a 'bus_t'structure and performs all required internal initializations.
4.2.3.2. InitializationAfter creation of the new 'bus_t' structure, the bus_init() function willbe called to give the driver the possibility to initialize it’s internalstates or BSR bits as required. Such functionality has been split frombus_new() since some drivers require to re-initialize during runtime.
4.2.3.3. Cleaning upThe driver is supposed to free all allocated memory (including its 'bus_t'structure). Additionally, it should set the device into a state that doesn’tprevent it from normal operation.
4.2.3.4. Short descriptionPrints a message describing the driver. This function is called by the 'print'command before it lists the areas covered by this bus driver.
4.2.3.5. Preparation
This function is called whenever a bus operation is initiated. Thedriver should perform the required preparation steps so thatsubsequent calls to the bus_read_* and bus_write functions can performtheir tasks properly.
E.g. a BSR bus driver would put the device into EXTEST mode to activate theboundary scan register on the device pins.
4.2.3.6. Description of the bus geometryUsb Jtag Cable Drivers Free
At certain stages, the bus driver’s bus_area() function is called by othercommands to query the bus geometry for a given address. The bus driver mustfill in the fields of a 'bus_area_t' structure describing the geometry of thearea in which the specified address is located:
a short textual description of the area
start address of area
length of area in bytes
data width in bits
Queries with an address out of range must result in an area length of
4.2.3.7. Initiate readingSince the JTAG state machine defines a capture-shift-update sequence, it isrequired to shift the address for a read prior to capturing the readdata. Therefore, the bus_read_start() function is called with the very firstaddress to read from. This enables the driver to shift the address into thedevice before it can actually retrieve the read data for this address.
4.2.3.8. Read accessThe bus_read_next() function fetches the read data from the device that hasbeen addressed by a previous call to bus_read_start() orbus_read_next(). Again, this is due to the capture-shift-update sequence ofJTAG:
capture read data from device pins
shift new address
update new address to device pins
The address parameter specifies the location of the
Function 'bus_read_end()' is called at the end of a read sequence. I.e. whenthe higher level command determines that the last data portion is to be readfrom the device. There is no new address and the function driver is supposedto return the read data that was addressed previously.
4.2.3.10. Atomic readingFor ease of use, a bus driver has to supply a 'bus_read()' function thatencapsulates reading data from a single address in an atomic operation. Busdrivers typically build this function from 'bus_read_start()' and a subsequent'bus_read_end()'.
4.2.3.11. Write accessUsb Jtag Cable Drivers Windows 10
This function writes one data element at the specified address. Since thistranslates to a single JTAG operation (capture ignored, shift and updateaddress & data), there is no splitting as with the read functions.