Hi,
here the schema. all the components are on it, but I don't know if the electrical part is right. Any comments/advices are welcome.
schema : https://gsm.tsaitgaist.info/SIMtrace/v0.6/SIMtrace.ps source (KiCAD) : https://gsm.tsaitgaist.info/SIMtrace/v0.6/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Kevin.
here the schema. all the components are on it, but I don't know if the electrical part is right. Any comments/advices are welcome.
schema : https://gsm.tsaitgaist.info/SIMtrace/v0.6/SIMtrace.ps source (KiCAD) : https://gsm.tsaitgaist.info/SIMtrace/v0.6/
I took a look at your shema, here are my thoughts:
The SC_SW line controls all analog switch pins. I think you should be a bit more selective here. To create a situation like this for example:
VCC, RST, CLK are connected through and I/O is connected to the man in the middle who can manipulate the traffic in realtime.
I have looked at the QS3245 datasheet. It has only one OE input pin ;-/
With your current design you will have do generate the smartcard clock yourself, you could use the clock from the target (with care!) when you can switch at least I/O seperatly.
You can leave the VPP away, it is deprecated. (save PCB-Space ;-)
Maybe you can leave Jtag away (save even more PCB-Space ;-) the AT91SAM7 series have fancy bootloaders - but maybe you will need the JTAG for debugging so it is your decision.
You should give the BATT-PWR/USB-PWR construct a short test. Maybe it is problematic when one power source drives into another that is switched off.
regards. Philipp
- -- ______________________________________ Philipp Fabian Benedikt Maier
philipp.maier@runningserver.com Funk: DO5DXT http://www.runningserver.com http://www.diskettenschlitz.de ______________________________________
Hi Kevin,
thanks for posting your most recent schematics.
On Sat, May 07, 2011 at 10:12:23PM +0200, Kevin Redon wrote:
here the schema. all the components are on it, but I don't know if the electrical part is right. Any comments/advices are welcome.
1) Regarding dexters mail: I defintely would want JTAG, it helps a lot for debugging. We don't have to solder the connector for production units after R&D has finished.
2) It might be an idea to use a 2.5mm jack (like Compal phones) for the DBGU, instead of the FTDI-6pin-header. I guess more people in and around the Osmocom projects have a T191 cable than a FT232 cable with the 6-pin header. What do the others think? It may be worth putting both footprints (for the 6-pin cable and the 2.5mm jack) on the PCB. This way we can later still decide which one to place on the board.
3) It might be nice to have an ADC input connected to the VCC_OUT line, to be able to measure the SIM card supply voltage as it is output by the phone. ADCREF of course would have to be connected, too.
4) It is generally good 'style' to connect the nWP to some I/O line of the CPU (together with a pull-down). This way the memory is write-protected by default. Only if the CPU sets the GPIO to high, it can write to the flash.
5) I think the IN/OUT naming is a bit misleading. E.g. "VCC_OUT" is the source of the VCC power, i.e. the phone. It may be better to call the signals leading to the phone {VPP,I/O,CLK,RST,VCC}_PHONE and the signals leading to the sim {VPP,I/O,CLK,RST,VCC}_SIM
6) The USB pull-up mechanism is missing. This is required for properly signalling a USB bus reset to the host controller. Please refer to the OpenPCD schematics for an example circuit. It just requires one transistor and some resistors. It has also proven useful to connect the nRESET to that pull-up circuit to make sure a cpu-reset leads to a bus reset as well.
7) A 5.6V Zener diode makes sense as over-voltage protection at the USB 5V power supply line
8) The two 47uF capacitors at the 3.3V line and the 22uF capacitor at the 5V line might be above the USB specifications for capacitive load. See Section 7.2.4.1 of the USB spec, where I believe it says you can only put a cumulative capacitance of 10uF at the downstream end of a Vbus. We might ignore that, or use something like a LM3525 (or even a TI TPS2151 which is a LDO with built-in in-rush current limiter). OpenPCD1 v0.4 is not being sold anymore exactly due to this problem.
9) I would only use a jumper for the TEST singal, as we probably only need it very rarely during sam7dfu testing/porting. After that, we will use USB DFU for updates
10) However, it is useful to have a push-button for DFU-mode activation, this is a simple switch between Vcc and a GPIO. Normally, DFU is activated over USB itself. However, if the firmware is dead, this BOOTLOADER switch can help with recovery (once again, see OpenPCD)
Regards, Harald
Thanks for the fast analysis
- It might be an idea to use a 2.5mm jack (like Compal phones) for the DBGU, instead of the FTDI-6pin-header. I guess more people in and around the Osmocom projects have a T191 cable than a FT232 cable with the 6-pin header. What do the others think?
I would choose jack 2.5 only, but I will put both.
- It might be nice to have an ADC input connected to the VCC_OUT line, to be able to measure the SIM card supply voltage as it is output by the phone. ADCREF of course would have to be connected, too.
I will add it.
- It is generally good 'style' to connect the nWP to some I/O line of the CPU (together with a pull-down).
ack
- I think the IN/OUT naming is a bit misleading. E.g. "VCC_OUT" is the source of the VCC power, i.e. the phone. It may be better to call the signals leading to the phone {VPP,I/O,CLK,RST,VCC}_PHONE and the signals leading to the sim {VPP,I/O,CLK,RST,VCC}_SIM
ack
The USB pull-up mechanism is missing. This is required for properly signalling a USB bus reset to the host controller. Please refer to the OpenPCD schematics for an example circuit. It just requires one transistor and some resistors. It has also proven useful to connect the nRESET to that pull-up circuit to make sure a cpu-reset leads to a bus reset as well.
A 5.6V Zener diode makes sense as over-voltage protection at the USB 5V power supply line
I will have a look for it
- The two 47uF capacitors at the 3.3V line and the 22uF capacitor at the 5V line might be above the USB specifications for capacitive load. See Section 7.2.4.1 of the USB spec, where I believe it says you can only put a cumulative capacitance of 10uF at the downstream end of a Vbus. We might ignore that, or use something like a LM3525 (or even a TI TPS2151 which is a LDO with built-in in-rush current limiter). OpenPCD1 v0.4 is not being sold anymore exactly due to this problem.
didn't know than, I will change the ld1117 with a tps73633 (less expensive then TPS2151, and fits perfectly). I don't understand why the capacitor at the 3.3v line affect USB, but I will minimize it.
- I would only use a jumper for the TEST singal, as we probably only need it very rarely during sam7dfu testing/porting. After that, we will use USB DFU for updates
ack
- However, it is useful to have a push-button for DFU-mode activation, this is a simple switch between Vcc and a GPIO. Normally, DFU is activated over USB itself. However, if the firmware is dead, this BOOTLOADER switch can help with recovery (once again, see OpenPCD)
I will take the openPCD design
Regards, Harald
WiP, Kevin
Hi Kevin,
On Sun, May 08, 2011 at 01:40:46PM +0200, Kevin Redon wrote:
- It might be an idea to use a 2.5mm jack (like Compal phones) for the DBGU, instead of the FTDI-6pin-header. I guess more people in and around the Osmocom projects have a T191 cable than a FT232 cable with the 6-pin header. What do the others think?
I would choose jack 2.5 only, but I will put both.
ok, thanks.
- The two 47uF capacitors at the 3.3V line and the 22uF capacitor at the 5V line might be above the USB specifications for capacitive load. See Section 7.2.4.1 of the USB spec, where I believe it says you can only put a cumulative capacitance of 10uF at the downstream end of a Vbus. We might ignore that, or use something like a LM3525 (or even a TI TPS2151 which is a LDO with built-in in-rush current limiter). OpenPCD1 v0.4 is not being sold anymore exactly due to this problem.
didn't know than, I will change the ld1117 with a tps73633 (less expensive then TPS2151, and fits perfectly).
ok.
I don't understand why the capacitor at the 3.3v line affect USB, but I will minimize it.
The problem is that in power-on, the capacitive load on the 3.3V side normally also becomes visible as a capacitive load on the 5V side (as the regulator basically is 'switched through' at the moment you have the raising edge of supply power.
- However, it is useful to have a push-button for DFU-mode activation, this is a simple switch between Vcc and a GPIO. Normally, DFU is activated over USB itself. However, if the firmware is dead, this BOOTLOADER switch can help with recovery (once again, see OpenPCD)
I will take the openPCD design
If you look at the OpenPCD design, the I/O pin has a pull-down, and the switch goes to Vcc. In your v0.7 schematics you now have no pull-down and a series resistor for Vcc. I think we should use the OpenPCD way as it is known working.
-
Harald Welte -
Kevin Redon -
Philipp Fabian Benedikt Maier