Project

General

Profile

Feature #4030

design breakout board for GTM900-B

Added by laforge over 1 year ago. Updated 5 days ago.

Status:
Feedback
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
05/29/2019
Due date:
% Done:

80%

Resolution:
Spec Reference:

Description

Let's build a small 2-layer PCB design as a break-out board for the calypso/iota/rita based GTM900-B module.

It should have the following key features:

  • on-board power supply for (5V?) input
    • over-voltage + polarity protection
  • 2.5mm jack for the UART (+ TVS array)
  • expose all pins of the module on 2.54mm header
  • LED for power and modem (is there one?)
  • power button and jumper in parallel (auto-start)
  • reset button
  • SIM card slot (2FF) with TVS array

One option would also be to directly put a CP2102 or even CP2105 on the board to attach to one (or both) UARTs. This way we'd also have the option to control reset and/or power via GPIOS or serial status lines, like tsaitgaist used to do..

GTM900.pdf View GTM900.pdf 1000 KB laforge, 05/28/2019 10:10 PM
GTM900_product_overview.pdf View GTM900_product_overview.pdf 994 KB Product overview (Chinese), more detailed and more schematics than in English version steve-m, 09/02/2019 09:34 PM
gtm900-audio-io-symm.png View gtm900-audio-io-symm.png 7.28 KB gtm900-audio-io-symm mschramm, 05/04/2020 06:37 PM
gtm900-audio-io-asymm.png View gtm900-audio-io-asymm.png 7.59 KB gtm900-audio-io-asymm mschramm, 05/04/2020 06:37 PM
lenovo-combo-audio-jack.jpg View lenovo-combo-audio-jack.jpg 26.2 KB lenovo-combo-audio-jack mschramm, 05/04/2020 06:37 PM
PWON_chinese-ds.png View PWON_chinese-ds.png 14.6 KB PWON_chinese-ds mschramm, 05/04/2020 06:40 PM
PWON_english-ds.png View PWON_english-ds.png 15 KB PWON_english-ds mschramm, 05/04/2020 06:40 PM
gtm900-bo_modem-side.jpg View gtm900-bo_modem-side.jpg 98 KB mschramm, 06/04/2020 03:27 PM
gtm900-bo_smt-side.jpg View gtm900-bo_smt-side.jpg 142 KB mschramm, 06/04/2020 03:27 PM
gtm900-bo_smt-side_proto-placed.jpg View gtm900-bo_smt-side_proto-placed.jpg 158 KB mschramm, 06/10/2020 08:20 PM
GTM900-breakout-schematic.pdf View GTM900-breakout-schematic.pdf 49.2 KB GTM900-breakout-schematic mschramm, 06/10/2020 08:45 PM
4096
4097
4098
4099
4100
4192
4193
4200

Checklist

  • UART A
  • UART B
  • Audio on 3.5mm jack[s]
  • power supply
  • mechanical mounting of GTM module
  • power button control via modem handshake (optional via jumper)
  • mounting holes of breakout board

Related issues

Related to OsmocomBB - Feature #4575: Build + Test GTM900 breakout board prototypeIn Progress06/02/2020

Related to OsmocomBB - Bug #4610: OBB port on GTM900-B risks causing hw damage with fighting driver outputs on Calypso GPIO3/DTR lineNew06/10/2020

History

#1 Updated by laforge over 1 year ago

The shortest 40pos 0.5mm pitch FPC available from Digikey seems to be https://www.digikey.com/product-detail/en/molex/0151660425/WM16424-ND/3281306 at 29.97mm.

#2 Updated by mschramm over 1 year ago

GTM900 exposes no LED at all, so the breakout only will get a power-on LED.

Should the modem reside on the break-out PCB like on the mPCIe adapter, e.g. with hex spacer, or will this board be much smaller for only carrying the additional functionality and not the modem itself?

#4 Updated by laforge over 1 year ago

  • Priority changed from Normal to Low

the modem should be mounted with spacers on the board. I typically want to have a mechanically stable configuration, without any pigtails or other fragile constructs hanging off it. That's why we have the SMA sockets on the mpcie breakout board, and why I believe we should have a similar construct here.

#5 Updated by mschramm over 1 year ago

mschramm wrote:

GTM900 exposes no LED at all,

this might be not true, there are two pins with funny names and ambiguous descriptions, so likely one of them (or both?) might drive a LED (plus aditional driver):

Pin 13 is VDD (output), and its function "signal indication of normally started GTM900". The other is pin 32, LPG (output), "mainly controls the status of the indicator".

#6 Updated by mschramm about 1 year ago

  • Status changed from New to In Progress

#7 Updated by steve-m about 1 year ago

mschramm wrote:
Pin 13 is VDD (output), and its function "signal indication of normally started GTM900". The other is pin 32, LPG (output), "mainly controls the status of the indicator".

LPG is "LED pulse generation", basically dedicated timer circuitry to let an LED blink. Currently it is configured to have the LED always on, which works on the GTM900 on the existing breakout-board from China.

