Warning about USBee

[ataradov]

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.

[voltsandjolts]

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

[magic]

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:

Code: [Select]

# 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.

[ataradov]

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.

[comox]

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.

[pgo]

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

[comox]

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.   

[magic]

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.