Testing – Jacob N Calvert https://jacobncalvert.com/blog-archive Mon, 15 Feb 2021 15:47:37 +0000 en-US hourly 1 https://wordpress.org/?v=6.0.17 https://jacobncalvert.com/blog-archive/wp-content/uploads/2018/02/cropped-icon-32x32.png Testing – Jacob N Calvert https://jacobncalvert.com/blog-archive 32 32 J-Pole Antennas for Ham Radio https://jacobncalvert.com/blog-archive/2021/02/08/j-pole-antennas-for-ham-radio/ https://jacobncalvert.com/blog-archive/2021/02/08/j-pole-antennas-for-ham-radio/#respond Mon, 08 Feb 2021 18:56:35 +0000 https://jacobncalvert.com/?p=759 If you’ve read any of my other posts, you know I love to build, tinker, and hack at stuff. Antenna-building is something I’ve not made a foray into, until recently. I have a dual-band handheld radio for the 2m and 70cm bands. The so-called rubber-duck antenna that comes with it performs ok but it isn’t ideal. I could get into my local repeaters which are about 10mi away with enough power to break the squelch, but my audio was weak…

The post J-Pole Antennas for Ham Radio appeared first on Jacob N Calvert.

]]> If you’ve read any of my other posts, you know I love to build, tinker, and hack at stuff. Antenna-building is something I’ve not made a foray into, until recently.

I have a dual-band handheld radio for the 2m and 70cm bands. The so-called rubber-duck antenna that comes with it performs ok but it isn’t ideal. I could get into my local repeaters which are about 10mi away with enough power to break the squelch, but my audio was weak and quality was poor. Naturally, I decided I should put up an antenna!

To Build or to Buy?

You can buy antennas on the web or at local shops like my local (and fantastic) GigaParts, however in true geeky-nerd style, I have to DIY an antenna to feel I truly understand what is going on.

Self-Education

I’ll be the first to admit, prior to starting this DIY antenna journey, I didn’t have a great understanding of how antenna theory related to an actual antenna. I understood the general 1/2 wave, 1/4 wave relation to the designed frequency of an antenna, but until digging in, I didn’t get the math behind it. I found this website to be invaluable for a plain-language (plain to someone with a bit of an engineering tilt) introduction to the core concepts and how to apply them.

What kind of antenna should I build?

This was the next question I needed to answer. My antenna only had a few real requirements, namely:

  1. Support the 2m band
  2. Support the 70cm band
  3. Be outdoor-mountable
  4. Be home-manufacturable

This list ruled out a standard di-pole, because although I have learned you can “load” a dipole to make it multi-band, I didn’t feel I had the mounting capability at present for that. I also ruled out a ladder-line j-pole, because I couldn’t find ladder-line anywhere near me. It used to be more common I suppose when OTA TV used it for their antennas, but no more. I ruled out a Yagi also, based on the complicated layout, and I didn’t necessarily want a directional antenna. After scouring the web, I settled on a standard J-pole.

J-Pole: what is it and how does it work?

If you navigate to the Wikipedia entry for J-pole antenna , you will notice there are many “form-factors,” but they all follow the similar J shape, hence the name. But looking at the typical design, I couldn’t understand how the feed point (which separated only by a short distance) doesn’t just ruin the antenna performance. Take a look at the image below, credit ZyMOS.

Typical J-Pole form-factor and feedpoint. Credit ZyMOS.

I found the most useful explanation in a YouTube video (an aside: you can anything on YT these days) which I will link.

How it works, condensed version