#9 Updated by mschramm 7 months ago

  • Status changed from In Progress to Stalled

#10 Updated by mschramm 5 months ago

  • Status changed from Stalled to In Progress

#11 Updated by mschramm 5 months ago

  • % Done changed from 0 to 70

just committed an approach for a GTM900 breakout last week, and first (internal) feedback came from laforge, who wanted the CP210x and a decent audio connection w/o pin header contacts, - which both are now in place too. Some routing is not yet done because of open questions.

  • I left in a mirrored version of the FPC receptacle representing the modem connector; it will get removed.
  • level translation on that board is made by the CP2105 USB dual UART for both serial ports (now bus-powered)
  • do we want to care about Vbackup? e.g. bringing this signal to the aux/ expansion header?
  • RESET now is a tact switch, and PWRON a jumper. Do we want momentary switches on both?
  • the initial AUX header now is gone; now we only would need it for the 2nd audio channel and the ADC input. Do we need either/both/none? THT header or test pads?

remarks on the audio section:

  • schema is similar to that in the chinese datasheet
  • I prefer the differential design, but it makes ESD design little more complicated (more TVS; TVS tbd)
  • electret biasing is derived by VCC which originates from the modem; we hence might want an LC lowpass towards the mic
  • the audio jack now is a 3.5mm TRRS, whereas the datasheet shows a RJ10 modular jack on that position - which receptacle do we want? If TRS or TRRS: what pin assignment (cause there are more than one concurrent...) ?

Let me know your feedback!

#12 Updated by mschramm 5 months ago

  • File GTM900-breakout-schematic.pdf added

(schematic pdf will be kept updated here for convenience when changes in schema are made)

#13 Updated by laforge 5 months ago

mschramm wrote:

just committed an approach for a GTM900 breakout last week, and first (internal) feedback came from laforge, who wanted the CP210x and a decent audio connection w/o pin header contacts, - which both are now in place too. Some routing is not yet done because of open questions.

I actually thought a CP2102 (single-port) only for one of the two UARTS, while the other one is on the normal osmocom style 2.5mm jack. But putting both UARTs ona CP2105 also seems fine to me, to be honest.

  • do we want to care about Vbackup? e.g. bringing this signal to the aux/ expansion header?

I think it may make sense if one wanted to play with the power saving features. At least have a connector, or possibly even have a footprint for a DNP battery holder?

  • RESET now is a tact switch, and PWRON a jumper. Do we want momentary switches on both?

I think reset as a button (taster) and PWRON on a jumper (defauly: on) looks good to me.

I think tsaitgaist once had a "DTR to power on calypso" device, so maybe we also have a jumper (and transistor?) to enable this mode of operation?

  • the initial AUX header now is gone; now we only would need it for the 2nd audio channel and the ADC input. Do we need either/both/none? THT header or test pads?

In general I would put all unused signals on test pads.

  • the audio jack now is a 3.5mm TRRS, whereas the datasheet shows a RJ10 modular jack on that position - which receptacle do we want? If TRS or TRRS: what pin assignment (cause there are more than one concurrent...) ?

I would definitely go for one (or two) 3.5mm jacks for the audio, assuming that people can use the kind of headsets that you would attach to audio jacks of a PC or laptop. IF a 4pin 3.5mm is used, let's use what laptop jacks e.g. of lenovo tend[ed?] to use.

#14 Updated by laforge 5 months ago

  • Checklist item UART A added
  • Checklist item UART B added
  • Checklist item Audio on 3.5mm jack[s] added
  • Checklist item power supply added
  • Checklist item mechanical mounting of GTM module added
  • Checklist item power button control via modem handshake (optional via jumper) added
  • Checklist item mounting holes of breakout board added

#15 Updated by falconia 5 months ago

FYI, I already made my own breakout/adapter board for GTM900 modules (called MMTB1) several months ago:

ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/mmtb1.tar.gz
https://www.freecalypso.org/pipermail/community/2020-January/000729.html

But my MMTB1 is much simpler than what you are doing here; your version is more complex with built-in USB-serial and taking 5V in rather than ready-made VBAT. My MMTB1 brings out the same interfaces as FCDEV3B, but it looks like your preferences are different.

In technical terms, I see only two problems with your current version, based on your PDF schematics posted in this ticket:

1) You have the GTM900 modem's UART_RI line connected to CP2105 SUSPEND/RI_SCI. The modem's UART_RI line is actually Calypso GPIO 0, but Huawei's official firmware configures this Calypso GPIO as an output, and my FreeCalypso firmware does likewise. But according to CP2105 datasheet, pin 1 (SUSPEND/RI_SCI) acts as the SUSPEND output by default, unless you switch it to RI_SCI or some other function via OTP configuration. Having CP2105 and Calypso outputs fight seems like a bad idea to me, and I would be concerned about possibly damaging one of the chips. So if you are going to keep this wiring, you should do the appropriate OTP configuration on the CP2105 to change that pin function. Yes, it sucks that CP2105 configuration is OTP instead of EEPROM: you only get one chance to program it, and if you mess it up, you have to either throw away the board or try to replace the QFN chip, which would be a major pita. For this reason, if you are going to keep the wiring that calls for OTP configuration change, you should do the programming at your factory, rather than leave it to end users. (This OTP nonsense is one of the many reasons why I am sticking with FT2232D for my projects and have no desire to switch to CP2105, but it is obviously not my place to tell you what to do in your business.)

