EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: andrewg_oz on August 16, 2019, 02:02:57 pm
-
Long time lurker here, registered just now to post this...
tldr: USBee makes (made?) logic analysers. They also produce their own Windows support software, the USBee Suite. That software appears to contain 'kill code' intended to disable knock-off clone hardware, but will also kill legitimately purchased USBee hardware.
In 2009 I was in the market for a logic analyser and decided on the USBee DX. At the time it was the top-of-the-line logic analyser from USBee. I purchased it primarily because their software supported user-developed protocol decoders, which I ended up making limited use of. I paid about $1600 at the time, which was a lot, but worthwhile for what I was doing with it.
A couple of years ago I stopped working for myself, and started working for "the man". I stopped using my own logic analyser. Until, that is, a few weeks ago when an old project turned up that needed troubleshooting. I downloaded the USBee Suite from the website re-installed it, and .... nothing. The logic analyser wasn't recognised.
Instead, an unknown device with VID 69C0 and PID 6909 showed up. The USBee DX should have been VID 08A9 and PID 0015.
Two weeks ago I emailed USBee and was advised to return it to fix an eeprom corruption, which I did. It was only after sending it that I thought to do some Googling. It turns out that USBee clone developers had reported the VID and PID of their hardware being changed to 69C0 and 6909 after running the USBee Suite software. Clearly, the anti-clone measures were too broad and had disabled my very expensive and legitimately purchased USBee DX, right when I needed to use it!
Two weeks later, and FedEx have been unable to deliver my logic analyser, so it is heading back. Unfixed. Apparently, the USBee guy I contacted gave me his *home* address, and he was "moving", so nobody was there to receive it.
So, let this be a warning. If you're currently using a USBee and their Suite - be very careful. Don't download any updates, and keep a copy of whatever installer you currently have. Use something like sigrok/pulseview instead. If you're looking at getting a USBee - don't. Any business that kills their own customer's hardware should be avoided. Well, I think something else should be done to them, but I'll refrain from describing *that*.
I'm currently planning to follow some instructions involving some Cypress utility software to edit the VID and PIDs myself. Maybe I can get it working.
-
Thanks for the heads up. Sounds like the morons at FTDI.
-
Cloned ftdi chip has its vid pid changed by the drivers .. windows cant see it properly identified afterwards cant recall witch version
You have to use the ftdi prog to reset/ re-write the vid and pid to their proper versions, and use an x vesrion of the drivers to work .....
That was the famous FTDI gate ...
-
Here's a link I kept from the time for the unbricking procedure...
https://www.reddit.com/r/arduino/comments/2k0i7x/watch_that_windows_update_ftdi_drivers_are/clgviyl/ (https://www.reddit.com/r/arduino/comments/2k0i7x/watch_that_windows_update_ftdi_drivers_are/clgviyl/)
-
Thanks for the heads up. Sounds like the morons at FTDI.
Yup. If it has FTDI Inside then it might be nothing to do with USBee.
(apart from them using cloned chips to build the thing in the first place, but maybe they thought they were real chips...)
-
so the $1600 USBee is using cloned FTDI?
-
so the $1600 USBee is using cloned FTDI?
If they are, it's maybe not their fault.
FTDI are notoriously hard to buy from directly in "small" quantities (ie. less than millions) and the chip fakers are quite resourceful in getting their products into the supply chains used by anybody who wants less than that.
and (b) That still doesn't give FTDI the right to brick people's devices.
This has been gone over a zillion times already. No need to start another thread, the old ones still apply.
Start here:
https://www.youtube.com/watch?v=eU66as4Bbds (https://www.youtube.com/watch?v=eU66as4Bbds)
-
There is no FTDI chip in the USBee DX. This isn't related to FTDIgate.
The OP's problem may or may not be intentional on the part of the software developers.
The USBee DX apparently uses a pair of Cypress FX2LP chips (CY7C68013A) - one for digital I/O, and the other for analog inputs via some ADCs. They "share" the USB via a USB hub chip.
More info (based on a clone) is at the Sigrok site https://sigrok.org/wiki/XZL_Studio_DX
-
ditto, in fact i have the cloned hardware that can be switched between usbee, salaeae and altera blaster using cypress chip. it doesnt have FTDI. a $5 HW with $1595 SW. last night i checked they now have $20 version SW for the cloned HW. its the $1595 pro version that imo condemned the cloned chip.
-
Just a follow-up, the USBee guy has been back in touch with a link to that cheap SW for cloned hardware, "You will want to use the following software so that doesn’t happen again".
That's pretty much admitting it was their software and it was deliberate...
I'll be really annoyed if this fixes it without faffing about with the Cypress software.
-
Jan 1 2024: This is EXACTLY what has happened to me! I pulled my USBee DX out of the drawer to put it to use, re-installed software and BAM the USB IDs had been changed! Also paid $1600 for it new back in 2009 or so.... Company now out of business... What can I do?
-
1600? You got to be kidding me! You must be a rich man.. what now? Buy saelae logic..
-
:scared: try soft https://sigrok.org/wiki/Main_Page
-
Maybe sigrok works with it?
-
At the Sigrok link I posted previously showing support of the clone USBee DX, it mentions there is only support for the digital inputs.
https://sigrok.org/wiki/XZL_Studio_DX
-
Jan 1 2024: This is EXACTLY what has happened to me! I pulled my USBee DX out of the drawer to put it to use, re-installed software and BAM the USB IDs had been changed! Also paid $1600 for it new back in 2009 or so.... Company now out of business... What can I do?
Get a suitable EEPROM programmer (not 100% sure, but isn't it possible to use the FX2 itself to program its EEPROM?) and investigate.
See if it's enough to reprogram PID/VID back to original values.
If not, beg for somebody to upload full image from a working unit. Or look if an image hasn't been published somewhere.
Or buy a clone and copy the firmware :-DD
-
1600? You got to be kidding me! You must be a rich man.. what now? Buy saelae logic..
Well, despite I like, and prefer Saleae logic analyzers over every other one, $1,499.00 isn't far away from your kidding $1600. In this regard Saleae isn't any different and they are actively bricking counterfeit analyzers as well. Until now I bought over 10 original analyzers from them and I absolutely recommend Saleae. Their support is outstanding. However when I tested a clone which uses a spartan 3 FPGA, it used to work until an update in 2015 or so. After that update it was completely dead even using previous SW versions. Either they've burned fuses in the FPGA or reprogrammed the I2C EEPROM with incorrect data.
-
Thanks everyone for your suggestions.
The reason I dug it out was to try it with Sigrok, as I wanted to use the USB PD protocol decoding capabilities.
I first wanted to make sure that it was working so reinstalled the USBee software I had downloaded years ago - before USBee disappeared - and that it when I started having problems. At first it was working. The USBee DX software recognized the device, would run for a bit, then crash. This happened a few times.
Then decided to try on a different machine that I had the USBee software installed. It was at that point the device was no longer recognized. The USBee device enumerates in Windows Device Manager, but is not connected to the correct drivers.
I then found this post, and confirmed that the USB VID and PID had been changed to the 69C0 and 6909 as the original poster indicated. This means that Windows no longer recognizes the USB device and therefore cannot associate it with the USBee drivers. So it is clear that that VID and PID in the USBee DX ROM has been corrupted.
I then tried the Cypress USB programmer (a software package from Infineon) that allows programming of the Cypress chips used by the USBee, which contains two CY7C68013A-56XVC, one for the digital inputs and the other for the analog. No luck, as it could not see the USB devices. Oddly It found the USB mouse and keyboard, but not the USBee.
Assuming that the EEPROM code is valid but only the VID and PID have been altered, it may be salvageable, but if the EEPROM contents have been corrupted further, then, yes, a new software image will be required.
The question is, how do I program the bloody thing if even the Cypress software can no longer attach to the device?
-
The question is, how do I program the bloody thing if even the Cypress software can no longer attach to the device?
Well two options:
- short SDA line to ground -> FX2LP detects eeprom corruption and boots to VID/PID of 04B4/8613
- use external programmer
-
Would be helpful for those confirming the issue to post SHA256 or MD5 hashes of the culprit executable.
Not all bad software is malware bad, but bad is still bad. ;)
-
Cypress Suite Usb 3.4.7 can and could on some fx + eeprom, rewrite and or work with an external eeprom, not sure it apply here ??
CY3684Setup.exe 51 megs .... i had to search a lot outside Cypress to get it
-
The question is, how do I program the bloody thing if even the Cypress software can no longer attach to the device?
Well two options:
- short SDA line to ground -> FX2LP detects eeprom corruption and boots to VID/PID of 04B4/8613
- use external programmer
The short should work, of course it needs to be removed after the board shows up on USB but before accessing the EEPROM with Cypress software.
Alternatively, I found a 3rd party tool for Linux which reads and writes EEPROM connected to FX2. It can work with any IDs.
https://github.com/ribalda/fx2eeprom
I checked that it reads my FX2 board, but it only reads 4KB. Perhaps that's the maximum transfer the bootloader can do in one go and moving more data is as simple as repeating the USB request with increasing 'address' variable, but I haven't tried.
edit
Yes, it can read and write to arbitrary addresses, up to 4KB per run. Patch below is all I had to change, 'offset' is the address to start reading/writing at. I have successfully reprogrammed my board's 8KB EEPROM a few times.
diff --git a/fx2eeprom.c b/fx2eeprom.c
index 222b8eb..72d8883 100644
--- a/fx2eeprom.c
+++ b/fx2eeprom.c
@@ -47,7 +47,7 @@ enum {READ,WRITE};
void use(char *prog){
- fprintf(stdout,"%s w/r VID PID size\n",prog);
+ fprintf(stdout,"%s w/r VID PID size offset\n",prog);
return;
}
@@ -60,7 +60,7 @@ int main(int argc, char *argv[]){
int address =0;
int mode;
- if (argc!=5){
+ if (argc!=6){
use(argv[0]);
return -1;
}
@@ -72,6 +72,7 @@ int main(int argc, char *argv[]){
vid=strtoul(argv[2],NULL,0);
pid=strtoul(argv[3],NULL,0);
length=strtoul(argv[4],NULL,0);
+ address=strtoul(argv[5],NULL,0);
buffer=malloc(length);
if (!buffer){
-
oh forgot theses
https://community.infineon.com/t5/Knowledge-Base-Articles/Reading-Serial-EEPROM-which-is-Connected-to-the-FX2/ta-p/254704
https://community.infineon.com/t5/Knowledge-Base-Articles/Programming-the-Serial-EEPROMs-on-the-EZ-USB-FX2LP-Development-Kit-Board/ta-p/248738
if some want the cypress suite ... 30 days from now jan 1 2024
Drivers https://ufile.io/qlrlhsx4
Cypress Suite https://ufile.io/6lzy3wri
-
Well two options:
- short SDA line to ground -> FX2LP detects eeprom corruption and boots to VID/PID of 04B4/8613
- use external programmer
The short should work, of course it needs to be removed after the board shows up on USB but before accessing the EEPROM with Cypress software.
Alternatively, I found a 3rd party tool for Linux which reads and writes EEPROM connected to FX2. It can work with any IDs.
https://github.com/ribalda/fx2eeprom
I tried shorting SDA to GND and connecting to USB, letting it start, but it didn't change the VID/PID.
There is a convoluted Windows process involving VisualStudio to change the VID/PID of the drivers, but seemed like too much work.
I think fx2eeprom is the way to go, but I am struggling to get it compiled. I have some Linux VMs, mostly Red Hat 7.9 x64, and have managed to connect the device through to the VM (VMWare on Windows) and lsusb displays the 2 Cypress devices, so promising.
Just struggling to get the fx2eeprom software complied. Installed libusb, had to download and install the rpm libusb-devel, but perhaps it is the newer flavor of Linux I'm using?
I am tempted to bin the thing and just buy a cheapo Sigrok compatible logic proble from Spark Fun.
-
C25 :wtf:
I tried shorting SDA to GND and connecting to USB, letting it start, but it didn't change the VID/PID.
You failed to short it properly. But forget it, I tried with my board and the FX2 simply hangs forever waiting for the EEPROM read to complete and never responds to enumeration requests from the host. Same thing when shorting SCL. My board has a jumper to disable the EEPROM but it works by disconnecting SDA from the chip.
Just struggling to get the fx2eeprom software complied. Installed libusb, had to download and install the rpm libusb-devel, but perhaps it is the newer flavor of Linux I'm using?
This should do it. What happens? What's the libusb version you installed? Was it the same for -devel? ;)
-
Shorting to the ground will not work, since FX2LP needs to see the high level (normally from pull-ups) to start booting. This is why all the cheap Saleae clones use a jumper that breaks the SDA or SCL at the EEPROM and after the pull-ups. On my boards I use test points that change the address of the EEPROM when shorted. This way I don't need a permanently installed jumper.
From the hardware, this board does not seem to have any standard test points / jumpers for that, so cutting the trace may be an option. Or removing the EEPROM and programming it outside of the board.
FX2LP also has the hardware control endpoint vendor request that is always active and I think can be used to recover the device if it is not entirely dead (enumerates at all). On Windows it is a huge pain, sine it needs drivers for random devices. Zadig can help create those drivers.
As far as programming goes, fxload is included in most Linux distros and does not need any compilation. Although it is also weird and uses some vendor hex files for initial programming and i have not used it a lot. But I think it worked fine when I needed it.
There are also two of FX2LP devices and one EEPROM, so I guess the second one is loaded separately somehow.
The board looks like it was done by a drunk monkey.
-
fx2tool works well for accessing the cypress fx2 external eeprom, e.g.
https://www.eevblog.com/forum/testgear/saleae-clone-24mhz-8-channel-la-looses-its-brains/msg4050142/#msg4050142 (https://www.eevblog.com/forum/testgear/saleae-clone-24mhz-8-channel-la-looses-its-brains/msg4050142/#msg4050142)
-
As far as programming goes, fxload is included in most Linux distros and does not need any compilation. Although it is also weird and uses some vendor hex files for initial programming and i have not used it a lot. But I think it worked fine when I needed it.
There are also two of FX2LP devices and one EEPROM, so I guess the second one is loaded separately somehow.
These two chips may be connected to one EEPROM.
To program the EEPROM you always need suitable firmware running on the chip, and that's what vend_ax is. You also need fxload to upload vend_ax to FX2 RAM because the built-in ROM bootloader doesn't support EEPROM programming requests, but it supports downloading other FW to RAM. Once you have vend_ax uploaded fxload is able to overwrite EEPROM, but it cannot read it AFAIK, hence my recommendation to use fx2eeprom instead.
The python stuff above seems to achieve the same effect in one convenient package. Worth trying too.
This is the complete process for dumping 8KB EEPROM with my patched fx2eeprom:
# lsusb
...
Bus 001 Device 102: ID 0925:3881 Lakeview Research Saleae Logic
...
# fxload -I vend_ax.hex -t fx2 -D /dev/bus/usb/001/102
# ./fx2eeprom r 0x925 0x3881 4096 0 >part0
Readed 4096 bytes
# ./fx2eeprom r 0x925 0x3881 4096 4096 >part1
Readed 4096 bytes001/102 are the bus/device numbers and 0x925 0x3881 are VID/PID.
edit
Your 24LC01B EEPROM is 1Kb only, i.e. 128 bytes. So you can read it in one go without patching fx2eeprom. It probably doesn't contain any firmware, only IDs (FW can always be uploaded by host drivers once the device is identified and that's the solution employed by most FX2 users), but if you are unlucky there could be some magic "password" which must be there for USBee's official software to talk to this board, or HW revision information, analog cal data or something like that.
-
To program the EEPROM you always need suitable firmware running on the chip
I know. My issue with the way they implemented it. The need for that external file creates confusion, since there are multiple incompatible versions floating around. There is no reason why that tool can't just include the binary.
fx2eeprom is a fixed function program that ideally should be self-contained.
Not that you need to use it a so it is not a big deal. But at the same time every time you do need to use it, it takes time to figure it out again.
-
Ok, a bit of progress with libusb.
The problem was that I was using the Red Hat libusb distribution and not the one from https://libusb.info/ Once I downloaded and installed 1.0.23 (tried the lastest release but had compilation problems compiling on RHEL 7.9) I was able to compile fx2eeprom without issue.
I will progress trying to read the EEPROM but I need to install fxload.
Will update tomorrow.
-
Hi,
I had a similar problem with the basic USB logic analyser and found I needed to pre-program the attached eeprom.
Code is available here if you want to try that:
https://github.com/podonoghue/LogicAnalyser/tree/master/Software/fx2lafw_eeprom_loader/bin
This is a small part of a bigger project (now sadly neglected) so you may need to download the total ZIP from:
https://github.com/podonoghue/LogicAnalyser/tree/master
and find the bin directly referenced above (or download individual files from the first link - a bit tedious).
This is a basic program to read/write the EEPROM.
I'm not sure how it would handle multiple devices though.
bye
-
Thanks for everyone's help, but had to call time on trying to recover the USBee DX.
I was able to successfully read the ROM from Linux using the tools, and ended up wondering if the problem was greater than just the USB IDs being messed up. Specifically if the ROM was corrupted or overwritten further. In that case the device would have been truly bricked.
The other thing that I had to acknowledge is that USBee's software is hopelessly out of date as the company is no longer in business.
My current (no pun intended) project involves working with the USB-C power delivery Configuration Channel protocol, which Sigrok Pulseview can decode. I ended up buying a Sparkfun Logic Analyzer for just under $30 CAD and managed to to get it working with Sigrok Pulseview. I was up and running with decoding the CC bus in a fraction of the time I spent trying to salvage the USBee DX.
The value of the USBee was always the software, and not so much the hardware which, as you can see from the pics, is just an FX2-based device, not unlike the cheap FX2 device from Sparkfun.
So, a sad end to something I paid a lot of money for back in the day, but my requirements have always been limited to serial bus decoding which I can do with Pulseview. Anything more sophisticated is handled by my Tektronix oscilloscope so no need for a PC oscilloscope, let alone 16 digital channels.
Again, thanks for everyone's help.
-
Hmm, wouldn't this thing work with Sigrok if you program some known IDs and knock out the analog FX2? Or even leave the analog alone and just remember to bind Sigrok to the digital side. I hope Sigrok supports selecting from multiple identical interfaces?
edit
Good chance of it working, IMO. Look at your pics, the digital FX2 is connected directly to the inputs, there is nothing there to set up outside the chip itself.