low cost USBi programmer using cypress CY7C68013A board

I too have experienced some really wobbly performance with the CY7/Free-USBi solution. After some installing/deleting/reinstalling/power cycling, I got it talking and could realtime control a ADAU1701. But now, my win7/32 setup fails to recognise the USB device. Forcing a driver reinstall just leads to "Can't start device" messages. Have I blown my EZ-USB board??
 
I too have experienced some really wobbly performance with the CY7/Free-USBi solution. After some installing/deleting/reinstalling/power cycling, I got it talking and could realtime control a ADAU1701. But now, my win7/32 setup fails to recognise the USB device. Forcing a driver reinstall just leads to "Can't start device" messages. Have I blown my EZ-USB board??


Win7/32 ?
Sigmastudio and the drivers are 64 bits...
This might be the problem.
 
Don't worry, It's works fine.

Just a nitpick. The Cypress boards are usually 3.3V boards. And the cheap ADAU1466 currently sold on Aliexpress and eBay are also 3.3V IOVDD, so as CyberPit says, it all works fine.

But the ADAU1466 can use either 1.8V or 3.3V IOVDD. When IOVDD is 1.8V, the programming pins can accept 1.8V only. Using 3.3V programmers on a 1.8V board will damage the ADAU1466

The Analog Devices USBi programmer can be switched between 3.3V and 1.8V, depending on the target device. The cheap CY7C68013A boards cannot, and only work at 3.3V

As a matter of fact, the original Analog Devices USBi uses the CY7C68053 56BAXI device, while the cheap boards use the CY7C68013A. The former can work at 1.8V to 3.3V, the latter only 3.3V

So, while it's perfectly safe for now to use the cheap Cypress boards or the FreeDSP one, if in the future ADAU1466 boards using 1.8V become available, those won't be safe to use with the cheaper options (unless someone uses a level shifter for the programming pins, which is not hard to do)
 
For anybody that wants to try this programmer using SPI:

SS = PA2
MOSI. = PA0
SCLK = PA7
MISO = PA1



I have it connected to an ADAU1466 core board and it has been 100% reliable writing through to eeprom.

SigmaStudio settings as in pic.

All credit to Rocha for this info
 

Attachments

  • IMG-20210507-WA0002.jpg
    IMG-20210507-WA0002.jpg
    397.7 KB · Views: 509
If you change the pull-up resistors as shown in the attachment the boards can be left connected and powered up simultaneously or separate. No need to disconnect or power up individually.
The DSP will boot from EEPROM and the programmer will be detected correctly.

For anyone else reading this thread: I tried changing the resistors and it makes no difference. Looking at the circuits, the SDA/SDL lines are used by both the CY7C68013A and the ADAUxxxx. And both try to access the same lines at boot time, creating a conflict. Changing the pullups doesn't make a difference.

As a matter of fact, both boards have 10k pullups, so when connected together, the resulting pull up value is ~5 kOhm, which is a bit high for an I2C bus at 3.3V. When changing the ADAU board pull ups to 4.7kOhm, the resulting pull up is 3.2kOhm, which is a better value. With 2.2kOhm, the resulting value is 1.8kOhm, which is even better, according to the TI app note (https://www.ti.com/lit/an/slva689/slva689.pdf?ts=1620582343503)

So, change the resistors if you want, it will not harm anything and actually make things better for high speed I2C communication, but it cannot solve the original problem of having shared I2C lines accessed by 2 masters at the same time.

The only way to actually solve it would be to add a circuit that interrupts the communication on SDA/SDL between the 2 boards for a second when power is applied, so that each I2C bus can allow the flash content to be loaded independently. The FreeUSBi circuit does that. Otherwise simply power on the boards separately, then connect the SDL and SDA lines
 
Hi Guys,
for those willing to access the SigmaDSP from SigmaStudio without using an USBi interface, there is a possibility by creating an USB device with a generic "Vendor Specific Class (0xFF)" as long as you support the following "Vendor Commands":

B2 : Write a list of bytes at a given memory address, for a given I2C or SPI device.
B4 : Read a list of bytes at a predefined memory address, for a given I2C or SPI device.
B3 : Set the predefined adress for command B4
B5 : finalize a B2 transaction
B6 : finalize a B4 transaction

Thanks for the information.

I wrote a Python package to:
  • Use USBi as a general-purpose USB-I2C converter.
  • Control I2C devices from PC.
Please see USBi tools box.
 
  • Like
Reactions: 1 users
Since it makes USBi a general-purpose USB-I2C converter, it can read any I2C device, including its own EEPROM.

I just make this repository private. Sorry!
I'm not quite sure why you think that reading the FX2LP EEPROM is a problem... It has been done multiple times before, and programs to dump and reflash the EEPROM are widely available, e.g. https://github.com/podonoghue/LogicAnalyser/tree/master/Software/fx2lafw_eeprom_loader and https://time4ee.com/news.php?readmore=453. Cypress documents how to do it in their SDK

You should share your repository again, since it can help people do something useful (generic I2C) and doesn't expose anything that is not already widely documented
 
I'm not quite sure why you think that reading the FX2LP EEPROM is a problem... It has been done multiple times before, and programs to dump and reflash the EEPROM are widely available, e.g. https://github.com/podonoghue/LogicAnalyser/tree/master/Software/fx2lafw_eeprom_loader and https://time4ee.com/news.php?readmore=453. Cypress documents how to do it in their SDK

You should share your repository again, since it can help people do something useful (generic I2C) and doesn't expose anything that is not already widely documented
Then, I'm not quite sure what this thread is all about. Since one can make a clone of USBi very easily for about four dollars.

Thanks for your info and advice though.
 
Last edited:
Then, I'm not quite sure what this thread is all about. Since one can make a clone of USBi very easily.

Thanks for your info and advice though.
This thread, which started in 2015, is about using a cheap board (<$5) from Aliexpress/eBay to program any of the ADAU DSPs. What is common knowledge today, was not 7 years ago. And in any case, not everyone looks in the same places when searching, so an explanation on how to use a cheap board (instead of building a more expensive USBi clone) is always good to have

:)
 