2) MIC- and MIC+ microphone input signals on the GTM900 FPC interface are NOT raw Iota MICIN & MICIP, instead GTM900 already incorporates capacitive coupling and ECM bias injection circuits inside the module. Therefore, your external ECM bias injection circuit is wrong and should be removed. The circuit depicted in the Chinese document resides inside the GTM900 module itself, it is not something you need to build externally. The module's VDD output is the internal V-IO power rail, produced by Iota regulator VRIO - it is a digital (thus noisy) supply rail, not for anything analog. For the ECM bias the Iota chip has a dedicated MICBIAS analog voltage output, but this Iota output is not brought to the outside of GTM900, instead that whole circuit is implemented inside the module.

#16 Updated by laforge 5 months ago

Dear Mychaela,

many thanks for your input, it is - as always - much appreciated.

On Tue, Apr 28, 2020 at 06:45:39PM +0000, falconia [REDMINE] wrote:

FYI, I already made my own breakout/adapter board for GTM900 modules (called MMTB1) several months ago:

I am aware of this board, but indeed I found it somewhat lacking in
features for the kind of use case I have in mind. It seemed more like a
'raw breakout', i.e. a mechanical adapter fo the FPC to other
pins/connectors, than to try provide as much as possible in terms of
an environment that's easy to use without building further hardware.

This is not a complaint at all. It's just that our goals are (as it
seems customary by now) somewhat different :)

In technical terms, I see only two problems with your current version,
based on your PDF schematics posted in this ticket:

1) You have the GTM900 modem's UART_RI line connected to CP2105 SUSPEND/RI_SCI. The modem's UART_RI line is actually Calypso GPIO 0, but Huawei's official firmware configures this Calypso GPIO as an output, and my FreeCalypso firmware does likewise. But according to CP2105 datasheet, pin 1 (SUSPEND/RI_SCI) acts as the SUSPEND output by default, unless you switch it to RI_SCI or some other function via OTP configuration.

Thanks for pointing that out. I would assume we can do the OTP
programming - but we'd have to do it in a safe way, i.e. at a time
before the GTM900B is connected.

Factory pre-programming the CP2105 is not really an option for us, the
quantities are too low to rectify that. But we can of course do the
programming after component placment before ever placing the modem on
the board, and long before it ever gets into the hand of a user.

As a "plan B safeguard" I suggest we put a 0-ohm resistor into the line,
so if for some reason we are in trouble, we can interrupt the signal
without having to resort to cutting copper traces with a scalpel.

2) MIC- and MIC+ microphone input signals on the GTM900 FPC interface are NOT raw Iota MICIN & MICIP, instead GTM900 already incorporates capacitive coupling and ECM bias injection circuits inside the module. Therefore, your external ECM bias injection circuit is wrong and should be removed.

Interesting, thanks. I'll leave it to @weef to investigate and act
accordingly.

Regards,
Harald

#17 Updated by falconia 5 months ago

laforge wrote:

I am aware of this board, but indeed I found it somewhat lacking in
features for the kind of use case I have in mind. It seemed more like a
'raw breakout', i.e. a mechanical adapter fo the FPC to other
pins/connectors, than to try provide as much as possible in terms of
an environment that's easy to use without building further hardware.

I would not call my MMTB1 a "raw breakout", instead it is an intermediate form between a raw breakout and what you are building. A true raw breakout is what Songbosi sent me originally: all 40 pins of the FPC connector wired 1-to-1 to 2.54 mm header pins. That raw breakout was truly difficult to work with, so I built my MMTB1 as a replacement. MMTB1 has an on-board SIM socket and on-board pushbuttons for PWON and RESET, so it is not just going from FPC to other connectors. And I wasn't building any further hardware, instead I simply reused the same power supply and dual UART adapter which I already had for FCDEV3B.

This is not a complaint at all. It's just that our goals are (as it
seems customary by now) somewhat different :)

Yes, of course we have different goals as usual, but if you do produce this breakout board you are currently building and make complete GTM900-B kits available in your webshop, then it would help me too: it would provide one more low-entry-barrier path for potential users to play with my FreeCalypso firmware.

Thanks for pointing that out. I would assume we can do the OTP
programming - but we'd have to do it in a safe way, i.e. at a time
before the GTM900B is connected.

Yes, that was my thinking as well.

Factory pre-programming the CP2105 is not really an option for us, the
quantities are too low to rectify that.

