I have a commercial webcam based on EZUSB - FX2. I still want to use the camera, so i don't want to make any changes (like disconnecting the seeprom). I hoped that using the vendor command A0 i could bypass the "C2" SEEPROM. I'm able to upload my code and have it running. It seems that after i take the cpu out of the reset i cannot disconnect and reconnect the device by "bmDISCON". That is, the device disconnects, but it NEVER reconnects. Is this behaviour caused by the SEEPROM?
If you can't fix the reconnect issues, you can mutilate the camera by overwriting the first byte of the EEPROM. This will put the FX2 into default mode and also eliminate any possible side-effects from the camera driver (won't get loaded without the PID). Once you're done with your job, you can restore the original first byte from your backup, and the camera is good as ever.
yeah, that's what i was thinking of lately. I tested the i2c routines today (reading the first 8 bytes of the eeprom) and i also found out that the Write Protect pin is floating (not 100 percent sure). Besides, if i overwrite the first byte with "C0" i don't have to update the my driver's Vid/Pid. But what happens if i let the default usb device handle the requests (RENUM = 0), am i able to handle vendor requests? It doesn't seem so. The TRM manual doesn't say i can but it doesn't say i can't either.
Well, i didn't need to change the eeprom. Suddenly (with RENUM = 0) i saw that the vendor, command issued by the driver, was finally accepted and i got back the test string that i embedded into the code. Unfortunately, it only worked every now and then. But this confirmed that when the Defualt USB Device is in control, the firmware receives custom setup packets. (a3load example should also confirm that) In the end, i probed the device a lot, till it had enough and ALSO refused to load the driver. Maybe it was its way to give me the solution. I made a clean reinstallation of the driver (not just copying the ".sys" to the system folder) and now the vendor command doesn't skip a beat. Unfortuantely, this is one of those solutions that doesn't add much to the reasons why it didn't work before. As always, i expect (headaches) some other issue that will put some light on the real reason why.
PS. By changing and restoring the serial code in the eeprom, i also made sure i could do write operations.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.