OsháBlue: Web Log and B-Sides

Env Specs: ubuntu (lsb_release -a: 16.04.5 LTS / xenial as VMWare Fusion 10.1.2 virtual machine on Mac OS X Mojave 10.14.2), urjtag (2018.09 from sourceforge, just use tar -xf urjtag-201809.tar.xz btw), ISE webpack (14.7 sustaining phase only of software life cycle btw), libftdi installed, not ftd2x

Sketched up quick notes about testing out a CPLD solution to merge several blocks of logic (*595’s, *597’s) in a recent rapid prototype concept eval/demo project, using some open hardware maker boards we already had, but hadn’t tested yet. Heavy emphasis on testing hardware, tools, and resources from Dangerous Prototypes (DP). As of this writing, the XC9572XL (Plan A) and related family are a bit old, as are the hardware and resources referenced in here, but still a valid path for our purposes because the Plan A chip is still available, not EOL, and fully capable of handling the minimal amount of logic integration we need. It is 5V tolerant, and can run from a 3.3V rail, which are both important points in minimizing complexity for our needs on this project.

After building up a tool chain, we found (so far) that the XC9752XL wouldn’t work reliably in this tool chain (issue with playing the .svf file into the chip via urjtag), although it is still a preferred chip for the reasons noted above. An unanswered forum post from a few years ago at urjtag’s discussion page (from Ian of DP no less) seems to confirm the same. Several attempts at work-arounds and several verifications (including using a driver from git.zerfleddert.de for direct connection from within ISE) led to the next point, moving along (to maintain some schedule and agility here)…

So, in the spirit of “moving along…” and leveraging the momentum we already had in the tool chain, we swapped the XC9752XL for the XC2C62A (Xilinx CoolRunner II) mini dev board and poof, good to go. Almost poof (in a good way, poof, not like poof up in smoke) anyway – a few more steps to pull some samples files and also to retarget some ISE schematics and chip pin constraint files (.ucf) and then regenerate the svf, and a successful playback/upload to the Plan B CPLD.

Summary and notes of some steps below. This is not intended to be an exhausting tutorial — those resources are out there (see links at the bottom). Just some specific notes here that were relevant.

Step 1. Build urjtag and test connection to the BB

Little gotchas and work-arounds:

Compiling urjtag:
issue with unrecognized mprf_z_sub during 
:./configure
: due to library paths left over from the ISE webpack install.  Solution 
:unset LD_LIBRARY_PATH
 --- wants python2.7, so 
:sudo apt-get install python-dev (for python.h header requested during make) --- after sudo make install 
run :sudo ldconfig so (ur)jtag sees a library it needs --- then 
run :jtag to test --- run lsusb to verify connected device and PID and VID --- 
issue with Error: Illegal State: Fewer bytes written than requested --- something glitchy --- in one case unplugging/replugging the USB device(s) and restarting jtag worked while in another (old school) restarting the OS worked --- haven't looked into root cause yet --- moving along ...

:jtag  
jtag>cable ft2232 pid=0x6010 vid=0x0403 interface=1 # this is the FTDI JTAG B port
jtag>Connected to libftdi driver.
# interface 1 is the Bus Blaster 2.5's on-board CPLD while interface 0 goes to any connected JTAG device, once that is set up
jtag>detect
# Now we get correct output from the detect command, indicating the on-board xc2c32a-vq44 and yes now urjtag includes the definition for this chip as shown in an entry for the Filename
# Prior an executable, without building, we were getting crash after detect command for the interface 1, even though we were trying to add the bsdl file to the path for the urjtag
# Notice that on detect for interface=0, we get: warning: TDO seems to be stuck at 1 ... that is because we need to tell urjtag to load the jtagkey driver role when talking to the other chip (the 2nd channel on the ftdi), so the command is:
jtag>cable jtagkey pid=0x6010 vid=0x0403 interface=0 
# The "jtagkey" is now important here so that urjtag properly talks JTAG to the target on the mini dev satellite board
# This is really after the next step ... but called out here to differentiate calling cable ft2232... versus calling cable jtagkey...

Step 2. Download JTAG tool emulation buffer code into the on-board CPLD

# github => for emulating a JTAGkey could try one of the BBv2-JTAGkey svf files --- 
:cp BBv2-JTAGkey-v1.4-VHDL.svf ~/CPLD-Testing/bbv2.svf
:sudo jtag
jtag>cable ft2232 (etc) interface=1 #on-board
jtag>detect
jtag>svf /path/to/file/bbv2.svf stop progress
# So, what we're doing here is: Using the FTDI JTAG B (interface=1) port to talk JTAG to the CPLD on the BB itself, and then programming that CPLD to act like a jtagkey type of JTAG programmer/debugger and talk to a target chip connected to its target 2x10 header.  So software talking to the FTDI JTAG A (interface=0) port now thinks it's talking to a jtagkey and can program use target device via JTAG.