I didn't mean Silabs chip factory preprogramming, instead I meant your own Sysmocom small hw factory - just like my FreeCalypso hw factory is a converted bedroom where I have my CMU200 and other production test gear, I assumed that you have something similar.

But we can of course do the
programming after component placment before ever placing the modem on
the board, and long before it ever gets into the hand of a user.

Good, this is exactly what I was asking for.

As a "plan B safeguard" I suggest we put a 0-ohm resistor into the line,
so if for some reason we are in trouble, we can interrupt the signal
without having to resort to cutting copper traces with a scalpel.

Seconded!

[MIC interface]

Interesting, thanks. I'll leave it to @weef to investigate and act
accordingly.

Just to reiterate, the MIC- and MIC+ pins that come out of the GTM900 on the FPC interface are meant for direct connection of an electret condenser microphone. On my MMTB1 I have these two signals routed to a 2-pin 2.54 mm header without any extra glue components, and I can connect an ECM to those two pins exactly the same as on FCDEV3B. In the case of FCDEV3B I have copied the microphone interface circuit (ECM bias injection and capacitive coupling to Iota MIC inputs) from TI's Leonardo schematics, but GTM900 already has this exact same circuit built-in inside the module.

#18 Updated by laforge 5 months ago

On Wed, Apr 29, 2020 at 07:27:18AM +0000, falconia [REDMINE] wrote:

Factory pre-programming the CP2105 is not really an option for us, the
quantities are too low to rectify that.

I didn't mean Silabs chip factory preprogramming, instead I meant your own Sysmocom small hw factory - just like my FreeCalypso hw factory is a converted bedroom where I have my CMU200 and other production test gear, I assumed that you have something similar.

It still is too much effort. tHat would mean we'd have to have a ZIF socket for this specific QFN package,
and remove every chip from the tape/reel, then re-reel it before passing it to the SMT house. Even if a tray
package was available, it's too much work ad no real benefit over the post-production-programming.

[MIC interface]

Interesting, thanks. I'll leave it to @weef to investigate and act
accordingly.

Actually, I meant mschramm

Just to reiterate, the MIC- and MIC+ pins that come out of the GTM900 on the FPC interface are meant for direct connection of an electret condenser microphone. [...]

understood.

#19 Updated by mschramm 5 months ago

4096
4097
4098
4099
4100

Thanks for remarks and input!

Audio I/O:

@falconia: after I had some translated phrases on what is in section 4.6.3 of the Chinese datasheet, it became clear that this is internal circuitry...!

But this means that we
  • either have an audio-out as shown in gtm900-audio-io-symm.png (incompatible with a Lenovo Combo audio ("AHJ/CTIA") requested by laforge; in this case we should strip the TRRS jack and bring those four wires to a pin header)),
  • or try an asymmetrical approach (gtm900-audio-io-asymm.png), which might work on a CTIA TRRS headset (in this case the TVS array should be reduced to two discrete diodes)
    For the latter, we might want to introduce a AGND area covering the receptacle, connected w/ a ferrite or a 10R.. to GND.
SUSPEND/RI_SCI on modem's UART_RI:

The CP2105 can be programmed before the FPC towards the modem is mounted / inserted into both receptacle. Question remains whether the CP2105 needs the VIO input from the modem during programming.
Also, as we don't need the VDD_3V45 from the CP2105, we could strip the two buffer caps there - or just leave them in place and bring VDD_3V45 to another test pad.

PWON control via modem handshake (optional via jumper):

The english and the chinese datasheet differ in the display on how PWON needs to be used (see images PWON_chinese-ds.png and PWON_english-ds.png): for powering on, a 10ms LOW on that line switches on, while bringing it LOW for 2 to 3 seconds, switches off the modem. We hence shoud not short this signal with a jumper to GND. I now used a tact switch as for RESET, and a non-inverting buffer w/ a tristate output fed by the UART_DTR signal (I should add a 0R resistor on that buffer's input, or maybe the mentioned junmper... ;) )

mechanical mounting of GTM module:

Out of the four drills in the GTM900 we should only use three (one is a halved on an edge), drills take 2mm screws. We should take hex SMT spacers for 2mm and screws similar to those on the M.2/NGFF PCBA.

#20 Updated by mschramm 5 months ago

  • File deleted (GTM900-breakout-schematic.pdf)

#21 Updated by mschramm 5 months ago

  • File GTM900-breakout-schematic.pdf added

(schematic pdf updated)

#22 Updated by falconia 5 months ago

Hi mschramm,

@falconia: after I had some translated phrases on what is in section 4.6.3
of the Chinese datasheet, it became clear that this is internal
circuitry...!

Glad we are on the same page now.

But this means that we
  • either have an audio-out as shown in gtm900-audio-io-symm.png (incompatible
    with a Lenovo Combo audio ("AHJ/CTIA") requested by laforge; in this case we
    should strip the TRRS jack and bring those four wires to a pin header)),

