EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: matbob on March 10, 2019, 04:00:02 am
-
Hello All,
I would like to share my experience with upgrading the DSLogic Basic to Plus. I saw discussions in EEVblog forum where some people were able to upgrade the basic version to plus version by soldering the 256Mbit RAM chip and renaming the firmware files (DSLogicBasic.fw/bin replaced by DSLogicPlus.fw/bin and renamed to *Basic.fw/bin). Even after these two steps, some were not able to get the upgrade and they had to modify the EEPROM content. The USB device PID in the EEPROM had to be changed to match the Plus version so that the DSView software recognizes the device as DSLogic Plus hardware.
Now, I will tell my story. I bought a DSLogic Basic clone from Ebay and I wanted to upgrade it to Plus. I bought the 256Mbit RAM and soldered it. I downloaded the DSView V0.99 from DreamSourceLab website and compiled and installed it (on Fedora 28, fingers crossed, installed successfully!). I ran the software, connected the hardware and it got detected as DSLogicBasic. Then I checked for the location in my PC where the firmware files are located, I found it was at: "/usr/local/share/DSView/res". I backed up all the files in the folder (you will need root privilages). Then I deleted the DSLogicBasic.fw and DSLogicBasic.bin files and made copies of DSLogicPlus.fw and DSLogicPlus.bin files and renamed them to DSLogicBasic.fw and DSLogicBasic.fw. By this step, the idea is to load the Plus firmware to the Basic (+RAM) hardware the next time the DSView software starts up. I opened DSView and connected my hardware, but it got detected only as DSLogic Basic.
So, the DSView software is checking the PID of the USB device to determine which version it is. Obviously, the PID was not getting modified by changing the firmware from Basic to Plus. The PID is stored inside the EEPROM and for the DSView software to recognize the hardware as Plus version, the EEPROM content had to be modified. I had a PICkit3 with me and I thought I will desolder the EEPROM, solder on a protoype board, solder the wires from PICkit3, read the EEPROM contents, modify the PID value at 2 locations (as suggested in another forum), write it back and solder it back. Unluckly, PICkit3 does not support EEPROM programming without a hardware hack. I did not want to do the hardware hack (beacuse the PICkit3 does not belong to me).
But I wanted to check that even though the DSView software recognized my hardware as Basic version, will it be capable of delivering the performace of the Plus version because the hardware and firmware is Plus version and only the PID is of Basic version. I checked the DSView software's user guide. The guide says that in the buffer mode, the maximum sample duration is given by: (maximum duration = hardware depth / sample rate / number of channels used). At 400MHz sample rate with 4 channels enabled, for a DSLogicBasic with 256Kbit memory, the maximum duration corresponds to: (256 x 1024 / 400M / 4) = 163.84us. For a DSLogicPlus with 256Mbit memory, the maximum duration is (256 x 1024 x 1024 / 400M / 4) = 167.77 ms! With my hardware (with the extra RAM and Plus firmware) I could see that in the DSView software, maximum duration is only 163.84us. That means the software is limiting the functionality even though the hardware is capable.
Now comes the interesting part. The DSView program was complied from the source. So, in the source code, there will be some place where the PIDs of the devices are defined. After a few minutes of searching, I found the file: .../DSView-0.99/libsigrok4DSL/hardware/DSL/dsl.h in which the DSLogic "profiles" for each version are defined. It was not very difficult to understand. I modified the following lines in the code:
{0x2A0E, 0x0021, "DreamSourceLab", "DSLogic Basic", NULL,
"DSLogicBasic.fw",
"DSLogicBasic.bin",
"DSLogicBasic.bin",
{CAPS_MODE_LOGIC,
CAPS_FEATURE_VTH,
(1 << DSL_STREAM20x16) | (1 << DSL_STREAM25x12) | (1 << DSL_STREAM50x6) | (1 << DSL_STREAM100x3) |
(1 << DSL_BUFFER100x16) | (1 << DSL_BUFFER200x8) | (1 << DSL_BUFFER400x4),
SR_KB(256),
0,
DSL_STREAM20x16,
0,
0,
DSL_STREAM20x16,
SR_MHZ(1),
SR_Mn(1),
0,
0}
},
to:
{0x2A0E, 0x0021, "DreamSourceLab", "DSLogic Basic", NULL,
"DSLogicBasic.fw",
"DSLogicBasic.bin",
"DSLogicBasic.bin",
{CAPS_MODE_LOGIC,
CAPS_FEATURE_VTH | CAPS_FEATURE_BUF,
(1 << DSL_STREAM20x16) | (1 << DSL_STREAM25x12) | (1 << DSL_STREAM50x6) | (1 << DSL_STREAM100x3) |
(1 << DSL_BUFFER100x16) | (1 << DSL_BUFFER200x8) | (1 << DSL_BUFFER400x4),
SR_MB(256),
0,
DSL_BUFFER100x16,
0,
0,
DSL_STREAM20x16,
SR_MHZ(1),
SR_Mn(1),
0,
0}
},
I assume that the modification is self explanatory if you go through the code. 0x2A0E is VID, 0x0021 is PID of Basic version, the SR_KB(256) is modified to SR_MB(256).... By this modification, I force the software to use the features offered for Plus hardware for the Basic hardware (already upgraded to Plus) as well. After this, I compiled and installed DSView again. This time also the name of the hardare appeared as DSLogic Basic (becasue I did not modify this in the source) but I see that the maximum duration available with my hardware is 167.77 ms!
The only catch is that if you connect a Basic hardware without the RAM soldered to the hacked DSView software, it will use the Plus firmware and because the RAM is not available, it won't show any results. But as long as you have only one hardware with the RAM soldered to it, this method works well.
-
Using the CyConsole tool didn't work for reprogramming the EEPROM?
-
Hello tsman,
Thanks for the comment. I was unaware of CyConsole. I went online and read about this software, it seems that it is a tool in the Cypress SuiteUSB which is available only for Windows. I run Linux (Fedora) on my PC and therefore I can't try this.
If I want to modify the PID in the EEPROM, I should be knowing the address where the PID is stored. According to this post in one of the forums: https://time4ee.com/news.php?readmore=453 (https://time4ee.com/news.php?readmore=453), there are 2 locations: 00000003 and 0000186A. The value has to be changed from 0x21 (PID of Basic) to 0x20 (PID of Plus). This might be possible using CyConsole. Please let me know whether you have successfully tried this. This would be much elegant method rather than modifying the DSView software.
Thank you.
-
I just upgraded my DSLogic Basic to the Plus version and I can confirm that it works. The steps I followed:
1- I got the MT48LC16M16A2-6A SDRAM IC from here https://www.aliexpress.com/item/in-stock-can-pay-MT48LC16M16A2-TG-75D-MT48LC16M16A2P-6A-MT48LC16M16A2TG-7E-MT48LC32M16A2-5pcs-lot/32805462396.html (https://www.aliexpress.com/item/in-stock-can-pay-MT48LC16M16A2-TG-75D-MT48LC16M16A2P-6A-MT48LC16M16A2TG-7E-MT48LC32M16A2-5pcs-lot/32805462396.html)
2- Desoldered the EEPROM from the LA board (U4) and attached it to a programmer like this https://www.aliexpress.com/item/SOIC8-SOP8-Test-Clip-For-EEPROM-93CXX-25CXX-24CXX-CH341A-24-25-Series-EEPROM-Flash-BIOS/32898599200.html (https://www.aliexpress.com/item/SOIC8-SOP8-Test-Clip-For-EEPROM-93CXX-25CXX-24CXX-CH341A-24-25-Series-EEPROM-Flash-BIOS/32898599200.html) I used a DIP8-SOIC8 adapter.
3- Read the EEPROM and save a backup just in case. Search for the Hex values "0E2A2100" and change it to "0E2A2000" (It appears 2 times, you need to change both). I've used HxD editor to edit the file extracted from the memory.
4- Just reprogram the EEPROM e solder the ICs to the board.
5- Now, when you open DSView it should identify the device as DSLogic Plus, no need to rename firmware files.
-
This happened before-
https://www.eevblog.com/forum/testgear/dslogic-plus/msg2011508/#msg2011508 (https://www.eevblog.com/forum/testgear/dslogic-plus/msg2011508/#msg2011508)
Simply rename the fw file from Plus to Basic. That's it.
I wonder if maybe the eeprom firmware has changed on newer ones where the fw file is no longer loaded/needed?
It seems odd that I can rename the fw file all day long (0.9.8,0.9.9) and switch between Plus/Basic, and some others don't seem to be able to.
If there is a newer eeprom firmware on newer ones, one way to check would be to remove all fw files and see if dsview is still happy (or if on Windows, just listen for the usb detection/re-enumerate when dsview starts).
-
I just upgraded my DSLogic Basic to the Plus version and I can confirm that it works.
Me too... :)
3- Read the EEPROM ...
4- Just reprogram the EEPROM ...
I'm sad but this didn't work for me :((
Taking a closer look at the EEPROM it identifies itself as 4128BRP form ST -> M24128
UNfortunately it seems not to be supported by CH341A programmer, ST Chips are listed only within 24C01 - 24C64, no C128 , no M-types..
So i ordered a couple of Atmel Chips on ebay and hope...
For the meanstime I edited the sources, DSView and PulseView, similar as mentioned above.
DSView recons the unit just at the moment of connection, PulseView not.
First you must connect the device and afterwards start Pulseview... :-//
-
Just select any common EEPROM chip form the menu like the 24C128 (supposing you are using the same CH341 programmer as me) that it should work.
Did you de-soldered the chip from the board? The programmer will not work if you try to read the eeprom with the IC on the board, you have to remove it. I then used an adapter like this https://www.aliexpress.com/item/1PCS-150mil-SOIC8-SOP8-to-DIP8-EZ-Programmer-Adapter-Socket-Converter-Module-Suitable-for-ALL-11/32900742229.html (https://www.aliexpress.com/item/1PCS-150mil-SOIC8-SOP8-to-DIP8-EZ-Programmer-Adapter-Socket-Converter-Module-Suitable-for-ALL-11/32900742229.html) attached to the CH341 ZIF socket.
-
Hello,
I tried the method of replacing the firmware in the eeprom and soldered the ram's memory. Unfortunately, my dslogic is not working. The DSView application sees the analyzer as a plus version, but giving a rectangular signal to inputs has no effect - it is always zero. Return to the old version (Basic) of the eeprom without changing the VID and PID returns the analyzer to normal operation (square wave). I also checked the random memory pins of the oscilloscope and see that communication occurs.
Can anyone share a working hex file for the plus version.
PS. File from the thread https://time4ee.com/news.php?readmore=453
it gives the same effect as I wrote above.
Regards
-
Did you get the Basic to work again? have you tried again to upgrade it to a Plus?
I had a random thought. that RAM add on to make it a Plus is 256MB,
Has anyone tried 512MB? Is it doable? double the amount of RAM of the Plus version?
-
Hello
1. Yes the Basic version works without problems (with BASIC firmware version), even with soldered 256MB RAM chip.
2. Yes, I tried two times, but without any effects. The software (v0.99) sees the plus version, however, after entering the rectangular signal to input, the DSView software always sees zero.
3. I have not tried to use 512 MB.
-
Hi,
Just to provide another data point.
I purchased a DSLogic basic on ebay. I was confused and thought it was the Plus.
I added the SDRAM chip (https://au.element14.com/micron/mt48lc16m16a2p-6a/sdram-256mbit-167mhz-54tsop/dp/2253737)
see https://time4ee.com/news.php?readmore=453 for intial information (but don't remove the EEPROM!)
Method 1 - no EEPROM changes required
-------------------------------------------------
I then (under windows) patched the DSView program. It is necessary to search for the PID/VID for the basic and change it so that it doesn't detect the Basic one and then modify the PID/VID for the Plus so that it is the Basic (two bytes modified). This effectively makes the software accept the basic as plus. The PID/VID are in little-endian order. (DSView.exe, Offset EE9AC2, EE9B52.)
Method 2 - Re-program EEPROM in-situ
--------------------------------------------
Wire pin 7(WC) to pin 4(Gnd) on the EEPROM. This disables the write protect. This can be done with a fine wire e.g. wire-wrap. This is safe because pin 7 only has a pull-up to Vdd.
This allows the EEPROM to be programmed by the Cypress USB chip over the USB from a PC.
A program to do this is available at https://github.com/podonoghue/LogicAnalyser/tree/master/Software/fx2lafw_eeprom_loader
The required EEPROM images are available if you search on the web or you can simply download the image from the DSLogic and patch the PID/VID and reprogram.
You may remove the link after programming but there is no requirement.
bye
Edit to clarify.
-
Hello pgo
Thanks for the information, I will try to upgrade the analyzer according to your suggestion this coming weekend.
I have an question. Which file in the DSview app you patched?
At the moment I found hex file only on this page: https://time4ee.com/news.php?readmore=453
and I have used them without success.
files:
The 24C128 EEPROM content file
https://mega.nz/#!j8p3iSZB!-L7zwI02reZQz0ASXzjAxWUnioAEUW1Z70uJY6H2oNQ
Regards
-
You don't need to change any file in the DSview, just solder the SDRAM chip and desolder the EEPROM. Read the EEPROM chip that you just removed from the board with a eeprom reader. Save the extracted content, that is your HEX file, then edit it to change the PID/VID, save it and reprogram the eeprom using this modified HEX file. Solder the IC back to the board, if everything is correct, the DSview will identify your LA as the Plus version.
I've posted a more detailed explanation (with pics) a few threads above.
There was another method that involved renaming some files in the DSview folder, but it did not work for me and if you reinstall the software or change the computer you would have to rename the files again. Reprogramming the EEPROM worked fine and is a more permanent solution.
-
Hi Fonak,
I edited DSView.exe.
Offset EE9AC2, EE9B52.
Hi Microcheap -
Not everyone has access to a programmer!
It is easier to solder one wire than remove the EEPROM.
It easier to program the chip without removing it and you don't need a programmer at all.
bye
-
Hi Microcheap and pgo
I did exactly (I use ch341a eeprom programmer) how you write in post from March 16, 2019, But this do not work for me.
As I wrote before, DSwiev sees the analyzer as Plus but after giving the rectangular signal to the iputs, softwere always sees zero (always flat line at zero level). When I return to original firmware everything worked fine as Basic version of course :)
I will try to upload the firmware again with your method and the method proposed by PGO. I hope one of them works. In addition, I will try to upload a hex downloaded from the Internet
Thank you pgo and Microcheap very much for your help
-
Hi Microcheap and pgo
I noticed a strange thing. When I ran the modified DSView file as pgo said (Offset EE9AC2, EE9B52 change data from 21 to 20) the analyzer is detected as BASIC and works perfect as BASIC (buffer 163us @ 400MHz). Then without disconnecting the analyzer from usb I closed the modified DSView program and turned on the original one. Then the analyzer is recognized as PLUS and works perfect as PLUS version (167ms buffer @ 400MHz). If I disconnect the analyzer from the USB and connect again (or restart original DSView.exe ), the analyzer is recognized as a PLUS but does not see the rectangular signal at the input. The analyzer has been programmed with modified firmware (offset 00000003 and 0000186A change from 21 to 20).
-
After reading this thread, I ordered a USB programmer with SOIC-8 clip and a (MT48LC16M16A2) memory chip to upgrade my DSLogic basic. I will try the 'fx2lafw_eeprom_loader' tool first and if I can't get it to work I can desolder the flash chip if necessary. Hopefully the memory chip and programmer will arrive next week if the E-Bay estimates are accurate.
-
I have a basic that isn´t upgraded yet. Where all would I have to change the memory value if I was gonna try the 512MB ram chip?
-
Hello
New version of DSview has been released
change log 1.00 -- (2019-09-09)
-----------------
--common
*add multi-language support and dynamic switch
*add two themes (dark/light) support and dynamic switch
*improve 4K/high DPI display support
*add close function for file type device
*add message tips when encounter file save errors
*fix file format of export file, like VCD
*fix other minor issues
--for logic analyzer
*add support for V3 version decode library
*add more decoders, the number of decoders come up to 97
*improve options and speed for certain decoders
*fix load&store issue of some decode options
*fix wrong measure result at certain sample rate
*fix channel selection of stream mode
*fix filter issue above 100M sample rate
*fix decode error for long time capture
*fix progress display issue when set region decode
*improve measurement bwteent edges in different channels
--for oscilloscope
*improve the auto measure funciton, support up to 20 measurements
*improve UI for auto measure
*implement x-y mode display for lissajous-figure
*implement Add/Sub/Mul/Div math channel
*add horizontal measure cursors
*improve measure of frequency, refer to current trigger level
*fix captured wave display issue when change horizontal resolution
*fix inconsistant issue when export csv file
*improve algorithm of frequency measure, especially for low frequency and special signals
*improve autoset function
*improve auto calibraiton function
--for data acquisiton
*add default settings of Y-axis
https://www.dreamsourcelab.com/download/ (https://www.dreamsourcelab.com/download/)
-
Method 2 - Re-program EEPROM in-situ
--------------------------------------------
Wire pin 7(WC) to pin 4(Gnd) on the EEPROM. This disables the write protect. This can be done with a fine wire e.g. wire-wrap. This is safe because pin 7 only has a pull-up to Vdd.
This allows the EEPROM to be programmed by the Cypress USB chip over the USB from a PC.
A program to do this is available at https://github.com/podonoghue/LogicAnalyser/tree/master/Software/fx2lafw_eeprom_loader
The required EEPROM images are available if you search on the web or you can simply download the image from the DSLogic and patch the PID/VID and reprogram.
I attempted to use the program but I don't have any compilers, and it won't run on Windows which it was compiled for without a pile of libraries. I'm attempting to use Eclipse and MINGW recompile it into a binary that includes all necessary libraries but it's a new experience for me. I would buy a programmer but this seems an interesting challenge.
-
Hi AngusBeef,
I believe the bin directory contains all the required DLLs from MingGW-64, the libusb DLL and the executable.
What DLLs do you believe is missing?
There should be no need to build anything (under Windows-64bit).
bye
-
I know that libwinpthread-1.dll is missing from the directory (at least on my PC) as I get an exception for it saying it failed to start as it's missing that dependency.
However, once I downloaded the above .dll from MinGW and drop it in the bin folder I still get a different exception at 0xc000007b.
I'm solving a library linking issue with GCC and the Eclipse IDE on Linux since I'm getting the "function not defined" errors when I can see they're properly defined in the header files - but it's been about 8 years since I've played with C++ so I forgot almost everything and I'm on the struggle bus.
Edit: to clarify I have both a Windows computer and a Linux computer - tried running it on Windows and I'm trying to recompile it on Linux - the libraries you used are mostly cross-compatible with the exception of Windows.h which reading through looks like only was used for the sleep function - but there's unistd.h that provides the same.
-
Hi
I've added libwinpthread-1.dll to the bin directory.
I didn't spot it missing as apparently there is a copy in my windows/system32 directory - presumably dropped by some other software.
I was assuming any DLLs picked up from there were part of windows.
It is probably important to have the correct version i.e. matching the build.
Dependency graph is attached.
I have also built it on Linux and included a binary but this will be even more problematic.
bye
-
Thanks! Including the additional dependencies solved the issue running the software on Windows.
Connected the pins with two probes and a lead wire, read the hex file off, changed the appropriate entries, and voila - it's got a new PID.
The only issue I ran into was that the checksums were incorrect in my hex file the first time I tried to write it (because I changed values in two lines of course). - I'm glad you run those checks in your program - I did some reading and then updated the checksum for the two lines I changed and then it wrote with no issue.
I think your method is more ingenious and elegant than de-soldering the EEPROM to use a programmer - it takes advantage of the components that already exist on the board.
-
Hello,
I have one uinit from the very first DSLogic coming out of the Kikstarter campaign.
I was even helping in the RLE compression on this hardware few years ago.
I have not used my device much and now I saw people are upgrading the RAM and EEPROM so I thought let give a try
I have purchased MT48LC16M16A2P and and surprise, my unit is already with MT48LC16M16A2P :) so it seems the Kickstarter batch is with 256 Mbit out of the box.
DSview recognizes the unit as DSlogic.
I also noticed that DSLogic now seems to support RLE compression.
I know the Kickstarter batch does not support adjusting the threshold level.
Having all this in mind I have few questions:
1. Does it make sense to upgrade the EEPROM with the new PID, so eventually it is recognized as DSLogic plus?
2. Is there someone tested the procedure with an original Kikstarter unit?
Is it working and what happens if one tries to adjust the threshold level?
3. Why people bother to upgrade the RAM at all?
Does RLE compression work fine now?
Does DSlogic plus offer other benefits?
Thank you
Dimitar
-
There seems to be an issue with AliExpress supply of MT48LC16M16A2P ICs at the moment - some feedback suggests that only the 133 MHz variant is being supplied even when the -6A 166 MHz part number is requested.
Is this an issue for upgrading the DSLogic Basic? Can it make effective use of the slower 133 MHz part? It looks like obtaining confidence in getting the exact -6A part is going to cost significantly more, if it's required.
-
I got a new DS Logic U2B, update sdram to 256Mbit, but modify the usb vid & pid to plus(u2b is 29, change to 20) in eeprom, but it can not work.
The PCB look like this.
-
I got a new DS Logic U2B, update sdram to 256Mbit, but modify the usb vid & pid to plus(u2b is 29, change to 20) in eeprom, but it can not work.
The PCB look like this.
Same here but have not received SDRAM yet. It came with 64Mbit(?) ram installed, so you removed that one and soldered the new one?
You may want to check some of those solder joints on the top under a microscope if you can.
Not working, as in after you changed the VID/PID in two places it no longer works at all or it still shows as a U2B?
-
I have a DSlogic and didn't use it in the last few years. This months I tried it with the latest PulseView (Sigrok) which was already installed in Ubuntu, and DSLogic was not recognized.
Does the upgraded DSlogic works with a generic PulseView, too, or is it working only with DSView (which is nothing but a PulseView by DreamSourceLab)?
-
I have a DSlogic and didn't use it in the last few years. This months I tried it with the latest PulseView (Sigrok) which was already installed in Ubuntu, and DSLogic was not recognized.
Does the upgraded DSlogic works with a generic PulseView, too, or is it working only with DSView (which is nothing but a PulseView by DreamSourceLab)?
Did you follow the installation procedure yet? https://sigrok.org/wiki/DreamSourceLab_DSLogic#Firmware
-
Yes, 64Mb -> 256Mb
Using U2B origin eeprom firmware, use buffer mode, test new SDRAM(256Mb) is ok.
Modify pid/vid, DSView shows Plus, but push start, only wait, not work.
I use other plus firmware from this post, DSView shows Plus, also not work.
Change DSView from latest 1.0.1 to 0.9.9, work ok. Because DSLogicPlus.bin changed, not work good with U2B version, you can copy older to latest 'res' folder.
-
Took another look yesterday. Turned out my DSlogic already has 256Mbit SDRAM, and it is not a clone, it was made by DreamSourceLab in 2015. On the box is written DSLogic Pro.
[attach=2]
[attach=1]
When it is recognized, it appears as DSLogic Pro, so nothing to upgrade. VID:PID of the device is 2a0e:0003, with no device description.
I don't recommend to use PulseView, try to use DSView instead.
DSView has way more acquisition modes, triggers and features than PulseView has, also DSView works properly, while PulseView sometimes returns fake signals or works erratically. The easiest way would be to make a virtual machine with Windows 7 and install DSView in the virtual machine.
To run PulseView instead of DSview, it will need to install the DSlogic firmware files and to create a udev access rule. Even after installing the firmware files and giving access to the device, PulseView / Sigrok will still have only a fraction of the DSView features and settings. However, the latest PulseView might have some extra protocol decoders that were not yet ported to DSView.
However, if one insists to use PulseView in Linux:
1. Download PulseView from https://sigrok.org/wiki/Downloads (https://sigrok.org/wiki/Downloads)
2. Make the downloaded AppImage file executable
3. Install the firmware files for DSlogic as described in https://sigrok.org/wiki/DreamSourceLab_DSLogic#Firmware
- download the firmware install script https://sigrok.org/gitweb/?p=sigrok-util.git;a=blob;f=firmware/dreamsourcelab-dslogic/sigrok-fwextract-dreamsourcelab-dslogic (https://sigrok.org/gitweb/?p=sigrok-util.git;a=blob;f=firmware/dreamsourcelab-dslogic/sigrok-fwextract-dreamsourcelab-dslogic)
- make the downloaded script executable and run it as root
sudo ./sigrok-fwextract-dreamsourcelab-dslogic
- by default the script will download the firmware files from github, then copy them into /usr/local/share/sigrok-firmware and from now on, any version of PulseView will find them when necessary
4. Make a new udev rule to grant access to the USB device, or else PulseView/Sigrok will throw the error "sr: dreamsourcelab-dslogic: Failed to open potential device with VID:PID 2a0e:0003"
- create a file named /etc/udev/rules.d/99-dslogic.rules with the following content
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a0e", ATTRS{idProduct}=="0003", MODE:="0666"this will grant access to the USB device with ID 2a0e:0003, which is the USB ID for my DSlogic Pro
- re-run all the udev rules, so the newly created rule file 99-dslogic.rules will be taken into account with the command
sudo udevadm control --reload-rules
5. Start the PulseView by running the AppImage file, and the DSlogic should now work.
./PulseView-NIGHTLY-x86_64.AppImage
6. After connecting to DSlogic, the LED will turn from orange to green.
-
Has anyone successfully upgraded a DSLogic Basic with SDRAM IC MT48LC16M16A2P-75, -7D or -7E?
-
Has anyone successfully upgraded a DSLogic Basic with SDRAM IC MT48LC16M16A2P-75, -7D or -7E?
best is 6A. I bought -75 first, after welded, not work.
-
Hi,
The one I used was Element-14 (Farnel)
MT48LC16M16A2P-6A
https://au.element14.com/micron/mt48lc16m16a2p-6a/sdram-256mbit-167mhz-54tsop/dp/2253737
bye
-
Yes, 64Mb -> 256Mb
Using U2B origin eeprom firmware, use buffer mode, test new SDRAM(256Mb) is ok.
Modify pid/vid, DSView shows Plus, but push start, only wait, not work.
I use other plus firmware from this post, DSView shows Plus, also not work.
Change DSView from latest 1.0.1 to 0.9.9, work ok. Because DSLogicPlus.bin changed, not work good with U2B version, you can copy older to latest 'res' folder.
That works with DSView, thanks. I used the eeprom from fx2lafw_eeprom_loader linked above and its working with pulseview as well.
From what I can see the only difference between U2B and Pro is the memory chip. The board looks the same. But then why would they behave differently and have a quite different EEPROM loaded (see attached)?
Also of note, the cables may be improved over before but the Basic and Pro cables are still very different. You can see here the Plus cables have a heatshrink section, presumably for the shield of the coax:
https://www.aliexpress.com/i/32905798335.html (https://www.aliexpress.com/i/32905798335.html)
The Basic and U2B are just plain wires.
From the specs the adapter board and component values appear to be the same. So I may try in the future replicating their design with some RG178.
-
I got a new DS Logic U2B, update sdram to 256Mbit, but modify the usb vid & pid to plus(u2b is 29, change to 20) in eeprom, but it can not work.
The PCB look like this.
Me too. Like the attachment, the PID becomes different. What can I do?
-
Me too. Like the attachment, the PID becomes different. What can I do?
Did you try 0.9.9 dsview as recommended?
You can either modify the eeprom to change the PID to pro. Or you can simply re-flash with the Pro eeprom file that has been uploaded by pgo (https://github.com/podonoghue/LogicAnalyser/tree/master/Software/fx2lafw_eeprom_loader).
-
so，you mean using the old version of dsview, I try, thanks！
btw, new version has two UIs，i like this
-
so，you mean using the old version of dsview, I try, thanks！
btw, new version has two UIs，i like this
You can either use the old version, or copy the 'res' folder from 0.9.9 to the new version, as hhyytt has discovered above.
-
Great！ I try，thank you reply!
-
I tried the method of hyyytt, covering the res of 1.0.1 with the 0.9.9 version of the res file.
but, opening 1.0.1 is still recognized as the u2b version。
my modification：
1. 64M --》 256M；
2.EEPROM edit PID；
3.DSVIEW 0.9.9 res replace--》 1.0.1 res
File from https://github.com/miniwave/DSview_v0.99
4.open DSVIEW 1.0.1 Identified as U2B fail！
Attached is the HEX file after modifying the PID
tell me what is wrong？
-
Can the U2Basic be upgraded to the same specs as the Pro, just like the previous Basic?
I got sent a U2B from Aliexpress w/ out the shielded fly wires, instead of the Basic. Poop. Filed a claim and got offered to ship it back (>$20) or take a 50% refund. 7 days to appeal. I can buy the fly wires separate for $~25.
-
Got the crappy DSLogic U2Basic
There are at least absent PCB trace from FPGA to RAM chip, so according to the MT48LC16M16A2 datasheet A12 pin (last pin of address bus) is not connected, so at least 16x16 DRAMs cannot be addressed fully.
Seems we can add some wire with the same length as another traces for address bus, but I'm not sure that this is the only change in the PCB design.
[attach=1]
-
Hi, Team
As my 256Mb chip still in transit, I decided to play a little with EEPROM.
I'm pretty lazy, so decided to connect 4th and 7th pins with small wire instead of desoldering EEPROM chip. But unfortunately, fx2lafw_eeprom_loader.exe unable to find my U2Basic due to 0029 PID, so I've modified .exe file to enable support U2Basic instead of Basic (just replaced 21 to 29 in offset 0x00008472).
After that I was able to load Basic firmware to the U2Basic and now it works as old good DSLogic Basic (with 400MHz sample rate and 256Kb buffer).
If you are interested in - feel free to use it. In the archive - fx2lafw_eeprom_loader with 0029 PID instead of 0021, .hex dump of DSLogic U2Basic EEPROM, and .hex dump of DSLogic Basic EEPROM.
-
Are you able to verify it actually works above 100MHz?
I've just changed the source code of DSView: libsigrok4DSL/hardware/DSL/dsl.h, added | (1 << DSL_BUFFER200x8) | (1 << DSL_BUFFER400x4), after (1 << DSL_BUFFER100x16) and changed samplerates100 to samplerates400 in DSLogic U2B definition (around line 532).
Now it seems to work up to 400MHz with 64MB buffer, but I have no way of verifying that since I don't have a working generator above 100MHz.
-
Use the generator at 100 MHz, and should see about 4 samples for each period of signal.
-
Well, it shows 40 samples for 10MHz signal. So I guess this part works - however, the question is whether it will really work at 400MHz or if it'll do just some weird interpolation or something like that.
I have my doubts about DSL (whichever version) working reliably with 100MHz+ signal anyways...
-
My experiences:
a) Bought U2 Basic.
b) Opened it up, wires pin 4 to 7 on the SPI flash
c) Reflashed with the "Basic" hex using the modified fx2lafw_eeprom_loader_u2b.exe - replugged, works (with current latest DSView 1.0.1) recognized as Basic model that does 400Mhz (appears to work fine, but obviously no real buffer memory)
d) Replaced SDRam with 48LC16M16A2-75 (hot air and microscope. I think I did it ok, we shall see..)
e) Booted again (still as 'Basic'), still works (as it's ignoring the SDRam)
f) Flashed this "Basic" version with https://raw.githubusercontent.com/podonoghue/LogicAnalyser/master/Software/fx2lafw_eeprom_loader/bin/DsLogicPro hex file using the 'unmodified' fx2lafw_eeprom_loader.exe
g) DSView 1.0.1 recognizs it as DSLogic Plus, but hangs ("waiting for trigger") when capture starts
h) DSView 0.9.9 does work: Streaming mode: works but oddly I see periodic one-sample zero glitches (e.g. every 16 samples are zero) on all channels. Self-test doesn't even work right. Ack. Stuff is all half-broken, lots of bad samples and stuff. Dammit.
i) Put board back under microscope and redid the SDRam soldering, it wasn't a great job the first time
j) Plug it back in and... lots of it works! (on V0.9.9) I fed in a 25mhz clock to the first four channels and sampled it at 400mhz (buffered mode) and it's fine!
e.g.
j1) Buffered mode, 4 channel, 400mhz sampling, with 167.77ms buffer (max available; not using RLE) == 400M*0.5*0.167 = 32MBytes = 256MBit. The data (25mhz clock on all channels) looks great. Adjustable input voltage threshold is working too.
j2) NOTE: RLE modes do _not_ seem to work reliably for me at >100Mhz speeds:
8 CH @ 100mhz, 200ms RLE sampling works ok, but stepping same thing to 200mhz gets me garbled results, channels shifted around, general half-crap.
However, if I do the same 8CH/200mhz buffered without RLE, the data (superficially) looks good.
So.. almost fully working...
The RLE crapping out at 200Mhz and up may imply sporadic SDRam errors (that are perhaps returning a few wrong samples not visible to the eye in non-RLE mode; obvs errors in RLE would cause large ripple effects on the data, like what I'm seeing)
This may well be memory access time problems (I am using a -75 chip).
I may swap the SDRam for a faster one, or just not use RLE modes on this and treat it with a bit of suspicion over 100mhz.
V1.0.1. note:
You can (kinda) use this with 1.0.1 software too - you just have to use the bitstreams from 0.9.9 (as pointed out on here);
in the "DSView/res" folder you can replace the "DSLogicPlus.bin" xilinx bitstream file with the one from 0.9.9
(Note that the firmware is only loaded if the device has not been programmed since it was plugged in, so you can (for example) run v0.9.9, do a capture, then quit and run V1.0.1)
I assume the 1.0.1 bitstream is superior, but it hangs on start on a hacked unit. Pehaps my RLE errors are actually something they fixed in the new bitstream.. ? More likely they are that my SDRam is too slow. We shall see...
-
Got the crappy DSLogic U2Basic
There are at least absent PCB trace from FPGA to RAM chip, so according to the MT48LC16M16A2 datasheet A12 pin (last pin of address bus) is not connected, so at least 16x16 DRAMs cannot be addressed fully.
Seems we can add some wire with the same length as another traces for address bus, but I'm not sure that this is the only change in the PCB design.
Thanks, this seems to be working well. Made a small attempt at trace length matching.
edit: the 1.0.1 bitstream is working as well.
-
Hello,
A new version of DSView 10.1 has appeared
link:
https://www.dreamsourcelab.com/download/ (https://www.dreamsourcelab.com/download/)
Changelogs:
–common
*add support for DSCope U3P100 device (100M bandwidth/1G samplerate/USB3.0 oscilloscope)
*add support for DSLogic U3Pro32 device (32 channels/1G samplerate/USB3.0 logic analyzer)
*add support for DSCope U2B100 device (100M bandwidth/1G samplerate/USB2.0 oscilloscope)
*add support for DSLogic U3Pro16 device (16 channels/1G samplerate/USB3.0 logic analyzer)
*add display of device type (USB 2.0 / USB 3.0 / Demo / File)
*add version check for FPGA firmware
*improve the default file name when saving/exporting files
*fix other display and language issue
–for logic analyzer
*extend channel support for trigger up to 32 channels
*fix issue of ps/2 decoder (#239)
*fix issue of cec decoder (#235)
*fix ID issue when export results of decoder (#237)
*fix “not” logic don’t work in advance trigger
*fix other display issues
–for oscilloscope
*improve wave shake issue when trig high freqency signals
*fix sampling point selection issue of downsampling
*add 20M bandwidth limitation for DSCope U2B100 / DSCope U3P100 devices
*improve synchronism between data acquisition and wave dispaly
*fix wave display and measurement issue when change vdiv and offset after stop
*fix capture restart issue when change offset in roll mode
*fix issue of timebase of math channel can’t be changed when waiting trigger
*fix issue of offset can’t be changed when waiting trigger
*fix clear and flicker issue of auto measurements
*fix cursor and mouse measurements issue after change samplerate when waiting trigger
*fix trigger issue when toggle between different trigger source
–for data acquisiton
*fix hardware offset setting issue
*fix mipmap issue of long time data at some case
*add cursor and mouse measurements
-
Thanks, this seems to be working well. Made a small attempt at trace length matching.
edit: the 1.0.1 bitstream is working as well.
I've made the same modification, but it's still not working with the latest bitstream.
Maybe it's due to the RAM I'm using, given I have soldered the -75, which is 34MHz slower than the -6A version. Which one of the two do you have?
-
The u2b that i've upgraded had a 166mhz memory, replaced with a 6e variant and all ok. So i think that the 133mhz version can have problems
-
Thanks @masterx81, probably my intuition was right then.
But could you please confirm you're talking about the 6A version? I could not find any 6E, while there is a 7E, which is 133MHz as well, which would probably be too slow as well.
Or maybe it was me who couldn't find it
-
6A, not 6E, you are right :-+
-
I've made the same modification, but it's still not working with the latest bitstream.
Maybe it's due to the RAM I'm using, given I have soldered the -75, which is 34MHz slower than the -6A version. Which one of the two do you have?
In the photo I posted above, -6A
-
I received also my DSLogic Basic that has 64 Mb ram installed. I did some investigations to upgrade to pro and noticed following:
64Mbit ram datasheet can be found from here:
https://www.winbond.com/resource-files/w9864g6kh_a02.pdf (https://www.winbond.com/resource-files/w9864g6kh_a02.pdf)
And 256Mbit version here:
https://www.winbond.com/resource-files/da00-w9825g6khc1.pdf (https://www.winbond.com/resource-files/da00-w9825g6khc1.pdf)
Difference between those is that 256Mb version has extra address pin A12 mapped to pin 36. Measured that pin from PCB and seems that it is not connected to any pin of Spartan? Has anyone measured that from Pro version where that should be connected?
-
Found one blurry image of back side of pcb from net. Seems that there is at least on trace missing from my basic version compared to that.[attachimg=1]
-
Look here for u2b;
https://www.google.com/amp/s/m.habr.com/ru/amp/post/483496/ (https://www.google.com/amp/s/m.habr.com/ru/amp/post/483496/)
I've used a thin enameled wire to connect the missing addressing pin. The i've done the eeprom mod and it works perfectly
-
I have a question regarding the shielded leads w/compensation network. The only 2 suppliers that seem to show these with the DSLogic Plus are Banggood, and Dreamsource.
Thanks.
-
I see thm_w's post helped answer this a few months ago. :clap:
-
So the difference from this 2 types of leads?
-
Yes masterx81, that's correct. I see aliexpress does sell the DSLogic Plus with the upgraded leads.
I need to order a large quantity for our engineering students, which might be a big ask.
-
More digging shows that one aliexpress supplier does have a massive amount of stock (4000+). Price is good at $95 US.
-
Sorry but what's the difference between the two type of leads? Less noise at high frequency?
-
Sorry but what's the difference between the two type of leads? Less noise at high frequency?
Yeah shielding could help a bit with noise. Bandwidth should be higher with the coax. But no one has actually compared the two.
-
I have one of the "older" leads, but also this seem a really small coax cable, connected to ground on the unit side
-
Any cable is also a transmission line. In a transmission line, when the impedance is not matched, the signal is reflected back and forth, making one see spikes or ringing on the signal edges if it is observed with an oscilloscope, or fake/multiple edges instead of only the correct edge when looking with a signal analyzer that can see only zeroes and ones.
Note that this reflections happens no matter how low is the frequency of the signal. What matters most in case of digital circuits is the raising and falling time of the edges. The fastest the edge, the more problems, no matter if we look at a 100 Hz or a 100 MHz signal.
TL;DR
The shielded cable is supposed to:
- have a controlled impedance, so one can match the impedance, and thus observe the correct signals and correct edges, not influenced by signal reflections.
- have a controlled velocity factor (and thus an equal propagation delay for all wires), so the edges from many parallel lines are observed in the correct order.
With normal (unshielded) wires, the impedance varies wildly, depending how the wire is bent or twisted, or how close is relative to other wires, or relative to GND.
This video from w2aew explains very well the idea of transmission lines and reflections, and also shows the waveform produced by the combination between the original signal and its reflections. Keep in mind that the same phenomena happens at any frequency, no matter if it's sinusoidal signal for a radio transmitter, or square signal for a digital circuit. The signal analyzer will be very confused by the strange waveforms appearing because of reflections. Also, keep in mind that those reflections seen in the video are nice and stable only because the pulses duration is constant. With varying digital signals, the combination between original and reflected signal can turn even the cleanest waveform into an unrecognizable mess. So, here is why, and how it looks like for the most simple cases:
https://www.youtube.com/watch?v=g_jxh0Qe_FY (https://www.youtube.com/watch?v=g_jxh0Qe_FY)
Now, how worry should we be? For looking at signals on an Arduino or a breadboard, using short wires like the ones coming with the probes, most probably there will be no visible difference between a shielded cable and a normal wire.
For looking at high speed signals with very aggressive edges, on a PCB with controlled impedance traces, the shielded cable and correct impedance matching is a must.
As an example, if you put a clean square wave (no matter the frequency, but with very fast edges), and don't care about the impedance matching, you can easily see 2-3 fake edges instead of one, especially at maximum acquisition speed.
By fake edge, I mean a few very close transition instead of a single clean falling or clean raising edge. Looks similar with a debounce noise, but it is caused by signal reflections, not by imperfect mechanical contacts.
As a fun exercise, you can see how the number and the distance between the oscillations of a fake edge varies with the length of the connection wire, or with the impedance mismatch. ;D
-
Look here for u2b;
https://www.google.com/amp/s/m.habr.com/ru/amp/post/483496/ (https://www.google.com/amp/s/m.habr.com/ru/amp/post/483496/)
I've used a thin enameled wire to connect the missing addressing pin. The i've done the eeprom mod and it works perfectly
My effort to upgrade my U2 Basic to Plus went poorly. Unless this is not understood, the FPGA pin that drives the A12 Ram pin is connected to GND on the U2Basic PCB. The above link shows that this pin needs to be isolated by carefully 'lifting' the pin from the GND pad. I struggled but managed to get this pin lifted and made the connection to the RAM A12 input. However, the mod failed. I believe that I may have damaged this FPGA pin by updating the EEprom to PLUS and applying power to the board 'before' I isolated the FPGA pin from GND. My belief is that with the board configured as a PLUS version, this forced the FPGA pin to an OUTPUT while it was connected to GND, causing a short circuit and damaging this FPGA pin. I have no proof of this but I recommend isolating the FPGA pin before configuring EEprom to the PLUS version. At this point when I perform an internal test, the test shows all 0 on each line.
Does anyone have any further information regarding this? Curious if others had similar failures.
Take care -
rfdes
-
The pin should be not connected on both sides, then you add a jumper wire to connect fpga to ram.
It shouldn't be grounded. But I can't remember actually measuring to confirm that.
You can see my photo above: https://www.eevblog.com/forum/testgear/upgrading-dslogic-basic-to-plus-without-eeprom-modification/msg2921384/#msg2921384 (https://www.eevblog.com/forum/testgear/upgrading-dslogic-basic-to-plus-without-eeprom-modification/msg2921384/#msg2921384)
Internal test worked OK.
-
The pin should be not connected on both sides, then you add a jumper wire to connect fpga to ram.
It shouldn't be grounded. But I can't remember actually measuring to confirm that.
You can see my photo above: https://www.eevblog.com/forum/testgear/upgrading-dslogic-basic-to-plus-without-eeprom-modification/msg2921384/#msg2921384 (https://www.eevblog.com/forum/testgear/upgrading-dslogic-basic-to-plus-without-eeprom-modification/msg2921384/#msg2921384)
Internal test worked OK.
I've seen the bare PCB without the FPGA installed and the I/O pin used to drive A12 is definitely grounded. My issue was resolved due to an intermittent solder bridge on the FPGA between two signals used to read/write to the RAM chip. These two pins are located about 10 pins away from the i/o signal used to drive A12. It was just a coincidence that this started giving me trouble at the time I was implementing the upgrade modification. Just my luck. Anyway after clearing the bridge all is well.
take care -
-
I've seen the bare PCB without the FPGA installed and the I/O pin used to drive A12 is definitely grounded. My issue was resolved due to an intermittent solder bridge on the FPGA between two signals used to read/write to the RAM chip. These two pins are located about 10 pins away from the i/o signal used to drive A12. It was just a coincidence that this started giving me trouble at the time I was implementing the upgrade modification. Just my luck. Anyway after clearing the bridge all is well.
take care -
Thank you for noticing :-+, took it apart again and it was grounded as you say. Have to lift the pin using a pointy exacto knife.
From what you are saying self-test should indicate failures in memory, but maybe I wasn't looking closely or its not fully testing the memory capacity, as I don't remember seeing anything unusual there.
-
Has anyone found a good source to buy just the shielded cables like the Plus uses? I'm upgrading my U2Basic (thanks to everyone who contributed to this thread) and the only source seems to be https://www.aliexpress.com/item/32999482818.html, (https://www.aliexpress.com/item/32999482818.html,) for around $30 shipped to the USA
Not sure if it's worth the extra cost, though, so I'll start with the memory upgrade only (and using fx2lafw_eeprom_loader to change the device ID) and see if it works well enough for me at the relatively low speeds I'm likely to use
-
Here are some remarks regarding upgrade from U2B to Plus. A lot of this information was spread across multiple posts and I wasted some time troubleshooting the issues. So here we go:
1. You need MT48LC16M16A2P-6A, apparently -6A is very important.
2. Replace RAM chip with the new one.
3. You have to lift the leg on FPGA! The leg is grounded by default, it won't work without lifting it. Be very careful, it's extremely easy to break the leg off.
4. Solder a wire between unconnected legs of FPGA and RAM. There are pictures in the topic so you can easily count which legs you have to solder to. Just remember you also have to left the pin on the FPGA!
4. Solder a wire across leg 4 and 7 of the EEPROM chip. You can also short it with tweezers for the programming but it won't do any harm if you leave the wire in place.
5. Use fx2lafw_eeprom_loader.exe software to program new firmware. You will find the link here in the topic.
6. Now the thing I had most problems with - there are a lot of firmware files being posted. I don't know why others had good luck with them but in my case a lot of them wouldn't work. The program would reports invalid characters in the hex file. So what worked 100% for me was:
fx2lafw_eeprom_loader.exe -t M24128 -p DsLogicPro
The firmware DsLogicPro should be provided with the software (ref. https://github.com/podonoghue/LogicAnalyser/blob/master/Software/fx2lafw_eeprom_loader/bin/DsLogicPro). You don't have to look for any special firmware files here in the topic.
Steps above converted my U2B to Plus version which happens to work in all DSView versions on macOS. People had issues with newest releases or they had to replace bitstreams but none of that was required for me. I use DSView 1.12 which is the newest available version at the time of writing this post. Also RLE seems to work quite reliably for me, even at 400MHz. Not sure if the person having issues did the wiring properly by matching length of the wire (should be 38.5mm). I used 0.1mm enameled wire which is probably the best for the job. With RLE you won't capture over ~400ms in buffered mode, not sure why you have options for 1, 2 or even 10 seconds.
DSView is a piece of shit and I prefer PulseView (mainly because I can use my own decoders) which works with DSLogic Plus but not with U2B.
-
I recently updated as well, and I was planning to summarize the new steps, but you beat me to it :) well done!
Couple of notes:
- Lifting the FPGA pin is, by far, the most challenging part of the upgrade. The rest, especially if using bismuth or ChipQuik to remove the RAM is trivial. The FPGA pin requires a good soldering iron, good eyes or a microscope, and 3 hands ::). And even so you risk bridging the neighboring pins or breaking the pin off. Do this only if you have previous experience with similar tasks, or practice on a dead board first. Corollary: if your time is worth anything, you are better off buying the Plus version directly
- The instructions are mostly written for the upgrade from Basic to Plus, not from U2B which is the one sold now. You cannot edit the file extracted from the U2B and modify only 2 bytes. The binary file is different. You need to find a Plus firmware binary. I downloaded the one described here https://habr.com/ru/post/483496/ (use Google translate), and uploaded on github https://github.com/User420t/DSL (the password is in the post with all the steps... now sure why it was password protected)
- If you use Windows, you need https://github.com/podonoghue/LogicAnalyser/tree/master/Software/fx2lafw_eeprom_loader/bin
@webhdx as far as I can tell, the DsLogicPro.bin file (at least in my distribution) is 334k. The EEPROM is only 16k. The file I used, 24c128_plus.bin is 16k. If you use the hex version (same content, different encoding), it's 46K. 334k is way too big. How did you manage to make it work? The *.bin files in the DsView distribution are, as far as I can tell, hdl files for the FPGA, and what it's stored in the EEPROM is just the firmware for the Cypress USB interface and to tell the system what type of board you have. The hdl is then uploaded by either DsView or PulseView, the correct version for the type of device used (Basic, U2B or Plus). It looks as if DsLogic used the Pro moniker at one point, but now it's probably the Plus version
DsLogic uses different hdl (DsLogicPlus.bin, DsLogicBasic.bin, DsLogicU2Basic.bin, etc) depending on the ID of the board. The board we bought has a Cypress firmware in EEPROM that identifies it as a U2Basic, so needs one version of the hdl (the one that knows some pins are tied to ground and using a smaller RAM). After the modification, we need to update the EEPROM to tell the system we now have a different board, with more RAM and identical to a Plus. Then DsView/PulseView will upload the correct hdl and use all the memory, plus unlock the faster data capture rates. Quite understandably, DsLogic doesn't expect the users to change the EEPROM, so they do not provide the right firmware in the distribution. And we need someone with an actual Plus to dump their EEPROM and share the bin file
Also, DsView *is* PulseView with a different UI and a few functionality changes. As a matter of fact, there were a lot of tensions between the sigrok community and DsLogic because DsLogic did not properly attribute the code nor posted the changes. You can use any PulseView decoder in DsView just by copying them in the right directory. The current released version of DsView lacks a lot of decoders, but all the decoders have been checked into their github repository (from PulseView) and can be used
-
The firmware file is in HEX format and the file itself is 44kB: https://github.com/podonoghue/LogicAnalyser/blob/master/Software/fx2lafw_eeprom_loader/bin/DsLogicPro Most of the contents are 0xFF's so it will probably just write first 16kB of the file. This is what worked for me.
I think you are right and it's just a firmware for USB stuff, not actual bitstream for FPGA. Yes I've heard about the drama between sigrok and DsView. The UI in DsView is terrible on Mac, there are lots of issues - I can't really zoom with mouse scroll etc. PulseView is what it is but at least I can comfortably use it on macOS.
-
Great. I can confirm that this file https://github.com/podonoghue/LogicAnalyser/blob/master/Software/fx2lafw_eeprom_loader/bin/DsLogicPro is, indeed, identical to the DsLogic Plus Cypress firmware, so it can be used to convert a U2Basic to Plus. And th eone you found is easier to find than all other semi-hidden files
What confused me in your reply, is that actually in the DsView distribution there is a file called DsLogicPro.bin (334K) and a DsLogicPro.fw (8k). The bin file is the hdl that DsView uploads upon initialization (and so does PulseView when manually adding those files), and the fw file seems to be a Cypress firmware, but very different from the one used on the Plus. There is an utility hex2bin that can easily convert between hex and bin formats and makes it easy to compare the different formats.
If anyone does a search for DsLogicPro.bin, they will find the wrong file, and that was the source of my confusion. I would suggest that you edit your great summary, and add the github URL of the actual file you used, to help future readers.
-
Thanks to everyone in this topic who worked this stuff out.
I just bought a U2Basic and completed the upgrade to Plus. I used hot air, a microscope, and scalpel to lift that FPGA pin. Still not a difficult mod IMO. Here's a pic of the board after lifting the pin and adding a wire.
I dumped the memory from the EEPROM and found it to be different to what sigrok says on their wiki: https://sigrok.org/wiki/DreamSourceLab_DSLogic_U2Basic
Mine has 7000 bytes instead of 6977.
I didn't use the USB utility to reflash the EEPROM, though I now realise that would have been the easier option. I used an Arduino-based programmer and one of those SOIC clips which had a surprisingly dicky connection.
Also I noticed that, after changing the EEPROM, I couldn't capture any waveform in DSView until I added that missing address wire.
-
Hi,
I just dismantled my DSLab Basic that I bought a long time ago and discovered that it doesn't have any ram at all. Might this explain why I've had such difficulty getting it to work or were some of these things actually supposed to ship with no ram?
Anyway, I've ordered a MT48LC8M16A2P-6A from rs-components so I'll solder that on when it turns up and see how I get on from there.
-
Hi,
I just dismantled my DSLab Basic that I bought a long time ago and discovered that it doesn't have any ram at all. Might this explain why I've had such difficulty getting it to work or were some of these things actually supposed to ship with no ram?
Anyway, I've ordered a MT48LC8M16A2P-6A from rs-components so I'll solder that on when it turns up and see how I get on from there.
You have one of the older Basic, not the U2Basic which is discussed here. In your case, soldering the RAM and changing a few bits in the EEPROM is all you need, no FPGA surgery. Much easier than converting the U2Basic
-
Hello
New version of DSview has been released: v1.2.0 — (2022-07-05)
https://www.dreamsourcelab.com/download/ (https://www.dreamsourcelab.com/download/)
ChangeLog
—————–
–common
*fix issue of large file saving failure in some cases
*optimize file saving speed
*fix issue of recognization of USB2.0 devices under MacOS
*fix abnormal window display caused by system scaling
*fix issue of hidden toolbar buttons
*fix assert errors caused by multithreading problem
*modify processing window of file saving
*fix accidental operation issues during file loading
*fix screenshot issue
*build a new compilation method based on cmake
*fix window cannot be recoved issue after moving out of screen
*fix other display issues
–for logic analyzer
*add protocol search function
*add auto stacking function when adding multi-layer protocols
*optimize decoder memory usage
*add specific decoder support for format conversion of data
*add enable/disable options for mouse quick scroll
*add csv export format selection (original / compressed)
*fix issue of wave back search
*optimize parallel decode, and increase to 32 data channels
*optimize the clock edge setting of MDIO decoder
*fix issue of Flexray decoder
*fix issue of ps/2 decoder
*optimize sdcard decoder
*extend interval to 0.1s under repeat mode
*increase number of decoders up to 138
–for oscilloscope
*fix the data accuracy issue when exporting csv file
*fix math waveform generation of half screen data when stop
*remove invalid edge count measurment display
*fix crash caused by trigger dock movement
*fix display error of time ruler in some cases
–for data acquisiton
*fix data inverval error under ultra-low sample rate
-
if I buy a new fpga, since I broke the pin on the existing one that needed to be raised, is there a file that needs to be inserted into it (fpga) and how can I use which HW
-
if I buy a new fpga, since I broke the pin on the existing one that needed to be raised, is there a file that needs to be inserted into it (fpga) and how can I use which HW
The necessary bitstream is downloaded in the FPGA every time you start DsView. Assuming it's cost effective to buy a new FPGA vs buying a new device, replacing the FPGA is safe to do.
If you have a Dremel tool with a fine tip and a good stereo microscope, you can also probably remove enough of the FPGA package material to expose the pin again. The sliver of silicon inside a FPGA is small, and there is plenty of pin material inside the package. I mean, that FPGA is toast for your purpose anyway, so might as well try to save it. Something like https://www.reddit.com/r/electronics/comments/75wcjb/how_to_repair_an_ic_with_damaged_pins/ (https://www.reddit.com/r/electronics/comments/75wcjb/how_to_repair_an_ic_with_damaged_pins/)
For everyone else attempting this modification, be aware that damaging the FPGA pins is a real possibility
-
is there a difference in the family if this one is from 2013, but I can find it in 2005
https://de.aliexpress.com/item/1005004024791617.html?spm=a2g0n.detail.1000014.4.7e0c4658vTgIio&gps-id=platformRecommendH5&scm=1007.18499.332340.0&scm_id=1007.18499.332340.0&scm-url=1007.18499.332340.0&pvid=5a318a3d-f810-4540-b6dc-5082e05db8e8&_t=gps-id%3AplatformRecommendH5%2Cscm-url%3A1007.18499.332340.0%2Cpvid%3A5a318a3d-f810-4540-b6dc-5082e05db8e8%2Ctpp_buckets%3A668%232846%238109%231935&pdp_npi=4%40dis%21BGN%2133.68%2133.01%21%21%2118.00%21%21%402103146c16956427935132733e047b%2112000027783341628%21rec%21BG%21137681740%21&gatewayAdapt=glo2deu (https://de.aliexpress.com/item/1005004024791617.html?spm=a2g0n.detail.1000014.4.7e0c4658vTgIio&gps-id=platformRecommendH5&scm=1007.18499.332340.0&scm_id=1007.18499.332340.0&scm-url=1007.18499.332340.0&pvid=5a318a3d-f810-4540-b6dc-5082e05db8e8&_t=gps-id%3AplatformRecommendH5%2Cscm-url%3A1007.18499.332340.0%2Cpvid%3A5a318a3d-f810-4540-b6dc-5082e05db8e8%2Ctpp_buckets%3A668%232846%238109%231935&pdp_npi=4%40dis%21BGN%2133.68%2133.01%21%21%2118.00%21%21%402103146c16956427935132733e047b%2112000027783341628%21rec%21BG%21137681740%21&gatewayAdapt=glo2deu)
-
is there a difference in the family if this one is from 2013, but I can find it in 2005
https://de.aliexpress.com/item/1005004024791617.html?spm=a2g0n.detail.1000014.4.7e0c4658vTgIio&gps-id=platformRecommendH5&scm=1007.18499.332340.0&scm_id=1007.18499.332340.0&scm-url=1007.18499.332340.0&pvid=5a318a3d-f810-4540-b6dc-5082e05db8e8&_t=gps-id%3AplatformRecommendH5%2Cscm-url%3A1007.18499.332340.0%2Cpvid%3A5a318a3d-f810-4540-b6dc-5082e05db8e8%2Ctpp_buckets%3A668%232846%238109%231935&pdp_npi=4%40dis%21BGN%2133.68%2133.01%21%21%2118.00%21%21%402103146c16956427935132733e047b%2112000027783341628%21rec%21BG%21137681740%21&gatewayAdapt=glo2deu (https://de.aliexpress.com/item/1005004024791617.html?spm=a2g0n.detail.1000014.4.7e0c4658vTgIio&gps-id=platformRecommendH5&scm=1007.18499.332340.0&scm_id=1007.18499.332340.0&scm-url=1007.18499.332340.0&pvid=5a318a3d-f810-4540-b6dc-5082e05db8e8&_t=gps-id%3AplatformRecommendH5%2Cscm-url%3A1007.18499.332340.0%2Cpvid%3A5a318a3d-f810-4540-b6dc-5082e05db8e8%2Ctpp_buckets%3A668%232846%238109%231935&pdp_npi=4%40dis%21BGN%2133.68%2133.01%21%21%2118.00%21%21%402103146c16956427935132733e047b%2112000027783341628%21rec%21BG%21137681740%21&gatewayAdapt=glo2deu)
Protip: don't buy an FPGA from an Aliexpress seller with 90% rating. Desoldering and resoldering that many pins risks damaging the PCB, and you don't want to discover you got a bad FPGA (or even a different chip with altered markings) after soldering it (and having to remove it again)
Use a reliable source like https://www.digikey.com/en/products/detail/amd/XC6SLX9-2TQG144C/2339919 (https://www.digikey.com/en/products/detail/amd/XC6SLX9-2TQG144C/2339919) or similar
But, yes, if you want the device to work as expected, use the exact same device model or you risk that either the bitstream doesn't work or subtle timing differences prevent the logic analyzer from working properly
-
Protip: don't buy an FPGA from an Aliexpress seller with 90% rating. Desoldering and resoldering that many pins risks damaging the PCB, and you don't want to discover you got a bad FPGA (or even a different chip with altered markings) after soldering it (and having to remove it again)
NOT terrible as above description, but NO select cheapest seller， what price, what goods 。
-
first attempt
-
Looks promising.
I had good luck with this wire for super-tiny soldering jobs https://www.remingtonindustries.com/magnet-wire/155-c-polyurethane/?_bc_fsnf=1&Wire+Size%5B%5D=40+AWG&Wire+Size%5B%5D=44+AWG. (https://www.remingtonindustries.com/magnet-wire/155-c-polyurethane/?_bc_fsnf=1&Wire+Size%5B%5D=40+AWG&Wire+Size%5B%5D=44+AWG.) The coating is easily burnt off with a slightly hotter soldering iron, and the wire is easily solderable after that, with the coating still protecting the rest of the wire. I solder/strip 2-3mm, then snip to leave only a short solderable section of the wire.
-
Looks like there is new hardware on the DSLogic U2Basic
The FPGA is no more a Spartan6 now is a PANGO PGL12G somebody knows if it can be upgraded too?
(https://habrastorage.org/r/w1560/getpro/habr/upload_files/7a0/0af/131/7a00af1319d9aaaa16895e2cb27ed946.jpg)
-
You will need to trace the connections between the memory and FPGA, but without the exposed pins, I doubt you'd be able to make this work.
Worse: in order to make DSView recognize the hacked U2Basic as a Plus, you need to change the device ID so that DSView can upload the right FPG bitstream. The new FPGAs use a different bitstream, so you'd also need to figure out if there is a U2Basic and Plus for the PANGO, and change the device ID that way
So, all considered, unlikely it will work unless you can get both a new U2Basic and new Plus, and figure everything else out...
-
I don't know exactly how helpful this might be: I believe support for the Pango was added in this commit to DSLogic's github (https://github.com/DreamSourceLab/DSView.git):
C:\devtrees\DSView>git bugnote 2532ad4c1
```
in repository: C:/devtrees/DSView
in branches: master
============
commit 2532ad4c
Author: dreamsourcelabTAI <tzz@dreamsourcelab.com>
Date: Mon Dec 12 15:58:05 2022 +0800
Suports new hardware
A DSView/res/DSLogicPlus-pgl12.bin
A DSView/res/DSLogicU2Basic-pgl12.bin
M libsigrok4DSL/hardware/DSL/command.h
M libsigrok4DSL/hardware/DSL/dsl.c
M libsigrok4DSL/hardware/DSL/dsl.h
============
```
And in case it helps, the Pango firmware files have been updated in these commits:
C:\devtrees\DSView>git ls -- DSView/res/DSLogic*-pgl12.bin
264e7c46 DreamSourc.. 2023-06-27 update FPGA bin files (version E)
b9b143c3 DreamSourc.. 2023-06-16 update fpga bin file for DSLogic
63955d72 dreamsourc.. 2023-04-26 Loop mode
cfa0c1cb dreamsourc.. 2023-01-12 update: new firmware file
2532ad4c dreamsourc.. 2022-12-11 Suports new hardware
-
I don't know exactly how helpful this might be: I believe support for the Pango was added in this commit to DSLogic's github (https://github.com/DreamSourceLab/DSView.git):
C:\devtrees\DSView>git bugnote 2532ad4c1
```
in repository: C:/devtrees/DSView
in branches: master
============
commit 2532ad4c
Author: dreamsourcelabTAI <tzz@dreamsourcelab.com>
Date: Mon Dec 12 15:58:05 2022 +0800
Suports new hardware
A DSView/res/DSLogicPlus-pgl12.bin
A DSView/res/DSLogicU2Basic-pgl12.bin
M libsigrok4DSL/hardware/DSL/command.h
M libsigrok4DSL/hardware/DSL/dsl.c
M libsigrok4DSL/hardware/DSL/dsl.h
============
```
And in case it helps, the Pango firmware files have been updated in these commits:
C:\devtrees\DSView>git ls -- DSView/res/DSLogic*-pgl12.bin
264e7c46 DreamSourc.. 2023-06-27 update FPGA bin files (version E)
b9b143c3 DreamSourc.. 2023-06-16 update fpga bin file for DSLogic
63955d72 dreamsourc.. 2023-04-26 Loop mode
cfa0c1cb dreamsourc.. 2023-01-12 update: new firmware file
2532ad4c dreamsourc.. 2022-12-11 Suports new hardware
Could still be possible, but one needs to EEPROM values for the new U2Basic and Plus. The right ID is needed so that DsView can decide to send the new bitstream instead of the old.
From the picture, it seems that the line A12 is connected in the memory chip (pin 36). If so, that means that the hardest part (lift the FPGA pin to add the address wire/pin) is not needed on this new device. A low risk test should be possible: rename the FPGA bitstream for the new Plus bitstream as the U2Basic (so that DsView sends the Plus bitstream thinking it's sending the U2Basic), capture data to fill the memory of the Plus, and monitor the A12 line. If there is activity in the A12 line, it might be possible to perform the hack by replacing the memory and finding the right ID for the EEPROM (by asking a new Plus user to read their EEPROM, which can be done without opening or any risk to their device)
If A12 is tied to ground like it was in the Spartan U2Basic, the hack is probably too hard...
-
Just wanted to share another success story.
Thanks to all who contributed to the cause.
-
Could still be possible, but one needs to EEPROM values for the new U2Basic and Plus. The right ID is needed so that DsView can decide to send the new bitstream instead of the old.
From the picture, it seems that the line A12 is connected in the memory chip (pin 36). If so, that means that the hardest part (lift the FPGA pin to add the address wire/pin) is not needed on this new device. A low risk test should be possible: rename the FPGA bitstream for the new Plus bitstream as the U2Basic (so that DsView sends the Plus bitstream thinking it's sending the U2Basic), capture data to fill the memory of the Plus, and monitor the A12 line. If there is activity in the A12 line, it might be possible to perform the hack by replacing the memory and finding the right ID for the EEPROM (by asking a new Plus user to read their EEPROM, which can be done without opening or any risk to their device)
If A12 is tied to ground like it was in the Spartan U2Basic, the hack is probably too hard...
Just got mine U2Basic today, with PGL12G FPGA.
The USB device ID is in the commit.
{0x2A0E, 0x0030, LIBUSB_SPEED_HIGH, "DreamSourceLab", "DSLogic PLus", NULL,
{0x2A0E, 0x0031, LIBUSB_SPEED_HIGH, "DreamSourceLab", "DSLogic U2Basic", NULL,
Btw, anyone found anything on they new FPGAs?