A little prerequisite knowledge will help the understanding of how this antenna works.

  1. The impedance in the middle of a 1/2 wave dipole is very low
  2. The impedance at the ends of a 1/2 wave dipole is very high
  3. The impedance somewhere between “very low” and “very high” is our magical 50Ω
  4. We can end-feed a 1/2 wave antenna, but the impedance is very high (as seen in item #2)

Basically, the bottom U part of the j-pole is where the feed-point is adjusted to 50Ω (or thereabouts), and at the ends the impedance is very high, which is perfect to end-feed our 1/2 wave antenna (the long part of the J). As a result of this configuration, it really doesn’t matter which “leg” of the antenna is tied to shield vs. conductor for the feed-point.

But this is still for a single band, right?

Yes, but conveniently, the “long” side of the j-pole for 70cm band is pretty darn close to the “short” side of the j-pole for the 2m band, and since it doesn’t matter which element is our “radiating” element, we can essentially reuse one of our elements. See the rough diagram below for an example of this.

Dual-band dimensions, element re-use.

Let’s Build It!

So I had armed myself with the knowledge (at least the theory) and now I just needed to create a plan. Like any good engineer, I looked around the web for any prior work in this area (no reason to reinvent the wheel!) and much to my delight, someone had posted a PDF of an easy build process for such an antenna. Following this guide, I was able to construct my first dual-band j-pole.

Tuning the antenna

This step is very important, and can be made easier by the use of SWR meters or in my case a Vector Network Analyzer. I purchased the NanoVNA (wonderful tool, works like a charm) and was able to adjust the elements of my new antenna to achieve a great SWR and feed-point impedance in the 2m band, and pretty good SWR and impedance in the 70cm band. See captures below.

2m Tuning Results

2m band SWR Sweep
2m band Feed-point Impedance Sweep

70cm Tuning Result

70cm band SWR Sweep
70cm band Feed-point Impedance Sweep

Some notes on the 70cm performance

You’ll notice the oscillatory nature of the SWR and impedance in the 70cm band. I do not completely understand this, and may return to tweak the antenna a little more. I get decent performance in several “buckets” of the 70cm band, so it’s workable, but not ideal. I have a couple of theories as to why this is, but I don’t know for sure. If any readers have some comments on this, I’d love to hear it, please comment or send me some email!

Element Diameter

The elements in the 70cm legs of the antenna are 3/8″ rod as opposed to 3/4″ EMT conduit. I suspect that the deep V around 441MHz is the center frequency for these stubs, and the antenna just has a narrow bandwidth because the elements are small. I will likely try to build another one with all 3/4″ elements to see if the antenna is improved.

Element Smoothness

I’m not sure that this has an impact or not, but the 3/8″ rod is threaded at 24-TPI and the 3/4″ elements are smooth EMT conduit. I wonder if this interplays with the skin effect?

The End Result

I mounted this antenna up on the roof, and boy-oh-boy does it work great! I am able to be heard at least 17mi away by an APRS digipeater, which was not possible with the rubber duck antenna. I can now full-quiet the local repeaters and my voice is loud and clear. Also, mounting the antenna outside has greatly reduce computer and monitor based interference, which was a pleasant surprise. All said, I’d say this was a great learning experience and fun project to boot!

Finished and mounted j-pole antenna

Thanks for reading!

The post J-Pole Antennas for Ham Radio appeared first on Jacob N Calvert.

]]> https://jacobncalvert.com/blog-archive/2021/02/08/j-pole-antennas-for-ham-radio/feed/ 0 Better JTAG on the Cheap with the FT232H https://jacobncalvert.com/blog-archive/2020/03/05/better-jtag-on-the-cheap-with-the-ft232h/ https://jacobncalvert.com/blog-archive/2020/03/05/better-jtag-on-the-cheap-with-the-ft232h/#comments Thu, 05 Mar 2020 14:45:56 +0000 https://jacobncalvert.com/?p=653 A couple of weeks ago I wrote a post about using the FTDI FT232R as a cheap JTAG debugger. I’ve been using it for a bit now to play with my Raspberry Pi 3B, and now that my code size has grown, the FT232R is just too slow to cut it. Here’s a breakdown: on the FT232R, the max speed I can set the adapter to is 3MHz. This has given me a transfer speed (loading via GDB) of around…

The post Better JTAG on the Cheap with the FT232H appeared first on Jacob N Calvert.

]]> A couple of weeks ago I wrote a post about using the FTDI FT232R as a cheap JTAG debugger. I’ve been using it for a bit now to play with my Raspberry Pi 3B, and now that my code size has grown, the FT232R is just too slow to cut it.

Here’s a breakdown: on the FT232R, the max speed I can set the adapter to is 3MHz. This has given me a transfer speed (loading via GDB) of around 3KB/s. Not too bad for small projects of only a few hundred KiB. But now my code size is approaching a ~5 MiB, the debug cycle was way too long… 5MiB @ 3KB/s = ~28mins to load… not good!

Still in my pursuit of a cheap JTAG debugger (I mean come on! It’s just a serial protocol!), I did buy something. The Adafruit FT232H breakout is exactly what I was looking for. At only $15 with Amazon Prime shipping, I was back to debugging at a reasonable speed in two days.