This is the approach I would favor, including the pin header part - it
is the approach implemented on my MMTB1, simple and trustworthy.

  • or try an asymmetrical approach (gtm900-audio-io-asymm.png), which might
    work on a CTIA TRRS headset (in this case the TVS array should be reduced to
    two discrete diodes)

I don't know enough audio-fu to tell if this approach will work or not
- proceed at your own risk.

For the latter, we might want to introduce a AGND area covering the
receptacle, connected w/ a ferrite or a 10R.. to GND.

Ditto regarding the unknown.

The CP2105 can be programmed before the FPC towards the modem is mounted
/ inserted into both receptacle.

Yes, this is what I am hoping you will do on your end before shipping
these boards to webshop customers.

Question remains whether the CP2105 needs the VIO input from the modem
during programming.

To be honest, I rather dislike the entire idea of using the modem's
V-IO output to power the VIO supply on the USB-serial converter side.
Instead the proper approach would be to implement a dedicated LDO
regulator on the USB side, powered from USB VBUS and putting out 2.8V,
and use that non-modem-sourced regulator to power the USB-serial
chip's VIO supply. If you are going to keep your current arrangement
of abusing Calypso V-IO for powering CP2105 I/O buffers, then you are
going to have the following two potential problems:

1) You won't be able to use any CP2105 GPIO outputs to command a modem
power-on: while the VRPC block in the Iota chip in the modem is in the
switched-off state, the chip's VRIO regulator is fully off, and there
is no voltage put out on the V-IO rail - a chicken and egg problem.

2) If the Calypso+Iota chipset is allowed to go into superdeep sleep
(my made-up term for the sleep mode in which not only is the Calypso
put into deep sleep with the VCXO stopped, but the Iota ABB sleep mode
is also activated), the maximum current that can be drawn from the
VRIO regulator is reduced to just 1 mA, in contrast with the 100 mA
allowed in Active mode. The modem's internal circuits are designed so
that this 1 mA sleep mode limit is never exceeded, but I can only
reason that your CP2105 can easily exceed that very tight limit.

PWON control via modem handshake (optional via jumper):

The GTM900 modem's PWON control input is wired directly to the
same-named signal on the Iota ABB chip, thus its behaviour is governed
100% by TI's Calypso+Iota chipset design, not by anything from Huawei.
The only way to understand it properly is to read and thoroughly
understand section 4.10 (Voltage Reference and Power Control) of TI's
TWL3025 datasheet:

ftp://ftp.freecalypso.org/pub/GSM/Calypso/TWL3025_SWRS021.pdf

Pages 40 through 44 of this datasheet cover the VRPC block.

The english and the chinese datasheet differ in the display on how PWON
needs to be used (see images PWON_chinese-ds.png and PWON_english-ds.png):

Independent of Huawei's recommendations, the actual hardware reality
inside the Iota chip is that when the VRPC state machine is in the OFF
state (the initial power-on condition after application of VBAT to
module pins 1-5), any instantaneous sampling of a LOW on the PWON line
will initiate the switch-on sequence, causing the Calypso processor to
boot. Regardless of what happens afterward (PWON being quickly released
or staying low forever), any further state transitions can only be
commanded by Calypso firmware.

for powering on, a 10ms LOW on that line switches on, while bringing it
LOW for 2 to 3 seconds, switches off the modem.

These are firmware conventions, not hardware - there aren't any such
timers anywhere in that modem hw.

We hence shoud not short this signal with a jumper to GND.

At least with FreeCalypso fw (not sure about Huawei's original fw),
having PWON permanently grounded with a jumper is OK but suboptimal:
the firmware is smart enough to recognize that no power-off request is
being made in this situation, but the downside is that Iota sleep mode
(what I call superdeep sleep) cannot be entered: a LOW on PWON is an
unconditional wakeup request to Iota VRPC.

On my FCDEV3B I provide a PWON pushbutton switch and a two-pin header
wired in parallel with it: using the pushbutton switch is preferable,
but a jumper may also be installed for unattended operation where no
human is available to press the button.

I now used a tact switch as for RESET,

This one is good. Please note that your pull-up resistor R11 is
unnecessary, although harmless - PWON is internally pulled up to VBAT
inside the Iota chip itself.

and a non-inverting buffer w/ a tristate output fed by the UART_DTR signal

This one is more problematic: Huawei's UART_DTR signal is wired to
Calypso GPIO3 internally (following TI's C-Sample and D-Sample
reference boards where GPIO3 was wired as DTR), TI's TCS211 reference
fw implements logic for CSD call hang-up per AT&D, and I assume that
Huawei's fw does likewise. Users should be able to wiggle DTR however
they like to play with AT&D logic in the firmware, without accidentally
commanding a power-off or preventing the modem from going into
superdeep sleep. Please pick a different CP2105 GPIO output: you have
all of the GPIOs associated with the other UART currently unused.

I would also strongly recommend following Openmoko's reference for how
to control PWON with a GPIO coming an application processor:

ftp://ftp.freecalypso.org/pub/GSM/GTA02/GTA02_Schematic_MB_A5_1220.pdf

See page 16, the circuit around Q1000.

Two additional concerns:

1) The RST signal which GTM900 provides on pin 31 is a very non-trivial
beast. As I discovered by reverse eng of this GTM900 module, it turns
out that Huawei replicated the XDS_RESET circuit from TI's Leonardo
development board:

ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_rev05.pdf