Step 3. Test Connection to the Attached Target Mini Satellite XC9572XL Dev Board

:jtag
jtag>cable jtagkey pid=0x6010 vid=0x0403 interface=0
jtag>detect
# Initially we get a notice that the stepping is not known and so no Filename is selected
jtag>quit

# So we edit the STEPPINGS file because the stepping here (0101) is actually not yet included in the STEPPINGS file that maps the stepping in the model number to a device
:sudo nano /usr/local/share/urjtag/xilinx/xc9572xl/STEPPINGS
# add to the file:
0101   xc9572xl_vq44   5
# and save because this is the vq44 package

:jtag
jtag> (redo the cable and detect commands above)
# Now we see the correct file selected for this device for bdsl

Step 4: Load something onto the target (XC9572XL) CPLD!

# We had compiled and exported an svf before from ISE webpack
# It's called: led1.svf
jtag> (already did cable and detect commands for the target)
jtag> svf outfile.svf stop progress 
# error regarding one of the SDR (serial data read) commands early in the SVF file -- something not working reading back correctly 
# same with a prepared tutorial file svf content
# not the same directly from within ISE (things got muddy and inconsistent and glitchy quickly... but we were able to program from within ISE using the open source driver from zerfleddert... and yadayada)
# much digging, trying, testing ... moving along ...

Step 4B: Err… Try a new XC2C64A (CoolRunner II) target CPLD!

jtag> (already did cable and detect commands for the target = using jtagkey and interface=0)
jtag> svf outfile.svf stop progress
jtag><paraphrase>everything matches, good playback/programming</paraphrase>

Issues and Debugging

Re-writing/overwriting .svf files from iMPACT and doesn't look like new code is getting uploaded to the target - rather same code as prior?  Try: iMPACT=> Output => Stop writing to SVF file (this seems to have worked to allow urjtag to grab the new file and send this to the target ... whereas before, despite writing the new file in iMPACT, the behavior of the target seemed the same.

Resources:

See wrong stuff? Errors? Drop a line. Please overlook typos etc. in these quick snapshot sketch types of posts..

sudo apt-get install motion

sudo nano /etc/motion/motion.conf

ctrl-v until you get to the end of the file and uncomment the first two threads for the file locations for the configs files for the 2 cams (thread1 and thread2)

create the corresponding two files both in the same /etc/motion/ directory:

sudo touch thread1.conf && sudo nano thread1.conf

and do the same for thread2.conf. The contents are as follows:

#thread1.conf:
videodevice /dev/video0
target_dir /user/me/video0files
stream_port 8081 # may be optional - seems necessary for reliability

#thread2.conf:
videodevice /dev/video1
target_dir /user/me/video1files
stream_port 8082 # may be optional - seems necessary for reliability

sudo motion # double-check the need for sudo there ...

view the output (via VNC in this case) at:

localhost:8080 # the control interface for motion, including the option to action=>restart

localhost:8081 # the video feed from video0 / thread1

localhost:8082 # the video feed from video1 / thread2

To allow access from a non-localhost different computer, for the web control interface and the video streams, respectively, set:

webcontrol_localhost off
stream_localhost off

CAUTION: Be sure you really want this access allowed from a non-localhost computer. You may want to look into authentication from here to allow access from another PC, and/or you may want to configure firewalls and/or VLANs to restrict access to the control and video streams.

After making config changes, it seems so far most reliable, as one simple UI option, to select action => restart from the web control interface.

This relies on the defaults, assumes your cameras are compatible with Linux/motion default settings, assumes that your two cameras enumerate as video0 and video1, and was tested on a headless Intel iNUC (circa 2016) running Ubuntu 16.04.5 LTS or thereabouts (which is old, and retained for legacy comms project compatibility and reference). Motion version is 3.2.12

For an older slower headless fanless mini-ITX system, running 3 cameras required using a kernel driver documented “hack” (really just a setting — see the uvcvideo documentation) and/or rebuilding the driver to mod bandwidth output data to guarantee 3 cameras continuous running when bandwidth data wasn’t correct, and or something like that … a while ago … haven’t tested on this iNUC platform.

Update: For Motion on Ubuntu 18.04.1 (and what a nice rev I must say) the mutiple camera/thread naming convention has been updated to:

camera /etc/motion/camera1.conf

camera /etc/motion/camera2.conf

instead of the former:

thread yada yada # (the filename itself doesn't matter, but the directive is different)

References

https://motion-project.github.io/motion_config.html

OsháBlue: Web Log and B-Sides

ubuntu, urjtag, ISE webpack, Bus Blaster v2.5 (BB), XC9572XL, oops I mean XC2C64A (CoolRunner II) mini dev board

Motion Setup for Two (2) USB Cameras on Linux – Super Quick and Simple Basics – Rapid Testing Sketch

References

tech and people, er… swap that order.

Maker Land / B-Sides / Web-Log