The FT232H breakout is about as barebones as it gets. The board breaks out untouched ACBUS0-ACBUS7 and ADBUS0-ADBUS7 to 0.10″ pitch headers. Since the FT232H has a single MPSSE channel, I can use this breakout to get faster JTAG speeds.

My configuration files from the previous post had to change a little to accommodate. I’ll break it down below in comments in the file because it’s a little bit cryptic. 

#
# FTDI USB Hi-Speed to MPSSE Breakout from Adafruit
#
# This should work for any bare FT232H
#

# Setup driver type
adapter driver ftdi

# 30000 kHZ -> 30MHz
adapter speed 30000

# Using JTAG (also could be SWD)
transport select jtag

# Common PID for FT232H
ftdi_vid_pid 0x0403 0x6014

# Set sampling to allow higher clock speed
ftdi_tdo_sample_edge falling


# Layout
# On this breakout, the LEDs are on ACBUS8 and ACBUS9, can't assign them
# registers are <ACVALUE><ADVALUE> <ACCONFIG><ADCONFIG>
# so we set 0x0308 to mean only ACBUS nTRST and nSRST, ADBUS3 (TMS) asserted high
# and we set 0x000B to mean only AC3,AC2,AC0 outputs -> (TMS,TD0, TCK)
ftdi_layout_init 0x0308 0x000b

# Pins
# pin name      | func. |
# --------------|-------|
# ADBUS0        | TCK   |
# ADBUS1        | TDI   |
# ADBUS2        | TDO   |
# ADBUS3        | TMS   |
# ACBUS0        | nTRST |
# ACBUS1        | nSRST |
#---------------|-------|

# When data == oe -> pins are switched from output to input to give
# the tri state (L, H, Hi-Z) effect 
ftdi_layout_signal nTRST -data 0x0100 -oe 0x0100
ftdi_layout_signal nSRST -data 0x0200 -oe 0x0200

So now it is as simple as connecting the corresponding pins on this breakout to the RPi3, and running OpenOCD again.

With the increased throughput of this MPSSE-supported interface, I now get ~587KB/s. Much better! It only takes ~8s to load my image now.

The post Better JTAG on the Cheap with the FT232H appeared first on Jacob N Calvert.

]]> https://jacobncalvert.com/blog-archive/2020/03/05/better-jtag-on-the-cheap-with-the-ft232h/feed/ 1 JTAG On the Cheap with the FTDI FT232R https://jacobncalvert.com/blog-archive/2020/02/04/jtag-on-the-cheap-with-the-ftdi-ft232r/ https://jacobncalvert.com/blog-archive/2020/02/04/jtag-on-the-cheap-with-the-ftdi-ft232r/#comments Tue, 04 Feb 2020 21:59:47 +0000 https://jacobncalvert.com/?p=620 JTAG 101 What is it? JTAG stands for the Joint Test Action Group, and the TAP or Test Access Port this group defined is one of the most (if not the most) common way to program and debug embedded devices and computers of all flavors. For the professional, JTAG devices are bountiful and usually not too much of a strain on the commercial budget. But for the hobbyist, things aren’t so peachy. A Segger J-Link EDU can be had for…

The post JTAG On the Cheap with the FTDI FT232R appeared first on Jacob N Calvert.

]]> JTAG 101

What is it?

JTAG stands for the Joint Test Action Group, and the TAP or Test Access Port this group defined is one of the most (if not the most) common way to program and debug embedded devices and computers of all flavors. For the professional, JTAG devices are bountiful and usually not too much of a strain on the commercial budget. But for the hobbyist, things aren’t so peachy. A Segger J-Link EDU can be had for ~$70 USD shipped, but the full featured J-Link is still ~$400, which is more than I want to pay as a hobbyist.

What does it do?

The JTAG TAP port consists of a few standard signals which essentially give you complete control over the systems in the JTAG chain. The chain is exactly what it sounds like: multiple devices which support JTAG chaining can be chained up and accessed from a single JTAG port. Need that flash programmed? JTAG can do that. Need to debug that microcontroller? JTAG can do that too. Want to do both without switching out tools? Yep, JTAG can do it. See this helpful diagram at Wikipedia for a visual representation.

JTAG for the Hobbyist

Chances are that you’ve got an USB -> Serial cable or breakout board lying around somewhere in your hoard. Chances are also, that it’s based on the wildly popular FTDI FT232R or a similar FT232-esque chip which converts USB to RS232. If you’re lucky enough to have this essential piece of hobbyist equipment, you’ve got a USB->JTAG adapter waiting to be unlocked!