Look on page 3, the JTAG block depiction along the top of the page,
the transistor circuit (Q308A and Q308B) between Iota nTESTRESET and
JTAG connector pin 2. This Q308 dual transistor is also present on
the GTM900, and Huawei's FPC connector pin 31 is wired exactly the
same way as JTAG connector pin 2 on TI's reference boards (and on my
own FCDEV3B too, which also has this exact same circuit). Some while
ago I wrote a detailed document explaining all of these quirks:

https://www.freecalypso.org/hg/freecalypso-docs/file/tip/Calypso-test-reset

Given that the RST signal you are manipulating is really XDS_RESET,
your pull-up to VBAT (R12) is wrong - it would leak the much higher
VBAT voltage into the modem's V-IO rail through the internal resistors
built into the prebiased transistor package. Having a pushbutton
switch shorting XDS_RESET to GND is OK (although not ideal because of
contact bounce, as explained in my article linked above) - but because
the reset signal is XDS_RESET rather than raw Iota nTESTRESET, you
could drive it with another GPIO from your CP2105.

2) What are you doing with the Calypso SIM_CD line which GTM900 brings
out on pin 24? Right now it looks like you are leaving it unconnected,
which would be bad as it would be a floating CMOS input on the Calypso.
On TI's Leonardo reference schematics, on Openmoko GTA02 and on my own
FCDEV3B this SIM_CD signal is connected to Calypso V-IO, and I recommend
that you do the same. Alternatively, connecting it to GND will probably
be fine too - it looks like most firmwares ignore it, as long as it
isn't left completely floating.

I hope that my feedback will be taken to heart - while I prefer my own
MMTB1 for my own playing with GTM900 modems, I am interested in your
competing GTM900 breakout board because if you end up offering it in
your webshop and it is designed correctly, it would provide one more
low-entry-barrier route for people to play with my FreeCalypso firmware
on cheap and readily available hw. But it would be a real shame if
you design your breakout board in such a way that it would be usable
only with your primitive OBB firmware and not with richer firmwares
like FreeCalypso or Huawei's original.

#23 Updated by laforge 4 months ago

prototype PCB received (no parts yet to assemble).

The first problem I see is the SMT (soldered) spacers on the bottom side to mechanically mount the module. This would require a second reflow just for those four SMT spacers. which will make the product more expensive to assemble. It's the only bottom mounted part..

Soldering those by hand is very likely also quite a bit of effort - and you'd have to be super careful not to get any solder on the thread of the spacer.

So I guess we should go back to a more classic mounting option with regular, screw-mounted spacers (which may require more clearance)

#24 Updated by mschramm 4 months ago

I don't quite understand; we never had these types of problems when assembling the SMT spacer (manually) on the prototypes for e.g. NGFF breakout or OctSIM. Manual soldering ist very easy and takes place from the modem side, not the SMT placement side. So no thread gets into danger by solder.

#25 Updated by laforge 4 months ago

On Sat, May 30, 2020 at 10:13:21PM +0000, mschramm [REDMINE] wrote:

I don't quite understand; we never had these types of problems when assembling the SMT spacer (manually) on the prototypes for e.g. NGFF breakout or OctSIM. Manual soldering ist very easy and takes place from the modem side, not the SMT placement side. So no thread gets into danger by solder.

ok, good to hear.

However: Dong this for (few) prototypes by hand is one thing - assuming
that the mass produced units are reflow soldered. But manually
soldering 4 spacers on e.g. 100 boards is a bit of a different story.

I would have assumed it's faster/cheaper to simply use screw/nut mounted spacers.

#26 Updated by laforge 4 months ago

  • Related to Feature #4575: Build + Test GTM900 breakout board prototype added

#27 Updated by laforge 4 months ago

  • Status changed from In Progress to Feedback
  • Assignee changed from mschramm to roh

#28 Updated by mschramm 4 months ago

4192
4193

Images from building 1st PCBA prototype

#29 Updated by roh 4 months ago

