JTAG from a router

This is a quick hack on a veroboard instead of a neat PCB, but here is the schematic. Three outputs (TMS, TCK, TDI) are routed to the 74HC04 for buffering. The /RESET output directly drives a pull-down NPN transistor. The 74HC04 is powered from an external Vcc taken from the target circuit, allowing the output voltage to be controlled by the target. Supplying 5V enables TMS, TCK, and others to have a full 0-5V swing; however, inputs to the wrtag will cause the 74HC04 outputs to drive the GPIOs at greater than 3.3V. To protect against this, two zener diodes clamp the Misc and TDO inputs to 3.3V. Additionally, a 50-ohm resistor is placed in series in case the input GPIOs are configured as outputs before cblsrv can reconfigure them as inputs. While this setup may appear unrefined, it functions adequately. The buffer Vcc is typically driven from the box's 3.3V output since all necessary JTAG components currently operate at 3.3V, and lower voltages would require a more sophisticated buffering solution than a 74HC04. It is advisable to consider using one of Texas Instruments' dual-supply level conversion buffers instead. This version of the AR7 features two Ethernet ports. The kernel initialized them in the incorrect order, causing eth0 to correspond to the non-functional PHY-less port, which created issues for OpenWRT. A hacky patch is provided below to disable probing one port, allowing eth0 to function correctly. The code for bit-banging the parallel port has been separated into a distinct class, which controls pins via a new GpioCtrl class. An implementation of this (in GpioCtrl_ar7.cpp) manages the AR7 GPIOs on the specified pins. It should be noted that GpioCtrl_ar7.cpp is tailored to specific wiring but can be easily modified due to defined pin numbers. Additionally, the logic sense is inverted because an inverter is used to buffer the signals. The AR7 GPIOs necessitate a read-modify-write operation to alter a pin state, as there are no dedicated SETPIN/CLEARPIN registers. There are two users of the pins: the kernel with its blinking LED infrastructure and cblsrv in userland. Although locks may seem necessary, they are not required in this case. The kernel's read-[AND, OR]-write operation in gpio_set_value() appears atomic with respect to userland, ensuring that the kernel does not return having read a pin state without writing it. Any state about to be written remains unaffected by preemption, such as the kernel flashing an LED. The kernel pin state primarily involves flashing LEDs, which is considered 'lossy.' Minor discrepancies in the Ethernet LED blink duration do not impact the user application. However, if an additional GPIO function (e.g., driving an LCD) is implemented, it must either be managed by the cblsrv binary or careful locking will be necessary between the two GPIO-utilizing tasks. The performance of the bit-banging code is surprisingly efficient; despite no optimization efforts, the cblsrv code downloads bitstreams at approximately 130 KBytes/sec. This setup is reliable and serves as a valuable piece of bench equipment. There are sufficient spare GPIOs to operate an HD44780-style character LCD, which could display the MAC address and IP address acquired from DHCP. However, this feature is somewhat superfluous, as a static IP address is typically assigned to the wrtag's MAC address. OpenOCD: A cable driver backend for OpenOCD utilizing the cblsrv protocol over TCP should enable the wrtag to function as a general-purpose JTAG debugger/ICE for ARM and other architectures.

The circuit utilizes a veroboard layout for quick prototyping, emphasizing functionality over aesthetics. The 74HC04 hex inverter is employed to buffer the JTAG signals (TMS, TCK, TDI), ensuring that the output signals maintain integrity when interfacing with the target device. The external Vcc connection allows for flexibility in voltage levels, accommodating various target circuit requirements. The inclusion of zener diodes serves as a protective measure against over-voltage conditions, safeguarding the GPIOs from damage.

The design also reflects considerations for signal integrity and proper interfacing with the AR7 microcontroller. The GpioCtrl class architecture allows for modularity and ease of modification, crucial for adapting to different hardware configurations. The read-modify-write mechanism employed for GPIO manipulation is a common approach in microcontroller interfacing, ensuring that state changes are handled effectively.

The dual Ethernet ports on the AR7 highlight the importance of proper initialization and management of hardware resources in embedded systems. The provided patch demonstrates practical solutions to common problems encountered during development. Overall, this circuit represents a practical approach to JTAG interfacing and GPIO management in embedded applications, showcasing the balance between quick prototyping and functional design.It`s a quick hack on veroboard rather than a neat PCB, but here`s the schematic. Three outputs (TMS, TCK, TDI) run to the 74HC04 for buffering. The /RESET output drives a pull-down NPN transistor directly. Note that the 74HC04 is driven from an external Vcc taken from the target circuit; this allows the output voltage to be controlled by the targe t. Supplying 5V, for example, will let TMS, TCK, etc. have a full 0-5V swing; however inputs to the wrtag will result in the 74HC04 outputs driving the GPIOs at greater than 3. 3V. To protect against this, two zener diodes clamp the Misc and TDO inputs to 3. 3V. Also, they have a 50ohm resistor in series in case the input GPIOs are configured as outputs before cblsrv can reconfigure them as inputs.

Grotty, but it works; it`s not hugely useful and I end up driving the buffer Vcc from the box`s 3. 3V out anyway ” everything I need to JTAG is currently 3. 3V and any lower will require buffering a little more exotic than a 74HC04. Consider using one of TI`s dual-supply level conversion buffers instead. There are two ethernet ports on this version of the AR7. My kernel initialised them in the wrong order, making eth0 the non-functional PHY-less one, which upset OpenWRT a little. There`s a hacky patch below to just disable probing one, so eth0 works. The code to bit-bang the parallel port has been split into a separate class, which drives pins via a new GpioCtrl class.

An implementation of this (in GpioCtrl_ar7. cpp) drives the AR7 GPIOs on the pins listed above. Note that GpioCtrl_ar7. cpp is specific to my wiring ” but the pins are #defined so are easy to change. Note also that their sense is inverted because I`m using an inverter to buffer them! The AR7 GPIOs require a read-modify-write to change a pin state, as there`re no SETPIN/CLEARPIN-type registers. There are also two users of the pins: the kernel with its blinkyLEDs (status, network) infrastructure and cblsrv in userland.

It sounds like locks are required, but none are, really. This is because: The kernel`s read-[AND, OR]-write in gpio_set_value() looks atomic w. r. t. userland in that the kernel will never return having read but not written the pin state. Any state we`re about to write does not get corrupted by being preempted and the kernel flashing an LED. But, the kernel pin state is just flashing LEDs, which is `lossy`. It doesn`t matter if the Ethernet LED blinks 1ms too little, as long as the user application isn`t affected.

If another GPIO function is added (such as driving an LCD) this will have to either be driven from the cblsrv binary or careful locking will have to occur between the two GPIO-using tasks. Great! It`s also faster than I expected for bit-bangy code; even though I`ve made no attempt to optimise the bitbang cblsrv code it downloads bitstreams really quick ” about 130KBytes/sec.

It`s reliable, too, and a nice piece of bench equipment to have around. LCD: There are enough spare GPIOs to drive an HD44780-style character LCD. This would be useful to display the MAC address and IP address obtained from DHCP. It`s more glitter than necessary though, as I just give out a static IP address for the wrtag`s MAC address. OpenOCD: A cable driver backend for OpenOCD that uses the cblsrv protocol over TCP should allow the wrtag to be useful as a general-purpose JTAG debugger/ICE for ARM, etc.

🔗 External reference