This thread, which started in 2015, is about using a cheap board (<$5) from Aliexpress/eBay to program any of the ADAU DSPs. What is common knowledge today, was not 7 years ago. And in any case, not everyone looks in the same places when searching, so an explanation on how to use a cheap board (instead of building a more expensive USBi clone) is always good to have

:)
I see.
Sharing my package will expose the firmware of USBi. I should consider it carefully.
 
I see.
Sharing my package will expose the firmware of USBi. I should consider it carefully.
I start thinking that you have not read the thread you are posting in. Because, if you did, you would have seen that the USBi firmware is attached as a file :) it's also widely shared elsewhere. Reading the content of an I2C EEPROM is really trivial, can be done using the Cypress tools, a cheap EEPROM programmer and a couple of clips on the IC itself, or even finding the binary content in the files distributed by Analog.

What you have done is helpful on its own as a USB to I2C bridge. And, as much as I always appreciate people being careful about companies' intellectual property, there are zero concerns about Analog's IP being exposed above and beyond what is already very commonly available.

Having said that, it's your work, your code, and your decision to share it or not. But you are not exposing anything that is not widely available already
 
I start thinking that you have not read the thread you are posting in. Because, if you did, you would have seen that the USBi firmware is attached as a file :) it's also widely shared elsewhere. Reading the content of an I2C EEPROM is really trivial, can be done using the Cypress tools, a cheap EEPROM programmer and a couple of clips on the IC itself, or even finding the binary content in the files distributed by Analog.

What you have done is helpful on its own as a USB to I2C bridge. And, as much as I always appreciate people being careful about companies' intellectual property, there are zero concerns about Analog's IP being exposed above and beyond what is already very commonly available.

Having said that, it's your work, your code, and your decision to share it or not. But you are not exposing anything that is not widely available already
  • I did read the thread, but I didn't realize that the "24aa256.bix" file IS the binary image of USBi's EEPROM, till now. I thought it was a firmware written by someone and contributed to community as an alternative solution, since people were talking about script and driver at the first beginning.
  • The "24aa256.bix" is very different from what I read from my USBi's EEPROM though.
  • I will consider your suggestion, sincerely. Thank you !
 
Hi guys,
not sure if this is still relevant but Ive been thinking about using a MCP2210 for SPI programming an ADAU1451, as it comes with pre-installed (HDI) driver + there is a cute little interface board with this chip available (https://www.digikey.ch/en/products/...1204/4495407?s=N4IgTCBcDaILYGMAOYwEYAMIC6BfIA). Also, there is a utility from Microchip which allows customizing the PID and VID as well as the strings in both RAM and internal EEPROM.

I am still not sure if this really works (as the origial USBi eval board is another device class and has more, external ROM), but as that interface board was only 13 CHF (Yes Im Swiss, sorry for any misspellings etc.) Ive ordered it and gave it a try.

After changing the PID and VID to VID_0456 & PID_7031 (didnt work in the first run, had to do it twice) + Manufacturer and Device desc. to "Analog Devices" and "Analog Devices USBi Driver" and restarting SigmaStudio it showed up again as "Analog Devices USBi (programmed)" under USB-Controllers so it seems like it was re-programmed by SigmaStudio (which is was the original chip requires). In Sigmastudio, the USBi interface box also shows up green, even after start up. So essentially, Ive successfully tricked SS into thinking this thing would be the ADUSB2EBZ board.

I still dont know if this actually works (as I first have to make the dsp board etc.) but so far so good.
If anyone has suggestions or knows if this def. will not work feel free to share!