i have one assembled prototype now (#4575) and am a bit unsure what config exactly to program into the cp2105.

this is the current (default) settings as read by this tool https://github.com/DiUS/cp210x-cfg

sudo ./cp210x-cfg
ID 10c4:ea70 @ bus 002, dev 057: CP2105 Dual USB to UART Bridge Controller
Model: CP2105
Vendor ID: 10c4
Product ID: ea70
Name: CP2105 Dual USB to UART Bridge Controller
Serial: 00D750E8
Flush buffers: 33
SCI/ECI mode: ffff

any suggestions about different tools or ways to make sure my 'mode' is correct are welcome.

#30 Updated by laforge 4 months ago

roh wrote:

i have one assembled prototype now (#4575) and am a bit unsure what config exactly to program into the cp2105.

I would have hoped that we can do PCB validation without having to program anything beyond the initial defaults. Please coordinate with mschramm what he thinks should be programmed.

Keep in mind it's a real OTP, so if you program something wrong, you need to re-work/replace the CP2105.

#31 Updated by mschramm 3 months ago

4200

laforge wrote:

I would have hoped that we can do PCB validation without having to program anything beyond the initial defaults.

Not, as long is R24 (0R) is placed: this connects !SUSPEND/RI_SCI and modem's UART_RI, and as USB suspend output is default, this and RI should not be connected w/ an unprogrammed cp2105 beforehand. Additionally, depending on default unprogrammed states of the respective cp2105 pins, R7, R8 and R20 (base resistors on reset- and PWON driver stages) might need to be unpopulated for this first modem tests w/o programmed cp2105.

Please coordinate with mschramm what he thinks should be programmed.

In terms of GPIO mode vs. Modem mode, I think SCI shall be in modem mode, and ECI in GPIO mode.
GPIO.0_ECI and GPIO.1_ECI shall be push-pull outputs.

Saying this, I obviously forgot to switch LDO's EN input via a GPIO.. ok, v2, which GPIO, none left?

Main LDO on picture gets another package, too; this one will work for testing on first prototype.

#32 Updated by mschramm 3 months ago

  • File deleted (GTM900-breakout-schematic.pdf)

#33 Updated by mschramm 3 months ago

(schematic pdf updated)

#34 Updated by falconia 3 months ago

mschramm wrote:

In terms of GPIO mode vs. Modem mode, I think SCI shall be in modem mode, and ECI in GPIO mode.

Looks correct to me.

GPIO.0_ECI and GPIO.1_ECI shall be push-pull outputs.

Are there also bits that configure the default initial state of these outputs? If so, you would want them to be LOW initially by default, which would be the inactive state per your current schematics.

Saying this, I obviously forgot to switch LDO's EN input via a GPIO.. ok, v2, which GPIO, none left?

What is wrong with having this LDO always on whenever USB power is present? You won't be able to control it with a GPIO, as it is your I/O voltage supply for your CP2105 - chicken and egg problem.

Other bugs I see on your current schematics:

  • Why is the right side of R25 (CP2105 RST pull-up resistor) connected to the modem's VDD instead of your locally generated VIO?
  • The "high" side of your SIM card presence detect switch exhibits the opposite bug.

#35 Updated by falconia 3 months ago

Please also see bug #4610 - yes, your current breakout board is affected by it.

#36 Updated by roh 3 months ago

falconia wrote:

  • Why is the right side of R25 (CP2105 RST pull-up resistor) connected to the modem's VDD instead of your locally generated VIO?

i just checked the DS and i think this should be VDD_3V45 in our schematic, not VIO.
i can rework R25 to get VDD from C22/23 near it.

  • The "high" side of your SIM card presence detect switch exhibits the opposite bug.

so R4 needs to connect to VDD instead of VIO_2V8 ? i guess USIM_VCC would be wrong since detecting presence needs to work even when the simcard-vcc is off?

#37 Updated by falconia 3 months ago

roh wrote:

  • Why is the right side of R25 (CP2105 RST pull-up resistor) connected to the modem's VDD instead of your locally generated VIO?

i just checked the DS and i think this should be VDD_3V45 in our schematic, not VIO.

Hmm, I looked in the CP2105 DS and the two reference schematics given there show it pulled up to CP2105 VIO, which is still not the same as the Calypso+Iota chipset's separately-generated VIO, where you have it pulled up currently. If you are seeing otherwise, please tell me exactly where and exactly which revision of the datasheet you are looking at.

i can rework R25 to get VDD from C22/23 near it.

Or you can just depopulate R25 - the CP2105 DS says this pull-up is optional to improve noise immunity.

  • The "high" side of your SIM card presence detect switch exhibits the opposite bug.

so R4 needs to connect to VDD instead of VIO_2V8 ?

Yes, because the signal which you (and Huawei unfortunately too) are calling VDD here (not CP2105 VDD!) is actually called V-IO in the Calypso+Iota chipset docs - it is the output of Iota LDO regulator VRIO. The signal which you are calling USIM_CD but which was originally just SIM_CD goes directly to the Calypso chip, it is a regular digital input, referenced to the Calypso+Iota chipset's V-IO, which Huawei also brought out as VDD for uses like the present.

Using a differently-sourced 2.8V rail here like your current VIO_2V8 (sourced from an LDO from USB rather than from Iota) shouldn't cause any harm in practice (at least none I can think of on the spot), but it is still philosophically wrong.

i guess USIM_VCC would be wrong since detecting presence needs to work even when the simcard-vcc is off?

Definitely wrong, as in wrong voltage level - it is a Calypso digital input referenced to the chipset's internal V-IO, NOT referenced to level-shifted SIM interface voltage.

Please also note that most designs do away with this switch altogether: on Openmoko GTA02 this Calypso SIM_CD input is tied directly to Calypso+Iota V-IO (well, OK, going through a 0R), ditto on TI's own Leonardo reference board from which Openmoko copied this bit, and on my FCDEV3B which works very well. My MMTB1 adapter for GTM900-B modems also has this FPC pin connected directly to Huawei's VDD, which is actually Calypso+Iota V-IO.

#38 Updated by mschramm 3 months ago

  • Related to Bug #4610: OBB port on GTM900-B risks causing hw damage with fighting driver outputs on Calypso GPIO3/DTR line added

#39 Updated by mschramm 3 months ago

falconia wrote:

roh wrote:

  • Why is the right side of R25 (CP2105 RST pull-up resistor) connected to the modem's VDD instead of your locally generated VIO?

It goes to modem's VDD which is clearly a mistake.

i just checked the DS and i think this should be VDD_3V45 in our schematic, not VIO.

Hmm, I looked in the CP2105 DS and the two reference schematics given there show it pulled up to CP2105 VIO, which is still not the same as the Calypso+Iota chipset's separately-generated VIO, where you have it pulled up currently. If you are seeing otherwise, please tell me exactly where and exactly which revision of the datasheet you are looking at.

i can rework R25 to get VDD from C22/23 near it.

Or you can just depopulate R25 - the CP2105 DS says this pull-up is optional to improve noise immunity.

datasheet says that the /RST can withstand 5.8V (if CP2105's Vio > 2.2V, which is the case), so we even could connect VBUS to R25; so VIO_2V8 would do as well as VDD_3V45 and VBUS would do.
We can of course test w/o R25, but disregarding that the note says 'for better noise imunity', I'd like to have those parts placed or at least have the unplaced footprint for respective environments. Let's select a proper PU voltage supply rail for R25; it shouldn't be modem's VDD as it is now.

  • The "high" side of your SIM card presence detect switch exhibits the opposite bug.

[...]

Using a differently-sourced 2.8V rail here like your current VIO_2V8 (sourced from an LDO from USB rather than from Iota) shouldn't cause any harm in practice (at least none I can think of on the spot), but it is still philosophically wrong.

Disregarding that VIO_2V8 here would work: agreed, SIM_CD's PU voltage should go to modem's VDD.

from an update before:

Saying this, I obviously forgot to switch LDO's EN input via a GPIO.. ok, v2, which GPIO, none left?

What is wrong with having this LDO always on whenever USB power is present? You won't be able to control it with a GPIO, as it is your I/O voltage supply for your CP2105 - chicken and egg problem.

You got me wrong here (while me not being precise enough): not the VIO_2V8 LDO was meant, but the main MCP1827.

#40 Updated by falconia 3 months ago

On 6/22/20, mschramm [REDMINE] <> wrote:

You got me wrong here (while me not being precise enough): not the VIO_2V8
LDO was meant, but the main MCP1827.

OK, and still the question remains: what is wrong with having this
main MCP1827 LDO always enabled?

#41 Updated by roh 3 months ago

ok

i have reworked:
  • R25 to VDD_3v45
  • R4 to VDD

on all 3 boards now.

#42 Updated by mschramm 3 months ago

Just reviewed some application notes and btw the errata sheet for the cp2105, and the latter contains an important mistake which impacts our current design. They call this error "CP2105_E101", it is about the voltage level of VIO during programming:

The data sheet incorrectly indicates that VDD must remain at 3.3 V or higher to successfully write to the configuration ROM. Instead,
the voltage on the VIO pin must remain at 3.3 V or higher when writing to the configuration ROM.

As VIO and VDD is not connected in our design (by intention), this error ist crucial; U3 must not be in place when in-circuit programming the cp2105, and VIO must be connected to VDD during programming.

#43 Updated by roh about 2 months ago

CP2105_E101 verified sigh see https://osmocom.org/issues/4575#note-18

#44 Updated by falconia 5 days ago

Looking at the notes in #4575, it looks like your design decision to use CP2105 as your USB to dual UART adapter chip instead of FT2232x (a design decision with which I always strongly disagreed) has come back to bite you - it looks like you are having very major difficulties getting that chip's OTP configuration memory programmed in a way that your board requires.

If you would be willing to drop that horrible CP2105 chip and replace it with FT2232x (either D or H, whichever you prefer), I have put together a detailed document explaining exactly how one can build a properly working solution consisting of FT2232x and GTM900:

https://www.freecalypso.org/hg/freecalypso-docs/file/tip/GTM900-design-guide

If you would be willing to go the FT2232x route and would like further guidance beyond what I wrote in the article above, I will gladly help you further to the best of my ability.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)