On Sun, May 08, 2011 at 05:00:59PM +0200, Kevin Redon wrote: thanks a lot. just to be precies: it's the TEST pin, not RESET (schematics is ok!) see my comment from the last mail yes, it should work. and if we run into problems, it's very easy to solder different resistors to the same footprint. great. Does the SAM7 have an internal pull-down on nWP? If not, we should add one, just to be sure the power-up default state is LOW. Ok, let's try that one. I am not familiar with USB buffers? How do they work? I couldn't find a data sheet for USBBUF02 or USBBUF02W6. Also, I don't see how this solves the problem, sorry. Some more explanation: When the AT91SAM7 is reset (software-reset or hardware-reset), it needs to generate a USB bus reset in order to tell the host PC to re-enumerate. This is required as the SAM7 has no information about the USB protocol state before the ARM CPU was reset. The other reason is: When we switch from DFU into normal mode (or the other way around), we again need to be able to issue a USB reset from software (via GPIO) and ask the host to re-enumerate. This is required as we expose different interface/configuration descriptors depending on DFU / normal mode. So I don't really see a choice but to have a software-controlled USB reset option. Once again, we know that this part is working in OpenPCD 0.4 (we had a couple of earlier versions, and they all had some shortcomings). It's really useful to have both the nRESET as well as the GPIO controlled usb-pullup (called UDP_PUP) in OpenPCD. If we don't do this properly, we will have to disconnect/reconnect the device from USB very often. Doing this from software is much easier and fail-proof. great. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)