FX2 and EEPROM

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?

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

Regards,
Marc

<jetmarc@hotmail.com> wrote in message
news:1177957952.262042.132080@n76g2000hsh.googlegroups.com...
> > 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.
>
> Regards,
> Marc

Great, Marc

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.

"runner" <emb@dded> wrote in message
news:463660e8$0$4795$4fafbaef@reader4.news.tin.it...
> <jetmarc@hotmail.com> wrote in message
> news:1177957952.262042.132080@n76g2000hsh.googlegroups.com...
> > > 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.
> >
> > Regards,
> > Marc
>
> Great, Marc
>
> 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.