Project

General

Profile

Feature #4575

Build + Test GTM900 breakout board prototype

Added by laforge about 1 month ago. Updated 6 days ago.

Status:
In Progress
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
06/02/2020
Due date:
% Done:

70%

Resolution:
Spec Reference:

Description

3 PCBs and associated components are on their way to the sysmocom office (arriving today around noon).

Pleae assemble ASAP one board for initial testing (see checklist)

Once the first board appears working, please assemble the other two.

Report any issues that require fixing in the design on the design to mschramm in #4030

cp210x-customizer.png View cp210x-customizer.png 68.9 KB mschramm, 07/05/2020 03:05 PM
4225

Checklist

  • test power supply
  • test USB enumeration of CP2105
  • check if modem is responding to AT commands on UART
  • check if SIM interface appears working (e.g. AT+CIMI to read IMSI)
  • develop and test OTP config for cp2105
  • verify audio wiring

Related issues

Related to OsmocomBB - Feature #4030: design breakout board for GTM900-BFeedback05/29/2019

History

#1 Updated by laforge about 1 month ago

  • Related to Feature #4030: design breakout board for GTM900-B added

#2 Updated by roh about 1 month ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20

#3 Updated by roh about 1 month ago

  • Checklist item test power supply set to Done
  • Checklist item test USB enumeration of CP2105 set to Done

#4 Updated by roh about 1 month ago

  • % Done changed from 20 to 60
[5845623.484170] usb 2-1.2: new full-speed USB device number 56 using ehci-pci
[5845623.594771] usb 2-1.2: New USB device found, idVendor=10c4, idProduct=ea70
[5845623.594779] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[5845623.594784] usb 2-1.2: Product: CP2105 Dual USB to UART Bridge Controller
[5845623.594788] usb 2-1.2: Manufacturer: Silicon Labs
[5845623.594791] usb 2-1.2: SerialNumber: 00D750E8
[5845623.595863] cp210x 2-1.2:1.0: cp210x converter detected
[5845623.601261] usb 2-1.2: cp210x converter now attached to ttyUSB0
[5845623.601881] cp210x 2-1.2:1.1: cp210x converter detected
[5845623.602879] usb 2-1.2: cp210x converter now attached to ttyUSB1

[5845630.941806] usb 2-1.2: USB disconnect, device number 56
[5845630.942331] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[5845630.942372] cp210x 2-1.2:1.0: device disconnected
[5845630.942772] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
[5845630.942817] cp210x 2-1.2:1.1: device disconnected

#5 Updated by roh about 1 month ago

voltages are fine (4.1V / 2.8V) and the cp is enumerating fine. i will need to figure out the OTP config next.

i found a tool which looks promising, but first i have to understand what config we need and how to encode it. since this came up in #4030 already i put the request there.

#6 Updated by mschramm about 1 month ago

roh: just updated the #4030 ticket there regarding desired cp2105 settings.

#7 Updated by roh 16 days ago

i did the reworks discussed on #4030 (pullups)

i am currently trying getting it to work, so i pulled R24 and tried my luck.
sadly there seem to be issues with the fpc connector (not sure its for a fpc this thick) and i cannot get it to power on. i pulled R7 and R20, but it seems the lines are not pulled up or the connecting is bad.

this is not the regular pull frame or fold up and push straight type but its a bit angled up and i think its intended for fpc without stiffeners.

#8 Updated by roh 16 days ago

i just tried a connectorback-cable-modem continuity test and figured out the fpc socket is 'reverse'

means the fpc only contacts when the metal is facing up and then all pins are reversed again sigh.

this means we need to find another fpc connector to place on these prototypes.

#9 Updated by roh 15 days ago

  • Checklist item develop and test OTP config for cp2105 added
  • Checklist item verify audio wiring added
  • Checklist item develop and test reset/power gpio settings and defaults added
  • Checklist item check if modem is responding to AT commands on UART(s) set to Done
  • Checklist item check if SIM interface appears working (e.g. AT+CIMI to read IMSI) set to Done
  • % Done changed from 60 to 70

i just tested a hirose FH12-40S-0.5SH(55) (DK PN HFJ140CT-ND ) https://www.digikey.com/product-detail/en/hirose-electric-co-ltd/FH12-40S-0-5SH-55/HFJ140CT-ND/1110388

