Cypress CY7C68013A running Saleae firmware¶
Plausible explanation added 20130428¶
Thanks for the post, it helped me try out Saleae’s software on my dev board (the same LCSoft-branded board as pictured). I used Saleae 1.1.15, an AT24C04 hooked to the SCL and SDA headers, and no desoldering, just leaving jumper J1 on. I’m not really comfortable using Saleae’s software without paying for it, but it was a fun exercise.
I don’t think the I2C speed of the EEPROM is the problem, having looked at a photo of the inside of a real Saleae. The real thing has a Microchip 24LC00 (as U1, marked M0AS), which supports 100kHz at 2.5V+ and 400kHz at 4.5V+ (the Saleae is at 3.3V). The AT24C128 supports 100kHz at 1.8V+, 400kHz at 2.5V+ and 1MHz at 5V+. So the AT24C128 supports the same speeds or higher as the real thing. It’s not like they can check for lack of support for a speed in the real thing either, since those are minimums and it’s always possible an especially good batch of genuine EEPROMs will be able to manage 400kHz at 3.3V.
I also hooked up a BusPirate and sniffed the I2C traffic on loading the Saleae software, it was accessing 0xA0, or entering an endless loop to try to access 0xA0 when 0xA0 wasn’t available, and I think it was all occuring at 100kHz but I’m not sure if the BusPirate will also sniff 400kHz traffic while in 100kHz mode.
I’m pretty sure the key is in the difference between EEPROMs with 8-bit memory addressing (24C00-24C16) and ones with 16-bit memory addressing (24C32-24C256+). The CY7C68013A can use either kind as a boot rom, but it requires that EEPROMs with 8-bit addressing be located at 0xA0 on the I2C bus, and ones with 16-bit addressing be located at 0xA2 if they’re to be used as a boot rom. Check out the EZ-USB Technical Reference Manual (on Cypress’ site) in section 3.2 “EZ-USB Startup Modes” and section 13.6 “EEPROM Boot Loader”.
The Saleae’s 24C00 is 8-bit, and therefore must be located at 0xA0 to be enabled as a boot ROM. The Saleae drivers check that this is the case, and when they “ReadEeprom” they really are trying to read an EEPROM at 0xA0, and checking that it responds to an 8-bit address request. I hooked up a Bus Pirate to sniff, and this is what’s happening, and it’s at 100kHz too (I think).
The dev board has a 16-bit 24C128, so if you use it as a boot rom it must be located at 0xA2 and the driver won’t find anything at 0xA0 when it checks. There’s a jumper (J1) which lets you move it between 0xA0 and 0xA2, but it must be at 0xA2 (jumper on) for the CY7C68013A to use it as the boot rom (and read the Saleae VID and PID off of), and even if you move it to 0xA0 (jumper off) after windows has added the device but before Saleae checks it, the Saleae drivers will still notice it’s a 16-bit EEPROM, not an 8-bit one (it won’t respond to 8-bit reads). The jumper is useful if you want to use it as a real development board, though, since it lets you move the eeprom to 0xA0 and boot the device as a default cypress device while still being able to use the CyConsole software to reprogram the EEPROM (at 0xA0) with no outside programmer needed. Then you put the jumper back on and hit reset and it boots off the reprogrammed EEPROM. But it doesn’t help with trying to clone a Saleae.
What you have done by adding the 24C16 is make an 8-bit EEPROM be located at 0xA0 (regardless of what you do with the A0 pin. None of the 24C16′s address pins are actually connected inside, you can’t change its I2C address because it already is using all available I2C EEPROM addresses to make all of its memory available in 8-bit form). I’m not sure why you didn’t get the ST -16 to work, though an old datasheet I found online suggests that it has write protect pins instead of address pins, so maybe you were write protecting it? Or maybe there is more than just the 8-bit, at 0xA0, requirement.
It’s not actually necessary to desolder the existing 24C128, BTW. If you leave the J1 jumper on, the 24C128 is at 0xA2, leaving the 0xA0 address available and unconflicted for you to add any 8-bit EEPROM to the SCL and SDA lines. The CY7C68013A seems to boot from 0xA0 first, if available, so you can even use a multiple-address 8-bit EEPROM like the -16 which has secondary addresses that conflict with the -128. The secondary address won’t be usable by either chip anymore, but that’s ok because 0xA0 is all that the Cypress needs to boot and all that the Saleae needs to check.
I suppose a later version of the Saleae drivers will do a check on the actual size of EEPROM available, to make sure it’s no bigger than the 128-bit 24LC00 chip they’re using (unless they use multiple size EEPROMs based on cost at time of manufacture), and it might also check that no other I2C EEPROM addresses respond. They might also want to check the REVID register on the CY7C68013A, since I bet a lot of these ebay CY7C68013″A” development boards have an old CY7C68013 which has been sanded down, blacktopped, and relabelled as an -A revision. Of course, reading Saleae’s blog it sounds like they might have a problem with counterfeit chips sneaking into even the genuine products.
The USBee and Saleae Logic/Logic16 boards are pretty much a clone of the Cypress eval board. The chip reads from an I2C EEPROM on bootup to grab the PID/VID/DID and version which it then uses to present itself to the host. The first byte is a control/config byte for the CY7C68013 to determine what to do with the EEPROM contents, the next two are the VID, then PID, then DID, then the last byte is a config byte that controls USB speed and whether to come out of reset or not. See the Cy7C68013 datasheet for more info.
Saleae uses the Cypress PID/VID of 0925:3881 (suspect the DID of 0x001b is also important)
USBee uses 08a9:0005 for the ZX and :0009 for the SX (DID of 0x2384)
The EEPROM on the eval board is an AT24LC128. The EEPROM has it’s high address bit connected to a jumper which pulls it to '1’, making the memory appear at 0xa2 or 0xa0 depending on the jumper. Only the first 8 bytes are used by Cypress. You can use their USB Suite along with the vend_ax.hex firmware image so that you can do a vendor command to read/write the EEPROM. You can also just use the bus pirate, which is what I ended up doing in the end. The EEPROM seems to have to be at I2C address 0xa2, even though the Cypress part looks at 0xa0 as well. There are two or three address pins on the EEPROM itself to configure the I2C address.
The very first byte loaded determines how the EEPROM is used. 0xc0 = load VID/PID/DID only, 0xc2 = load firmware from EEPROM.
The larger EEPROMs use two bytes for the memory address to read/write, and the smaller ones use only one byte. This comes in important later. See the datasheets for the I2C memory for read/write command formats.
Using the bus pirate in I2C mode you can program it thusly:
1. Saleae Logic
[0xa2 0x00 0x00 0xc0 0x25 0x09 0x81 0x38 0x84 0x23 0x00]
SX: [0xa2 0x00 0x00 0xc0 0xa9 0x08 0x09 0x00 0x84 0x23 0x00] DX: [0xa2 0x00 0x00 0xc0 0xa9 0x08 0x15 0x00 0x00 0x00 0x00] EX: [0xa2 0x00 0x00 0xc0 0xa9 0x08 0x09 0x00 0x04 0x00 0x00]
You can use this to read back what you wrote to make sure it took (I2C can be flaky, watch the status screen for NACKs)
[0xa2 0x00 0x00 [ 0xa3 r:8]]
Getting around Saleae’s anti-counterfeiting¶
Older versions of the Saleae software don’t check for counterfeit boards. Unfortunately I don’t have any old copies of their software, and the 'net doesn’t have anything but old copies of the Windows software. Using the bus pirate in I2C sniffer mode you can see that once the Saleae firmware is downloaded (by the Logic app) the firmware takes a closer look at the serial EEPROM:
[0xA0+0x08+[0xA1+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF-] [0xA0+0x08+0xA4+][0xA0+0x09+0x62+][0xA0+0x14+][0xA0+0x0B+0x3D+] [0xA0+0x0C+0xE1+][0xA0+0x0D+0x6B+][0xA0+0x0E+0x88+][0xA0+0x1E-] [0xA0+0x08+[0xA1+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF-]
As you can see it tries to access a smaller EEPROM (one byte memory address) at address 0xa0 and reads in 8 bytes starting from offset 8 (in my case, reading all 0xff). Then it writes 0xa4 0x62 0x14 0x3d 0xe1 0x6b 0x88 0x1e, and reads back the data it wrote. In the capture above, the write didn’t work, and the app crashed.
Saleae’s firmware wants a small EEPROM at address 0xa0. The Cypress part seems to require a larger EEPROM at address 0xa2. I tried putting a smaller memory part on the board and programming its PID/VID but the Cypress part never accepted it at 0xa0. I must have buggered something up, since it’s very doubtful that Saleae’s units have two EEPROMs, or maybe there is some pin strapping option on the Cypress part to correctly read the PID/VID from a smaller-memory device at 0xa2 or 0xa0.
What I did was to solder a smaller EEPROM on the board, so there are two. the 24LC128 at 0xa2, and a smaller EEPROM with its A2/A1/A0 pins connected to a jumper that pulls them up to '1’. This puts the smaller device at 0xac or 0xad, depending on whether the device has a working A0 pin or not. This seems necessary since the Cypress part looks at 0xa0 and gets a valid response but can’t seem to read the PID/VID correctly. So what I do is plug the jumper in to move the smaller EEPROM out of the way, connect the eval board to the computer and once it enumerates (reading the PID/VID from the larger EEPROM at 0xa2) I pull the jumper out which moves the smaller EEPROM into 0xa0. Now when the Logic firmware downloads, it can see a small device at 0xa0, tries to read the memory, if it’s good, it reports success and if it’s not good, writes good data, verifies it and reports success. It’s a bit of a dog’s breakfast but it works well enough for now.
I suspect that Saleae’s hardware has the A2 address bit pulled high and connected to a Cypress port pin. When the Saleae firmware loads, it pulls the port pin low, changing the address of the EEPROM, and then does the memory check to see if it’s an official Saleae part. With some probing around I’m sure I can get this to work without screwing about with the jumper solution and two EEPROMs that I have now.
Historic: Using the Cypress tool to change the PID/VID¶
- Uninstall the Saleae Logic Driver, using Device Manager.
- We want to install the generic cyusb.sys Cypress driver which will allow us to send commands to the device using CyConsole. If you’re using Win XP, goto step 3. Else, download Cypress Suite USB (CySuiteUSB_3_4_7_B204.exe) which contains the Win7 x64 driver.
- Locate the appropriate cyusb driver. For Win 7 x64, this is: C:\Cypress\Cypress Suite USB 3.4.7\Driver\bin\wlh\x64. For Win XP, we can use the older version of the driver, found in the Dev Kit package, here: C:\Cypress\USB\Drivers\CyUsb.
- Open cyusb.inf. This must be modified to contain the VID/PID of our clone (which is also the VID/PID of the Saleae Logic), so that Windows will accept and install the driver CyUSB. So, replace all instances of USB\VID_XXXX&PID_XXXX with USB\VID_0925&PID_3881 (note that the VID/PID of the device can be found in device manager). Also, make sure to uncomment (remove the semi-colon) the lines looking like this: “%VID_0925&PID_3881.DeviceDesc%=CyUsb, USB\VID_0925&PID_3881″.
- If you’re Running Windows 7 (and also Vista, I think), you’ll need to force Windows to accept installing unsigned kernel drivers. To do so, restart your computer and press F8 during the boot process, as you do to start in safe-mode. However, instead of selecting safe-mode from the boot menu, select ‘Disable Driver Signature Enforcement’. Note that this is temporary – the driver won’t remained installed after a reboot. This is fine for our purposes.
- Install the CyUSB driver.
- Start CyConsole.
- Select ‘EZ-USB Interface’ from the Options menu.
- Press the ‘Download’ button. This allows us to upload our own firmware.
- Select the file C:\Cypress\USB\Examples\FX2LP\Vend_ax\Vend_Ax.hex. You should see the firmware being uploaded and the 8051 will be reset.
- Let’s first read our current EEPROM contents:
- Enter ’0xA2′ into the ‘Req’ box next to the ‘Vend Req’ button.
- Set ‘Length’ to 8
- Make sure ‘Dir’ is set to ’1 IN’
- Now click ‘Vend Req’. You should see 8 bytes of Hex codes starting with ‘C0′. My device read out: ‘C0 25 09 81 38 1B 00 00′. Note the VID (09 25) and PID (38 81) are stored in little-endian format. C0 is required by the Cypress chip. I am unsure what 1B is for.
- Now let’s program the VID/PID of the USBee ZX into our EEPROM:
- Enter the bytes ’C0 A9 08 05 00 84 23 00′ into the ‘Hex Bytes’ field.
- Now change the ‘Dir’ box to ’0 OUT’
- Click ‘Vend Req’. The bytes written will be echoed back to the console.
- That’s it! Make sure your have the USBee Suite installed along with the ZX test pod. Pull out the device, plug it back in and it should be recognised by USBee as the ZX model.
So, while not as easy as switching a few jumpers, the device can be made to look like a USBee ZX without too much effort. I believe that the USBee driver is just a signed version of the CyUSB driver, which means that the device is recognised by CyConsole (as opposed to the Saleae driver, which seems to be modified such that the device doesn’t show up in CyConsole, hence the rigmarole of installing CyUSB above). This means that changing back to Saleae Logic is as simple as following steps 7 to 12, but programming with our original bytes ‘C0 25 09 81 38 1B 00 00′.
Historic: history of the CY7C68013A bought on ebay¶
Just talks about the support files that he doesn’t provide a link to, that the logic analyzer uses PB0-PB7 for the 8 analyzer pins, etc., look at the Logic driver .inf file to get the Logic16 PID/VID (although the Logic16 has an FPGA between the I/O and Cypress chip and the Cypress chip is faster/bigger), etc.