SUMP2 Troubleshoot

o FPGA doesn't configure when plugged in. No solid green, only faint 4 reds.
  This indicates the FPGA did not configure. Assuming the PROM is already 
  properly configured with the sump2 firmware, quickly unplug and replug the 
  iCEstick into the USB port. The 2nd insertion seems to always work. I suspect
  an inrush current issue with the iCEstick board design. Possibly the FPGA 
  configuration begins prior to the boards bypass caps being fully charged.

o bd_server.py fails to connect to correct COM port.
  With bd_server.ini line "usb_port=AUTO", the application will try to connect 
  with 1st FTDI VCP it finds. Chances are either there isn't a valid VCP for "B"
  port of the FT2232H chip, or there are multiple VCPs that have been located
  and the 1st one bd_server found wasn't the right one. The most reliable way
  to use bd_server.py is to modify bd_server.ini and manually specify the COM#
  that you know the iCEstick "Converter B" VCP is assigned to. This can be 
  found manually on Win7 under [Start],[Devices and Printers].

o "Converter B" was previously VCP enabled and now it is not.
  This is a very annoying FTDI device driver feature. The VCP only stays 
  enabled if the same USB host port is used. Example, if you have a USB Hub and
  switch the iCEstick to a different slot in the hub, your VCP settings will be
  lost. There are two potential long term solutions to this issue:
  1) Use FTDI's FT_PROG utility to always enable VCP on "B" of the FT2232H.
  2) Use FTDI's DLL interface instead of VCP. BML has accomplished this in .NET
     but not in Python programming environment.

o sump2.py is VERY slow rendering and/or crashes.
  Before launching sump2.py, try modifying the sump2.ini values for:
  sump_rle_post_trig_len = 00100000
  sump_rle_pre_trig_len  = 00100000
  These represent "cull" zones before and after the trigger to toss any RLE
  samples after decompression. Making these numbers smaller limits the maximum
  time window that sump2.py will work in. By definition, RLE captures of very
  little activity will generate a giant uncompressed database that may be either
  impossible or too impracticle for the software to deal with.