Hi
The corrections have been applied. I hope I did not forget anything.
The main changes : - reset is a jumper - bootloader switch added - 100k resistors used (instead of 4.7k, I hope it does not break anything) - jack connector added (for the debug) - WP from flash connected - USB voltage regulator TPS73633 used (lower capacitance) - USB buffer used instead of the openPCB solution (thus no pull-up and reset connection). saves space and complexity - pin renamed - QS3244 instead of QS3245 used, I/O and other pins are controlled separately - ...
To make the changes I used the AT91SAM7X-EK Evaluation Board User Guide. The overall capacitance is reduced, but I think the 22uF for the battery should be kept.
files : https://gsm.tsaitgaist.info/SIMtrace/v0.7/
good luck, Kevin
On Sun, May 08, 2011 at 05:00:59PM +0200, Kevin Redon wrote:
Hi
The corrections have been applied. I hope I did not forget anything.
thanks a lot.
The main changes :
- reset is a jumper
just to be precies: it's the TEST pin, not RESET (schematics is ok!)
- bootloader switch added
see my comment from the last mail
- 100k resistors used (instead of 4.7k, I hope it does not break anything)
yes, it should work. and if we run into problems, it's very easy to solder different resistors to the same footprint.
- jack connector added (for the debug)
- WP from flash connected
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.
- USB voltage regulator TPS73633 used (lower capacitance)
Ok, let's try that one.
- USB buffer used instead of the openPCB solution (thus no pull-up and
reset connection). saves space and complexity
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.
- QS3244 instead of QS3245 used, I/O and other pins are controlled
separately
great.
corrections added : https://gsm.tsaitgaist.info/SIMtrace/v0.7+/
- bootloader switch added
see my comment from the last mail
pull-down added
- jack connector added (for the debug)
- WP from flash connected
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.
pull-down added
I am not familiar with USB buffers? How do they work?
It's not a buffer (just me not knowing what I do). It's just and emi filter, replacing the R and C for the USB.
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.
That is the part I never understood in openPCD. What was the purpose of USB_PUP ? Now I understand (finally). Thus I did the same as openPCD now.
Waiting for next corrections, Kevin
I am not familiar with USB buffers? How do they work?
It's not a buffer (just me not knowing what I do). It's just and emi filter, replacing the R and C for the USB.
For those interested : http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-374...
On Mon, May 09, 2011 at 10:41:23AM +0200, Kevin Redon wrote:
I am not familiar with USB buffers? How do they work?
It's not a buffer (just me not knowing what I do). It's just and emi filter, replacing the R and C for the USB.
For those interested : http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-374...
looks fine, especially as it includes ESD protection.
filter, replacing the R and C for the USB.
For those interested : http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-374...
looks fine, especially as it includes ESD protection.
should I use this IC (saves place and complexity, costs as much), or should I leave as it is (like openPCD)
Hi Kevin,
On Mon, May 09, 2011 at 10:35:54AM +0200, Kevin Redon wrote:
corrections added : https://gsm.tsaitgaist.info/SIMtrace/v0.7+/
Ok, this looks fine to me now, I think you can go ahead with component placement + routing. Feel free to post links to the gerber (or rendered to PDF) once you have it.
I'll take care of ordering the prototype PCBs (and the BOM from digikey) once the gerber is finalized.
Regards, Harald
-
Harald Welte -
Kevin Redon