and that one is much better, also the cable lays horizontal out of the connector and it seems to be built for the same thickness as the fpc including stiffener.

not sure if it makes sense to test the molex sample (also does not look as nice/more flimsy).

i had to pull out R7/R20 for testing since the lines are pulled high by default.

on the ttyUSB0 i get the 'debug' serial
on ttyUSB1 i get the 'AT interpreter', both working fine so far. was that order intended or is this by accident?

i have tested with a white congress-sim and AT+CIMI works after reboot.

#10 Updated by falconia 15 days ago

roh wrote:

i just tested a hirose FH12-40S-0.5SH(55) (DK PN HFJ140CT-ND ) https://www.digikey.com/product-detail/en/hirose-electric-co-ltd/FH12-40S-0-5SH-55/HFJ140CT-ND/1110388

and that one is much better, also the cable lays horizontal out of the connector and it seems to be built for the same thickness as the fpc including stiffener.

This is the FPC connector part I use on my MMTB1, design files freely published since January. This part works flawlessly, and it was obvious to me from the beginning that it is the right part to use - IIRC, even Huawei's own datasheet recommends this connector part. Thus I don't understand why you went with a different part to begin with.

on the ttyUSB0 i get the 'debug' serial

You can use FreeCalypso utility rvtdump (FC host tools package, public domain license, 100% my own original work) to decode this binary-packet-based debug trace serial stream into human-readable ASCII, and you can also use rvinterf and other utilities from the same suite to send TM/ETM and GPF debug commands to the firmware - Huawei's fw on these modems implements most of the same debug commands as TI/FreeCalypso mainline.

on ttyUSB1 i get the 'AT interpreter', both working fine so far. was that order intended or is this by accident?

This order of ttyUSB devices is the opposite of FreeCalypso convention, and it stems from your decision (which I vehemently disagree with) to use CP2105 instead of FT2232D as your USB to dual UART converter. In the FreeCalypso family I endorse FT2232D as the officially recommended choice of USB to DUART adapter, and the official convention is to connect channel A to the MODEM UART (AT commands) and channel B to the IrDA UART (rvinterf). Both channels of FT2232D are strictly equal in hw, thus the assignment is a matter of convention only.

But the two channels of CP2105 are NOT equal: one is SCI, the other is ECI. Your breakout board design connects the AT command UART channel to SCI, which seems to be the only sensible way with CP2105, given that GTM900-B brings out the full set of modem control signals and given that DCD on ECI conflicts with the programming voltage pin. But the standard Linux kernel driver puts ECI on ttyUSB0 and SCI on ttyUSB1, resulting in ttyUSB channel assignment that is the opposite of FreeCalypso convention.

Another issue is that Calypso UARTs (clocked with 13 MHz internally) support non-standard (outside of GSM world) baud rates of 203125, 406250 and 812500 bps, but do NOT support any "standard" baud rates above 115200 baud. FT2232D supports non-standard baud rates on both channels, but CP2105 supports them only on the ECI channel.

#11 Updated by roh 15 days ago

i tend not to support criminal vendors (ftdi)

#12 Updated by falconia 15 days ago

roh wrote:

i tend not to support criminal vendors (ftdi)

Can you recommend some other chip that meets all of the following requirements:

  • Goes from one USB device to two UARTs
  • Is supported by mainline Linux kernel
  • Supports non-standard baud rates like 203125, 406250 and 812500 bps on both channels
  • Has the full set of modem control signals available without complications, at least on the channel that becomes ttyUSB0 in Linux

Any recommendations? If you can recommend a suitable alternative to FT2232D that satisfies all of the requirements I just listed, I will gladly consider it!

#13 Updated by roh 8 days ago

i am working on the otp config atm.

my current assumptions are that:
  • SCI needs to change to modem mode (the R24 can go back in)
  • ECI stays gpio mode
  • the gpios on ECI need to become outputs (default is input)
  • the initial state for both gpio0 and 1 on ECI needs to be low (not sure about the details on how to yet)
  • i'll remove R14 for now, since i do not see how having dtr involved makes sense here, when the !pw_on signal behaves more like a toggle-button with that modem firmware.

