https://blackmesalabs.wordpress.com/2016/10/24/sump2-96-msps-logic-analyzer-for-22/

[BML_sump2] / sump2_troubleshoot.txt

diff --git a/sump2_troubleshoot.txt b/sump2_troubleshoot.txt
new file mode 100644 (file)
index 0000000..db90373
--- /dev/null
+++ b/sump2_troubleshoot.txt
@@ -0,0 +1,38 @@
+SUMP2 Troubleshoot\r
+\r
+o FPGA doesn't configure when plugged in. No solid green, only faint 4 reds.\r
+  This indicates the FPGA did not configure. Assuming the PROM is already \r
+  properly configured with the sump2 firmware, quickly unplug and replug the \r
+  iCEstick into the USB port. The 2nd insertion seems to always work. I suspect\r
+  an inrush current issue with the iCEstick board design. Possibly the FPGA \r
+  configuration begins prior to the boards bypass caps being fully charged.\r
+\r
+o bd_server.py fails to connect to correct COM port.\r
+  With bd_server.ini line "usb_port=AUTO", the application will try to connect \r
+  with 1st FTDI VCP it finds. Chances are either there isn't a valid VCP for "B"\r
+  port of the FT2232H chip, or there are multiple VCPs that have been located\r
+  and the 1st one bd_server found wasn't the right one. The most reliable way\r
+  to use bd_server.py is to modify bd_server.ini and manually specify the COM#\r
+  that you know the iCEstick "Converter B" VCP is assigned to. This can be \r
+  found manually on Win7 under [Start],[Devices and Printers].\r
+\r
+o "Converter B" was previously VCP enabled and now it is not.\r
+  This is a very annoying FTDI device driver feature. The VCP only stays \r
+  enabled if the same USB host port is used. Example, if you have a USB Hub and\r
+  switch the iCEstick to a different slot in the hub, your VCP settings will be\r
+  lost. There are two potential long term solutions to this issue:\r
+  1) Use FTDI's FT_PROG utility to always enable VCP on "B" of the FT2232H.\r
+  2) Use FTDI's DLL interface instead of VCP. BML has accomplished this in .NET\r
+     but not in Python programming environment.\r
+\r
+o sump2.py is VERY slow rendering and/or crashes.\r
+  Before launching sump2.py, try modifying the sump2.ini values for:\r
+  sump_rle_post_trig_len = 00100000\r
+  sump_rle_pre_trig_len  = 00100000\r
+  These represent "cull" zones before and after the trigger to toss any RLE\r
+  samples after decompression. Making these numbers smaller limits the maximum\r
+  time window that sump2.py will work in. By definition, RLE captures of very\r
+  little activity will generate a giant uncompressed database that may be either\r
+  impossible or too impracticle for the software to deal with.\r
+\r
+\r