X-Git-Url: http://git.rot13.org/?p=BML_sump2;a=blobdiff_plain;f=sump2_troubleshoot.txt;fp=sump2_troubleshoot.txt;h=db903733c6685f4d9554b40dedd3e99303e3f028;hp=0000000000000000000000000000000000000000;hb=b6ac52f611f53e96447a6bee178d418f14623985;hpb=bbafe3d7b73ed7bf085686eb333ea10a968bd40b

diff --git a/sump2_troubleshoot.txt b/sump2_troubleshoot.txt
new file mode 100644
index 0000000..db90373
--- /dev/null
+++ b/sump2_troubleshoot.txt
@@ -0,0 +1,38 @@
+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.
+
+