ULX3S and IceStudio

Today I learned that IceStudio supports the ULX3S! I thought I'd first try it in WSL Ubuntu.

I'm not sure if X-Windows server is needed, but I have some notes in a prior blog post to use cygwin from WSL.

sudo apt-get update  
sudo apt-get upgrade 
sudo apt-get install nodejs
sudo apt-get install npm
node -v
cd ~/workspace/

## see https://github.com/FPGAwars/icestudio#download
##
git clone https://github.com/FPGAwars/icestudio.git
cd icestudio

## Do we need to have an X-Windows server running?
##
export DISPLAY=:0 # you may wish you put in this your ~/.bashrc
cp /mnt/c/cygwin64/home/gojimmypi/.Xauthority   ~/.Xauthority

## test X-Windows
xclock

## ensure we are on the develop branch
##
git status 

npm install
npm start

Unforunately, this left me in a state of "waiting..."

gojimmypi:~/workspace/icestudio
$ npm start

> icestudio@0.5.1 start /home/gojimmypi/workspace/icestudio
> grunt serve

Running "nggettext_compile:all" (nggettext_compile) task

Running "watch:scripts" (watch) task
Waiting...
Running "wiredep:task" (wiredep) task

Running "exec:stopNW" (exec) task

Running "exec:nw" (exec) task

Done.
Completed in 3.118s at Tue Dec 24 2019 06:57:33 GMT-0800 (PST) - Waiting...

For Windows, download the NodeJS and NPM. I did get it working, but see this icestudio GitHub issue #368. More to come...

Resources and links:

• ULX3S
• FTDI Drivers, specifically CDM v2.12.28 WHQL Certified (contains both 32 and 64 bit 
• icestudio
• nodejs
• cygwin
• WSL GUI - Using Cygwin X-Server for Graphical Interface
• Makefile gtkwave sim and xserver recipes for WSL FPGA programming
• WSL2 install (I still have WSL 1 for this blog)

REST API SOAP Payload Sniffing

Visual Studio has a tremendously helpful code generator for accessing a SOAP API without needing to worry about the transport and decoding issues. Simply right click on the project and select Add, "Connected Service".

This should bring up a tabbed window to add Connected Services. We're interested in the WCF:

Enter the URI for the SOAP interface of interest and press the Go button. If all went well, the available service(s) should be listed. Enter a namespace and click next to see additional options. For more information see the documentation: Use the WCF Web Service Reference Provider Tool.

For more details on WCF, see the github dotnet wcf repo.

This abstraction of course has a flip side: The actual data transferred is buried deep in the internals so any single-step debugging cannot "see" the raw HTML/raw XML payload. This is where Fiddler comes in to help. (yes, if you've not used Fiddler for some time, it was bought by Telerik, which was bought by Progress).

Before getting started, the netsh command will be used. It is probably a good idea to see how it is currently configured before making changes. To see the current setting, use: netsh winhttp dump

The default typically looks like this:

# -----------------------------------------
# WinHTTP Proxy Configuration
# -----------------------------------------
pushd winhttp

reset proxy

popd

# End of WinHTTP Proxy Configuration

To allow Fiddler to see the packets it needs to run in "Administrative" mode in Windows. Either right-click on the icon and select "Run as Administrator" or after searching for the app, select from the start menu:

We'll need to set a proxy to ensure all http transfers pass through Fiddler. Otherwise it just sits there idle. So yes, the command prompt needs to be running as administrator here, too. This is the command to setup the proxy:

netsh winhttp set proxy 127.0.0.1:8888

When done, return to default:

netsh winhttp reset proxy

If you don't return things to default, web browsers, Outlook, and potentially other things will misbehave, particularly when existing Fiddler. A reboot also restores the proper netsh default state.

A few notes on Fiddler:

• The `Decode` feature only decodes moving forward. If you see gzip-encoded payload, pressing the button will not decode existing captures.
  
• Only newly seen request/responses will be decoded. Press F12 or File - Capture Traffic to being sniffing. A checkbox means packet sniffing is active.
  
• Data is viewed under the Inspectors tab. I personally prefer the XML view. 

This was all related to the WCF GitHub Issue 4071 that I opened up for some problems I encountered when serializing a SOAP response in a dotnet core command line app.