Enter OpenOCD

OpenOCD (Open On-chip Debugger) is a fantastic project which aims to create an open and extensible OCD solution for all, and lucky for us, this includes the hobbyist! The OpenOCD project defines interfaces between the common parts of the OCD process, such as the target board or device, the OCD device used, etc., and using these well-defined interfaces is able to create a modular system which can support many different targets and debuggers with only a configuration change. This is a simplification of how this works, but it is sufficient to understand what we want to do with it.

So back to the FT232R. This little chip can be re-configured to use the RS232 signals as bit-banged JTAG signals, and OpenOCD can drive it. Even better, once the OpenOCD agent is up and running, we can then use GDB to connect to and drive our debug efforts. This mode of operation is detailed over at their documentation site (hint: search for ft232r).

The OpenOCD tool can usually be installed with your package manager on Linux. I’m running Linux Mint, so I apt install’d openocd. When I ran the tool pointing to the ft232r config file, it complained that it was not a supported interface… so I guess we’ll build from source!

Building OpenOCD with the Right Interfaces

All we need to do is build OpenOCD from source with the right interfaces enabled and we can make it work. What follows next is my step-by-step on doing this. I’m doing this in /tmp just so I can recreate the steps I did earlier in my apps directory.

Grab the Source

Go get the source from the GitHub mirror here and drop it in a working directory. I would also read the README for any dependencies you didn’t have already on your machine.

jacob@jacob-aspire-mint:/tmp$ git clone https://github.com/ntfreak/openocd.git
Cloning into 'openocd'...
remote: Enumerating objects: 74, done.
remote: Counting objects: 100% (74/74), done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 62845 (delta 36), reused 50 (delta 21), pack-reused 62771
Receiving objects: 100% (62845/62845), 24.17 MiB | 24.90 MiB/s, done.
Resolving deltas: 100% (51571/51571), done.
jacob@jacob-aspire-mint:/tmp$

Run the bootstrapper

This little piece of code essentially checks that your build environment is sane and you have all the tools needed to build OpenOCD. Output is below, you should come away with no errors. 