since one/'the second' serial port is not broken out of the gtm900 beyond tx and rx anyhow (the one connecing to ECI, labeled infrared and txd2/rxd2 in the huawei ds) it doesn't make sense to me to set that to modem mode too.

it doesn't matter which tty is which. we will need to distinguish modems by strings and serials anyway since we will keep the usbids as they are so the default drivers catch it. mapping the ttyUSBx to whatever you need via udev is not even overhead thus.

i'm not decided on the strings yet, so any sensible suggestions are welcome.

i want to make sure i burn as few chips as possible, so i want to get a good first try before burning the otp, so any help/info about errors in my above assumptions is really welcome.

this especially true for fields like the 'flush buffer configuration' or the sci_ri details.

the table with the defaults is on page 18 of the cp2105 ds also shows the 3 default strings.

#14 Updated by roh 8 days ago

  • Checklist item deleted (develop and test reset/power gpio settings and defaults)

#15 Updated by mschramm 6 days ago

4225

roh wrote:

my current assumptions are that:

  • ECI stays gpio mode

yes.

  • i'll remove R14 for now, since i do not see how having dtr involved makes sense here, when the !pw_on signal behaves more like a toggle-button with that modem firmware.

If not controlled by a terminal emulation, the port-assigned DTR might work differently than known from a terminal emulator (or a native RS232). Whether DTR or GPIO.0_ECI/DTR_ECI would be used for /PWON in such a use case, depends on many other decisions. I'm fine with leaving R14 for now as we first have to evaluate other functions of the break-out PCBA.

since one/'the second' serial port is not broken out of the gtm900 beyond tx and rx anyhow (the one connecing to ECI, labeled infrared and txd2/rxd2 in the huawei ds) it doesn't make sense to me to set that to modem mode too.

Erm... no one wants this anyway, we always wanted to have ECI in GPIO mode, e.g. see #4030#note-34 .

Checklist item deleted (develop and test reset/power gpio settings and defaults)

why did you delete this item?


regarding programming a (P)ROM configuration to this IC:

Besides https://github.com/DiUS/cp210x-cfg, I've tried three factory tools loaded from the product page https://www.silabs.com/interface/usb-bridges/classic/device.cp2105 ('software +tools' tab; no deep link possible).

One is a python 'demo' for their libcp210xmanufacturing (saying demo as at the end of this python prg some functions are described as not yet wrapped. Also, the initial open err is also seen at another cp2103 - so don't know more about it); typo on company name is from source:

$ python ./CP210xManufacturing.py
Number of CP210xDevices = 1

CP210x_Open err 0xff
('--- SetupDi data --- device #0',)
(u'ProductString CP210x_RETURN_SERIAL_NUMBER : 00776166',)
(u'ProductString CP210x_RETURN_DESCRIPTION   : CP2105 Dual USB to UART Bridge Controller',)
('--- Hardware data --- device #0',)
('PartNumber: 0x5',)
('devVID 0x10C4 devPID 0xEA70',)
('SelfPower: 0x0',)
('MaxPower: 0x32',)
('DeviceVersion: 0x100',)
(u'DeviceManufacturerString: Silicon Lafs',)
(u'DeviceProductString: CP2105 Dual USB to UART Bridge Controller',)
(u'DeviceSerialNumber: 00776166',)
('FlushBufferConfig: 33',)
(u'InterfaceString #0: Enhanced Com Port',)
(u'InterfaceString #1: Standard Com Port',)
('bDeviceModeECI: ff bDeviceModeSCI: ff',)
PASS

$

Second tool was cp210xsmt (part of appnote's AN721 sw package (AN721SW)), as input configuration files this too needs to have files provided by "...Xpress Family configuration tools provided in Simplicity Studio." These are simple flat json-style text files, but I have not found a cp2105 example covering more function that the ones seen above.

Last tool tried was a GUI-based 'customizer' by Silabs, but also no more options exposed... 8(

Looks like as if we have to use their "Simplicity Studio v4" which integrates CP210x/CP211x support in their Xpress Configurator, at least once to have a working configuration file as template on enhanced GPIO functions...

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)