jacob@jacob-aspire-mint:/tmp/openocd$ ./bootstrap 
+ aclocal
+ libtoolize --automake --copy
+ autoconf
+ autoheader
+ automake --gnu --add-missing --copy
configure.ac:26: installing './compile'
configure.ac:37: installing './config.guess'
configure.ac:37: installing './config.sub'
configure.ac:16: installing './install-sh'
configure.ac:16: installing './missing'
Makefile.am:46: warning: wildcard $(srcdir: non-POSIX variable name
Makefile.am:46: (probably a GNU make extension)
Makefile.am: installing './INSTALL'
Makefile.am: installing './depcomp'
Makefile.am:23: installing './mdate-sh'
Makefile.am:23: installing './texinfo.tex'
Setting up submodules
Submodule 'jimtcl' (http://repo.or.cz/r/jimtcl.git) registered for path 'jimtcl'
Submodule 'src/jtag/drivers/libjaylink' (http://repo.or.cz/r/libjaylink.git) registered for path 'src/jtag/drivers/libjaylink'
Submodule 'tools/git2cl' (http://repo.or.cz/r/git2cl.git) registered for path 'tools/git2cl'
Cloning into '/tmp/openocd/jimtcl'...
warning: redirecting to https://repo.or.cz/r/jimtcl.git/
Cloning into '/tmp/openocd/src/jtag/drivers/libjaylink'...
warning: redirecting to https://repo.or.cz/r/libjaylink.git/
Cloning into '/tmp/openocd/tools/git2cl'...
warning: redirecting to https://repo.or.cz/r/git2cl.git/
Submodule path 'jimtcl': checked out 'a9bf5975fd0f89974d689a2d9ebd0873c8d64787'
Submodule path 'src/jtag/drivers/libjaylink': checked out 'f73ad5e667ae8b26a52b847c603fdadaabf302a6'
Submodule path 'tools/git2cl': checked out '8373c9f74993e218a08819cbcdbab3f3564bbeba'
Generating build system...
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/config.guess'
libtoolize: copying file 'build-aux/config.sub'
libtoolize: copying file 'build-aux/install-sh'
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:42: installing 'build-aux/ar-lib'
configure.ac:37: installing 'build-aux/compile'
configure.ac:30: installing 'build-aux/missing'
Makefile.am: installing './INSTALL'
libjaylink/Makefile.am: installing 'build-aux/depcomp'
Bootstrap complete. Quick build instructions:
./configure ....
jacob@jacob-aspire-mint:/tmp/openocd$

Run the configure script

This is where we determine that we want the FTDI FT232R to be supported. We do this by adding a flag to the configure line. Output is cut short in the middle because it’s quite long, but the important part is at the end.

jacob@jacob-aspire-mint:/tmp/openocd$ ./configure --enable-ft232r 
checking for makeinfo... no
configure: WARNING: Info documentation will not be built.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk

[ ... snip ... ]

libjaylink configuration summary:
 - Package version ................ 0.2.0-git-f73ad5e
 - Library version ................ 0:0:0
 - Installation prefix ............ /usr/local
 - Building on .................... x86_64-pc-linux-gnu
 - Building for ................... x86_64-pc-linux-gnu

Enabled transports:
 - USB ............................ yes
 - TCP ............................ yes



OpenOCD configuration summary
--------------------------------------------------
MPSSE mode of FTDI based devices        yes (auto)
ST-Link Programmer                      yes (auto)
TI ICDI JTAG Programmer                 yes (auto)
Keil ULINK JTAG Programmer              yes (auto)
Altera USB-Blaster II Compatible        yes (auto)
Bitbang mode of FT232R based devices    yes
Versaloon-Link JTAG Programmer          yes (auto)
TI XDS110 Debug Probe                   yes (auto)
OSBDM (JTAG only) Programmer            yes (auto)
eStick/opendous JTAG Programmer         yes (auto)
Andes JTAG Programmer                   yes (auto)
USBProg JTAG Programmer                 no
Raisonance RLink JTAG Programmer        no
Olimex ARM-JTAG-EW Programmer           no
CMSIS-DAP Compliant Debugger            no
Cypress KitProg Programmer              no
Altera USB-Blaster Compatible           no
ASIX Presto Adapter                     no
OpenJTAG Adapter                        no
SEGGER J-Link Programmer                yes (auto)

Build it

Finally, we build it. Again, I’m snipping the output down to size, but you should end up with an executable binary in src/ called openocd. This final step doesn’t take long (on my machine only about 45s). 

jacob@jacob-aspire-mint:/tmp/openocd$ make
Makefile:4634: warning: overriding recipe for target 'check-recursive'
Makefile:4045: warning: ignoring old recipe for target 'check-recursive'
cat src/helper/startup.tcl src/jtag/startup.tcl src/target/startup.tcl src/server/startup.tcl src/flash/startup.tcl | ./src/helper/bin2char.sh > src/startup_tcl.inc || { rm -f src/startup_tcl.inc; false; }
cp src/jtag/drivers/minidriver_imp.h src/jtag/minidriver_imp.h
make  all-recursive
make[1]: Entering directory '/tmp/openocd'
Makefile:4634: warning: overriding recipe for target 'check-recursive'
Makefile:4045: warning: ignoring old recipe for target 'check-recursive'
Making all in jimtcl
make[2]: Entering directory '/tmp/openocd/jimtcl'


[ ... snip ... ]

libtool: link: ranlib src/.libs/libopenocd.a
libtool: link: rm -fr src/.libs/libopenocd.lax src/.libs/libopenocd.lax
libtool: link: ( cd "src/.libs" && rm -f "libopenocd.la" && ln -s "../libopenocd.la" "libopenocd.la" )
depbase=`echo src/main.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I.   -I./src -I./src -I./src/helper -DPKGDATADIR=\"/usr/local/share/openocd\" -DBINDIR=\"/usr/local/bin\" -I./jimtcl -I./jimtcl  -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -g -O2 -MT src/main.o -MD -MP -MF $depbase.Tpo -c -o src/main.o src/main.c &&\
mv -f $depbase.Tpo $depbase.Po
/bin/bash ./libtool  --tag=CC   --mode=link gcc -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -g -O2   -o src/openocd src/main.o src/libopenocd.la  ./jimtcl/libjim.a  -ldl 
libtool: link: gcc -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -g -O2 -o src/openocd src/main.o  src/.libs/libopenocd.a -lusb-1.0 -lm ./jimtcl/libjim.a -ldl
make[2]: Leaving directory '/tmp/openocd'
make[1]: Leaving directory '/tmp/openocd'

Testing OpenOCD

Now that we have a binary, we need to test it out and see if it works. My target for today is a Raspberry Pi 3 B. We first need to gather some info about our target, i.e., the Raspberry Pi 3. We need to know which pins on the GPIO header correspond to which JTAG signals.

First let’s grab the BCM2835 pinout reference. (Side note: we use the BCM2835 reference because there is no BCM2837 reference, and it seems the pinouts are roughly the same.) This will tell us what each GPIO pin does. Some of the GPIOs are only designated for one singular function, whereas many other GPIOs are multi-function, and their function is software programmable. These alternate functions are designated ALT on the reference material. I used the reference over at e-Linux because I find the table easy to read. Searching the table, we find the JTAG signals we’re interested in (TRST, TCK, TMS, TDI, TDO) are assigned in the range of GPIOs 22-27 for the ALT4 function. Next we want to pull up the schematic of our Raspberry Pi 3 B, and see what each of those map to on the GPIO header. I’ve created the table below to keep things straight.

JTAG SignalBCM283x GPIO #Raspberry Pi 3B J8 Pin #
TRSTGPIO22P15
TCKGPIO25P22
TMSGPIO27P13
TDIGPIO26P37
TDOGPIO24P18
GNDmanyP6

Once we’ve got these figured out we’ve got to prep the Pi for JTAG usage. This is the simplest part in the whole setup. On the Pi’s SD card, add the following line to the config.txt. 

enable_jtag_gpio=1

Finally, we’re ready to hook up our JTAG debugger. Looking in the documentation for the OpenOCD FT232R configuration, we find the following table which shows us which RS232 signals correspond to which JTAG signals. We need to (powered down of course!) hook up our FT232R module/cable and Pi accordingly, and don’t forget the ground wire!


    - RXD(5) - TDI
    - TXD(1) - TCK
    - RTS(3) - TDO
    - CTS(11) - TMS
    - DTR(2) - TRST
    - DCD(10) - SRST

Once things are hooked up, we need to setup our configuration for the OpenOCD tool. The default config from the ft232r.cfg is sufficient for the interface, but I wanted to add one item and to get us debugging we need to tell OpenOCD how to connect to the Pi and its four cores. I’ve based my rpi3b.cfg config off of a fellow GitHub contributor’s config but made some modifications.

ft232r.cfg

adapter driver ft232r
adapter speed 3000
ft232r_restore_serial 0x15

I modified the ft232r.cfg to increase the adapter speed to 3M (3000 kHz) and to restore the port config when OpenOCD is done so the adapter can be used as a serial device again.

rpi3b.cfg

transport select jtag

adapter speed 3000

reset_config trst_and_srst

jtag_ntrst_delay 500

if { [info exists CHIPNAME] } {
  set _CHIPNAME $CHIPNAME
} else {
  set _CHIPNAME rpi3
}

if { [info exists DAP_TAPID] } {
   set _DAP_TAPID $DAP_TAPID
} else {
   set _DAP_TAPID 0x4ba00477
}

jtag newtap $_CHIPNAME tap -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_DAP_TAPID -enable
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.tap

set _TARGETNAME $_CHIPNAME.a53
set _CTINAME $_CHIPNAME.cti

set DBGBASE {0x80010000 0x80012000 0x80014000 0x80016000}
set CTIBASE {0x80018000 0x80019000 0x8001a000 0x8001b000}
set _cores 4

for { set _core 0 } { $_core < $_cores } { incr _core } {

    cti create $_CTINAME.$_core -dap $_CHIPNAME.dap -ap-num 0 \
        -ctibase [lindex $CTIBASE $_core]

    target create $_TARGETNAME.$_core aarch64 \
        -dap $_CHIPNAME.dap -coreid $_core \
        -dbgbase [lindex $DBGBASE $_core] -cti $_CTINAME.$_core

    $_TARGETNAME.$_core configure -event reset-assert-post "aarch64 dbginit"
}

Putting it All Together

Now we have all the pieces we need to debug using our JTAG adapter. Let’s begin!

jacob@jacob-aspire-mint:/opt/apps/openocd$ sudo ./src/openocd -f ./ft232r.cfg -f ./rpi3b.cfg 
Open On-Chip Debugger 0.10.0+dev-01047-g09ac9ab1 (2020-02-04-09:11)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
FT232R restore serial: 0x0015 (enabled)

Warn : Transport "jtag" was already selected
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 3000 kHz
Info : JTAG tap: rpi3.tap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : rpi3.a53.0: hardware has 6 breakpoints, 4 watchpoints
Info : rpi3.a53.1: hardware has 6 breakpoints, 4 watchpoints
Info : rpi3.a53.2: hardware has 6 breakpoints, 4 watchpoints
Info : rpi3.a53.3: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Listening on port 3334 for gdb connections
Info : Listening on port 3335 for gdb connections
Info : Listening on port 3336 for gdb connections

Now we’re cooking! You can connect GDB up to each core, debug that way, or use the OpenOCD interface, see below:

OpenOCD Interface

acob@jacob-aspire-mint:/tmp/openocd$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
rpi3.a53.3 cluster 0 core 3 multi core
target halted in AArch64 state due to debug-request, current mode: EL3H
cpsr: 0x000003cd pc: 0x20001c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> targets
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0  rpi3.a53.0         aarch64    little rpi3.tap           running
 1  rpi3.a53.1         aarch64    little rpi3.tap           running
 2  rpi3.a53.2         aarch64    little rpi3.tap           running
 3* rpi3.a53.3         aarch64    little rpi3.tap           halted

> reg
===== Aarch64 registers
(0) x0 (/64): 0x0000000000000003 (dirty)
(1) x1 (/64): 0x00000000C1000000
(2) x2 (/64)
(3) x3 (/64)
(4) x4 (/64)
(5) x5 (/64)
(6) x6 (/64)
(7) x7 (/64)
(8) x8 (/64)

[ ... snip ... ]

GDB Interface

jacob@jacob-aspire-mint:/tmp/openocd$ aarch64-none-elf-gdb
GNU gdb (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 8.3.0.20190709-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=aarch64-none-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.linaro.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote :3333
Remote debugging using :3333
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0000000000200028 in ?? ()
(gdb) si
0x000000000020002c in ?? ()
(gdb) si
0x0000000000200074 in ?? ()
(gdb) si
0x0000000000200078 in ?? ()
(gdb)

Wrapping Up

Now we have a JTAG solution that can debug many, many flavors of processors and microcontrollers given the right configuration. It becomes even more useful if your FT232R module supports selecting the logic level voltage like mine does. See below for some pros and cons of this approach.

Pros

This is a quick and dirty way to get a JTAG adapter at no cost if you’ve already got these FTDI chips laying around. It’s quick and fully configurable (check out the OpenOCD config pages for all it can do) and makes a great debugger.

Cons

Since we are bit-banging our way to success here, it is a bit on the slow side. It’s not unusable, but it is slower than a native interface. If you don’t have one of these chips already at your disposal, I’d opt for one of the FT232H or better yet the FT2232H, both of which have an MPSSE engine which greatly improves emulation.

The post JTAG On the Cheap with the FTDI FT232R appeared first on Jacob N Calvert.

]]> https://jacobncalvert.com/blog-archive/2020/02/04/jtag-on-the-cheap-with-the-ftdi-ft232r/feed/ 8 Network bandwidth testing with iperf3 https://jacobncalvert.com/blog-archive/2018/02/10/network-bandwidth-testing-with-iperf3/ https://jacobncalvert.com/blog-archive/2018/02/10/network-bandwidth-testing-with-iperf3/#respond Sun, 11 Feb 2018 00:01:13 +0000 http://jacobncalvert.com/?p=185 Everyone knows how to use speedtest.net to test your internet connection speed, but how do you test your LAN bandwidth?   When you want to troubleshoot speed issues on your LAN, what can you use? Luckily, some clever software call iperf3 can help us out.  You can find the tool at the main website for iperf and iperf3  here. This tool is available for Windows, Linux, Mac, Android, and iOS, so you’ve got options. There are two parts to testing your network with iperf3. First…

The post Network bandwidth testing with iperf3 appeared first on Jacob N Calvert.

]]> Everyone knows how to use speedtest.net to test your internet connection speed, but how do you test your LAN bandwidth?

 

When you want to troubleshoot speed issues on your LAN, what can you use? Luckily, some clever software call iperf3 can help us out.  You can find the tool at the main website for iperf and iperf3  here. This tool is available for Windows, Linux, Mac, Android, and iOS, so you’ve got options.

There are two parts to testing your network with iperf3. First you need to set up the server. The server will listen on a particular port for client connections and will host a “control” connection with a client once the test begins. In today’s example, I will be testing the network between my laptop and my router (the Linux box I built in the previous series BYORpt1 and BYORpt2).

I’ll be using the Linux router as the server and my laptop as the client. Later I’ll show an option which will reverse the directions of traffic flow without any extra work.

Setting up the Server

root@calvert-home:/home/jacob# iperf3 -s -p 8384
-----------------------------------------------------------
Server listening on 8384
-----------------------------------------------------------

These commands instruct iperf3 to act as (s)erver on (p)ort 8384. That’s it for the basic tests.

Setting up the Client

jacob@jacob-laptop ~ $ iperf3 -c 172.16.0.1 -p 8384

Once you execute this command, testing will begin. The default parameters will run the test as fast as possible for 10 seconds.

Your output will look something like:

Connecting to host 172.16.0.1, port 8384
[ 4] local 172.16.2.21 port 35950 connected to 172.16.0.1 port 8384
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.94 MBytes 41.4 Mbits/sec 0 311 KBytes 
[ 4] 1.00-2.00 sec 5.22 MBytes 43.8 Mbits/sec 0 553 KBytes 
[ 4] 2.00-3.00 sec 4.81 MBytes 40.3 Mbits/sec 0 803 KBytes 
[ 4] 3.00-4.00 sec 5.06 MBytes 42.4 Mbits/sec 0 1.03 MBytes 
[ 4] 4.00-5.00 sec 5.05 MBytes 42.4 Mbits/sec 0 1.22 MBytes 
[ 4] 5.00-6.00 sec 5.08 MBytes 42.6 Mbits/sec 0 1.24 MBytes 
[ 4] 6.00-7.00 sec 5.02 MBytes 42.1 Mbits/sec 0 1.24 MBytes 
[ 4] 7.00-8.00 sec 5.06 MBytes 42.5 Mbits/sec 0 1.24 MBytes 
[ 4] 8.00-9.00 sec 5.56 MBytes 46.7 Mbits/sec 0 1.24 MBytes 
[ 4] 9.00-10.00 sec 4.59 MBytes 38.5 Mbits/sec 0 1.24 MBytes 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 50.4 MBytes 42.3 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 50.4 MBytes 42.3 Mbits/sec receiver

Notice, I have pretty bad performance for a GbE capable machine. Unfortunately, I have to link up to the switch through a PowerLine adapter, which causes some slowdown.

Reversing the Direction

To reverse the direction of “server” and “client” responsibilities, we simply append the flag -R

Output on the Server Side

On the server side you will also see output that should mirror your client.

-----------------------------------------------------------
Server listening on 8384
-----------------------------------------------------------
Accepted connection from 172.16.2.21, port 35948
[ 5] local 172.16.0.1 port 8384 connected to 172.16.2.21 port 35950
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 4.30 MBytes 36.1 Mbits/sec 
[ 5] 1.00-2.00 sec 4.73 MBytes 39.6 Mbits/sec 
[ 5] 2.00-3.00 sec 4.86 MBytes 40.8 Mbits/sec 
[ 5] 3.00-4.00 sec 5.04 MBytes 42.3 Mbits/sec 
[ 5] 4.00-5.00 sec 5.06 MBytes 42.4 Mbits/sec 
[ 5] 5.00-6.00 sec 4.96 MBytes 41.6 Mbits/sec 
[ 5] 6.00-7.00 sec 5.06 MBytes 42.4 Mbits/sec 
[ 5] 7.00-8.00 sec 5.08 MBytes 42.6 Mbits/sec 
[ 5] 8.00-9.00 sec 5.26 MBytes 44.2 Mbits/sec 
[ 5] 9.00-10.00 sec 4.95 MBytes 41.6 Mbits/sec 
[ 5] 10.00-10.21 sec 1.08 MBytes 44.3 Mbits/sec 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-10.21 sec 50.4 MBytes 41.4 Mbits/sec 0 sender
[ 5] 0.00-10.21 sec 50.4 MBytes 41.4 Mbits/sec receiver

Going Further

iperf3 supports multiple processes (but not multiple threads!! beware!!) with the -P option. That can have some interesting results.

Thanks for reading!

The post Network bandwidth testing with iperf3 appeared first on Jacob N Calvert.

]]> https://jacobncalvert.com/blog-archive/2018/02/10/network-bandwidth-testing-with-iperf3/feed/ 0