Project

General

Profile

Actions

Feature #4575

closed

Build + Test CP2102 GTM900 breakout board prototype

Added by laforge almost 4 years ago. Updated 4 months ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
-
Target version:
-
Start date:
06/02/2020
Due date:
% Done:

80%

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


Files

cp210x-customizer.png View cp210x-customizer.png 68.9 KB mschramm, 07/05/2020 03:05 PM
cp2105_silabs_defaults.txt cp2105_silabs_defaults.txt 1.8 KB roh, 07/14/2020 05:48 PM
cp2105_gtm900_roh.txt cp2105_gtm900_roh.txt 1.8 KB roh, 07/14/2020 05:48 PM
screenshot_pins_configfoo.png View screenshot_pins_configfoo.png 109 KB roh, 07/14/2020 06:08 PM
cp2105_gtm900_cp210xsmt.txt cp2105_gtm900_cp210xsmt.txt 724 Bytes incomplete config, just as value-listing roh, 07/14/2020 07:05 PM
cp2105_gtm900_roh_test.txt cp2105_gtm900_roh_test.txt 1.76 KB roh, 07/24/2020 02:52 PM
cp2105_gtm900_roh_test_gpio.txt cp2105_gtm900_roh_test_gpio.txt 1.76 KB roh, 09/17/2020 12:53 AM
cp21xx_custom_util-screenshot1.png View cp21xx_custom_util-screenshot1.png 66.2 KB mschramm, 09/17/2020 01:43 AM
cp21xx_custom_util-screenshot2.png View cp21xx_custom_util-screenshot2.png 165 KB mschramm, 09/17/2020 01:43 AM

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)
  • verify audio wiring

Related issues

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

Actions
Actions #1

Updated by laforge almost 4 years ago

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

Updated by roh almost 4 years ago

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

Updated by roh almost 4 years ago

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

Updated by roh almost 4 years 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

Actions #5

Updated by roh almost 4 years 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.

Actions #6

Updated by mschramm almost 4 years ago

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

Actions #7

Updated by roh almost 4 years 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.

Actions #8

Updated by roh almost 4 years 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.

Actions #9

Updated by roh almost 4 years 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.

Actions #10

Updated by falconia almost 4 years 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.

Actions #11

Updated by roh almost 4 years ago

i tend not to support criminal vendors (ftdi)

Actions #12

Updated by falconia almost 4 years 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!

Actions #13

Updated by roh over 3 years 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.

Actions #14

Updated by roh over 3 years ago

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

Updated by mschramm over 3 years ago

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...

Actions #16

Updated by roh over 3 years ago

i have attached the default config of one of the boards and a suggestion (strings unmodified) from me but i am not sure about the gpio settings yet.

the documentation for this tool is basically not existant, one needs to have a whole i386 gtk installed or the java and its packaged libs will segfault left and right. also undocumented is that its errorhandling doesnt seperate between no device and no permissions (uses libusb for direct access)

there are lots of properties which are not well explained in the datasheet like the toggle suspend parameters.. also it doesnt write the chip for me but crashes with a locked-up ui.

i hope the configs are useable for the other tools we have in source format as well.

Actions #17

Updated by roh over 3 years ago

it seems cp210xsmt uses a completely different confifile format again %-/
the documentation is really sparse, i found a pdf with some snippets, but its rather incomplete.
i attach a file which has most(/all?) cp2105 supported values, but the formatting needs more work, and it doesn't support comments

Actions #18

Updated by roh over 3 years ago

some more tests with the silabs tool, this time with pulling V_IO up to 3.6V via a 1N4148 from VCC (see https://osmocom.org/issues/4030#note-42)
the 2.8V ldo may not like it, but it did not die on me doing that without disconnecting it. (it supplies 2.8V again afterwards)
i modified the strings to have something to recognise this board on without comparing SN. those are still up for discussion

atleast it tries to do something this time.

7/24/20 4:12 PM: Device connected: CP2105 - 00D753C4
7/24/20 4:12 PM: Load from: /home/roh/kunde/sysmocom/git.admin.sysmocom.de/osmo-small-hardware/gtm900-breakout/cp2105_config/cp2105_gtm900_roh.txt
7/24/20 4:33 PM: Saved to: /home/roh/kunde/sysmocom/git.admin.sysmocom.de/osmo-small-hardware/gtm900-breakout/cp2105_config/cp2105_gtm900_roh_test.txt
7/24/20 4:33 PM: Device programming started...
7/24/20 4:33 PM: CP2105 FAILED write of CP2105PortConfigGroup: PinConfig [pinConfig=[0, 0, 0, 0, 1, 1, 0, 1, 0, 0, 0, 1, 1, 0], resetValue, suspendValue, useECISuspendValues=F2FE, useSCISuspendValues=0, invertECISuspend=0, invertSCISuspend=1 enableWeakPullUp=0, rs485Invert=1]
7/24/20 4:33 PM: Device programming completed.
7/24/20 4:33 PM: Device verification started...
7/24/20 4:33 PM: CP2105 FAILED write of Product Description: GTM900 interface. Device value: CP2105 Dual USB to UART Bridge Controller
7/24/20 4:33 PM: CP2105 FAILED write of Interface 0 String: IR Port. Device value: Enhanced Com Port
7/24/20 4:33 PM: CP2105 FAILED write of Interface 1 String: Modem Port. Device value: Standard Com Port
7/24/20 4:33 PM: CP2105 Successul write of SCI/ECI Mode: 1
7/24/20 4:33 PM: Device verification completed.

which is weird... since replugging the device and restarting the tool shows that the configuration was written successful, including the strings.

[530817.046703] usb 2-1.2: new full-speed USB device number 59 using ehci-pci
[530817.158747] usb 2-1.2: New USB device found, idVendor=10c4, idProduct=ea70
[530817.158755] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[530817.158760] usb 2-1.2: Product: GTM900 interface
[530817.158764] usb 2-1.2: Manufacturer: Silicon Labs
[530817.158767] usb 2-1.2: SerialNumber: 00D753C4
[530817.159609] cp210x 2-1.2:1.0: cp210x converter detected
[530817.160745] usb 2-1.2: cp210x converter now attached to ttyUSB0
[530817.161159] cp210x 2-1.2:1.1: cp210x converter detected
[530817.161971] usb 2-1.2: cp210x converter now attached to ttyUSB1

this helps a bit, but we still have no sane way of production for this yet (non-ui-tool which has working verification)

$ lsusb -d 10c4:ea70 -v

Bus 002 Device 059: ID 10c4:ea70 Cygnal Integrated Products, Inc. CP210x UART Bridge
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x10c4 Cygnal Integrated Products, Inc.
  idProduct          0xea70 CP210x UART Bridge
  bcdDevice            1.00
  iManufacturer           1 Silicon Labs
  iProduct                2 GTM900 interface
  iSerial                 5 00D753C4
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           55
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              3 IR Port
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              4 Modem Port
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)
Actions #19

Updated by roh over 3 years ago

did some experiments with controlling the gpio under the default kerneldriver on buster.

controlling the gpio works nicely after exporting them.
the issue is that it gets pulled down by the 22k+22k to ground and the transistor quite hard.
with both in we get 0.4 and 0.2V left and right of the baseresistor.
removing the 22k to gnd from base results in 0.7 and 0.5V. still not enough to enable the npn and by far too low.
when removing the base-resistor completely one can measure proper 0V 2.8V logic levels coming from the cp2105.

i suspect the gpio are open-drain currently and the otp config is still wrong or we need pullups

Actions #20

Updated by mschramm over 3 years ago

roh wrote:

i suspect the gpio are open-drain currently and the otp config is still wrong or we need pullups

... and so they were; another OTP flash program run for toggling the two GPIOs to PP went void (using the GUI programmer).

Actions #21

Updated by laforge over 3 years ago

  • Priority changed from High to Immediate

This has been without any update for two months, which is not acceptable. Please finally get the prototype board into a working state, or report which changes mschramm should be doign to the design.

Actions #22

Updated by roh over 3 years ago

i have reworked one board to something somewhat use able for now. how to (mass) produce it is another discussion.

my changes compared to the schem. v1:
  • bugfixes:
    • R4 needs to connect to 'VDD' (generated by the modem) and not VIO_2V8
    • R25 needs to connect to 'VDD_3V45' (generated by the cp2105) not VDD
    • VIO_2v8 and VCC (4.2V after ldo) need to connect to some pinheader so VIO can be pulled higher via a standard 1n4148 diode for programming the OTP area with the attached config via the ui-tool
  • make the 4.2V ldo switchable via dtr of SCI (serial1, the one with at-interpreter), since the gpio-in are only sw-controlled and not a real reset or powerbutton and are impulse-triggered and not level triggered inputs (intended for buttons, not remote-control)
    • R14 is DNP
    • pin1 of U2 (_SHDN 4.2V ldo) should connect to the collector of T2
    • some jumper should connect to the base of T2 and ground to allow disabling of the powerdown for the modem. (force on)
    • i have rewired the _PWON jumper to test this, but maybe it should stay and be renamed (see below)
  • notes:
    • there seem to be some leakage coming from the modem itself (gone when fpc cable removed), so LED1 is glowing faintly when the modem is off.
    • when the modem is not powered on on usb-connect (vio and vcc raise together/jumper removed) the modem stays powered 'off' till any of the gpio line toggle. when the powerbtn is kept pressed (like the old _PWON jumper) the modem boots directly when opening the serial1, so maybe we should have 2 jumpers: one for disabling the poweroff (T2 base to gnd), one for forcing automatic boot. (ex _PWON)
    • serial0 is the debug(irda) serial, ECI
    • serial1 is the main, AT-Command serial, SCI
i have tested the attached (ui-tool 'CP21xxCustomizationUtility') config on debian buster with a 4.19.118-2+deb10u1 and the gpio-tools:
  • gpioinfo finds 2 lines (0 is powerbtn, 1 is reset)
  • gpioset gpiochip0 0=1
  • gpioset gpiochip0 0=0
  • gpioset gpiochip0 1=1
  • gpioset gpiochip0 1=0
todo and unclear items:
  • should any other of the (handshake) lines inbetween the modem and the cp2105 on SCI be push_pull instead of open drain? please help crosscheck this.
  • does the leakage when the modem is powered off matter?
  • audiofoo (why do we not wire the aux-lines? i had assumed those are the ones with line-levels)
Actions #23

Updated by mschramm over 3 years ago

(adding two instead of one screenshot because of ...scrollbars. 2nd image also shows the two UARTs in neocon)

Actions #24

Updated by roh over 3 years ago

reworked another 2 boards to have the bugfixes and the ldo_en via dtr feature (not remapping the jumper on sn2 and sn3)

i could really need some help reviewing the otp settings a final time, especially the push/pull vs open drain for the handshake lines on the first serial.
please see above screenshots of the proposed settings.
then i can flash those 2 boards, so we have 3 working prototypes.

since i have not noted it above: the 'new' ldo (mcp1827) are in with pin1 lifted (for enable rework)

also of note: the fpc connector fitting best is HFJ140CT-ND from hirose and the 'straight' fpc-cable (pins visible on both ends from one side)

Actions #25

Updated by laforge over 3 years ago

roh wrote:

i have reworked one board to something somewhat use able for now. how to (mass) produce it is another discussion.

my changes compared to the schem. v1:
  • bugfixes:
    • R4 needs to connect to 'VDD' (generated by the modem) and not VIO_2V8
    • R25 needs to connect to 'VDD_3V45' (generated by the cp2105) not VDD
    • VIO_2v8 and VCC (4.2V after ldo) need to connect to some pinheader so VIO can be pulled higher via a standard 1n4148 diode for programming the OTP area with the attached config via the ui-tool

agreed to the above.

  • make the 4.2V ldo switchable via dtr of SCI (serial1, the one with at-interpreter), since the gpio-in are only sw-controlled and not a real reset or powerbutton and are impulse-triggered and not level triggered inputs (intended for buttons, not remote-control)

I'm not quite following here. why does gpio-in matter? It should be gpio-out, right?

  • notes:
    • there seem to be some leakage coming from the modem itself (gone when fpc cable removed), so LED1 is glowing faintly when the modem is off.

this should be investigated further. We need to understand where the leakage is coming from.

  • when the modem is not powered on on usb-connect (vio and vcc raise together/jumper removed) the modem stays powered 'off' till any of the gpio line toggle. when the powerbtn is kept pressed (like the old _PWON jumper) the modem boots directly when opening the serial1, so maybe we should have 2 jumpers: one for disabling the poweroff (T2 base to gnd), one for forcing automatic boot. (ex _PWON)

I would think it's sufficient that we always boot on serial-open and always terminate on serial-close (i.e. fully DTR driven). But well, the two jumpers cannot hurt, if there are some other use cases.

  • serial0 is the debug(irda) serial, ECI
  • serial1 is the main, AT-Command serial, SCI
i have tested the attached (ui-tool 'CP21xxCustomizationUtility') config on debian buster with a 4.19.118-2+deb10u1 and the gpio-tools:
  • gpioinfo finds 2 lines (0 is powerbtn, 1 is reset)
  • gpioset gpiochip0 0=1
  • gpioset gpiochip0 0=0
  • gpioset gpiochip0 1=1
  • gpioset gpiochip0 1=0

This looks good. The question is where is the problem with those (see my question above)

todo and unclear items:
  • should any other of the (handshake) lines inbetween the modem and the cp2105 on SCI be push_pull instead of open drain? please help crosscheck this.

In the CP2105 default configuration, all outputs are PP and all inputs are OD. I would think this a relatively reasonable configuration, so in terms of PP, that would be RTS, TXD and DTR.

  • does the leakage when the modem is powered off matter?

yes, we never know what kind of undefined states this might provoke at some later point

  • audiofoo (why do we not wire the aux-lines? i had assumed those are the ones with line-levels)

Audio interface needs to be tested, which shouldn't be hard if you have the AT interface working.

Actions #26

Updated by roh over 3 years ago

  • Checklist item verify audio wiring set to Done

laforge wrote:

roh wrote:

  • make the 4.2V ldo switchable via dtr of SCI (serial1, the one with at-interpreter), since the gpio-in are only sw-controlled and not a real reset or powerbutton and are impulse-triggered and not level triggered inputs (intended for buttons, not remote-control)

I'm not quite following here. why does gpio-in matter? It should be gpio-out, right?

i was referencing it as a input to the modem. sorry for being not clear.

  • notes:
    • there seem to be some leakage coming from the modem itself (gone when fpc cable removed), so LED1 is glowing faintly when the modem is off.

this should be investigated further. We need to understand where the leakage is coming from.

i think this is the result of vio still being active. i need to check up if its possible to run the cp2105 without, but i doubt it. even then we'd need the gpios and dtr line working to power up the rest.
i can try adding some buffer which is getting powered down into the lines to the modem, but this will take quite some rework time. (lots of lines)
i will discuss with martin about suitable buffers.

  • when the modem is not powered on on usb-connect (vio and vcc raise together/jumper removed) the modem stays powered 'off' till any of the gpio line toggle. when the powerbtn is kept pressed (like the old _PWON jumper) the modem boots directly when opening the serial1, so maybe we should have 2 jumpers: one for disabling the poweroff (T2 base to gnd), one for forcing automatic boot. (ex _PWON)

I would think it's sufficient that we always boot on serial-open and always terminate on serial-close (i.e. fully DTR driven). But well, the two jumpers cannot hurt, if there are some other use cases.

i have modified one board to have both jumpers now, but need to run some more tests. i am currently assuming this 'not booting on powerup' is a result of the leakage, since its booting directly when both voltage rails come up at the same point in time.

  • does the leakage when the modem is powered off matter?

yes, we never know what kind of undefined states this might provoke at some later point

i will address this next. not sure how yet.

  • audiofoo (why do we not wire the aux-lines? i had assumed those are the ones with line-levels)

Audio interface needs to be tested, which shouldn't be hard if you have the AT interface working.

i finally tested the audio interface and it works fine with some 'came with a phone' 4pin 3.5mm jack headset from htc.
had some issues with my testsetup at first, but now i can reliably do voice links and the quality and amplitude are quite ok in default settings for me.
in the at-command-reference i found a lot of commands dealing with audio routing, filtering, echo cancellation, gain settings etc. page 175ff of 207.

i still need to realize some measurements about signal levels.
from what i've read on page 22 of the hardware documentation it seems the aux is intended for 'handsfree audio' and a much higher impedance speaker (1k instead of 32ohm) so it may be more fitting to adapting it to 'line' levels for some kind of soundcard interface.
the way the breakout board currently does the balanced->unbalanced conversion on the first audio channel works good, and i think we should leave it like it is for use with this kind of headphones.

Actions #27

Updated by laforge over 3 years ago

On Thu, Oct 01, 2020 at 09:51:54PM +0000, roh [REDMINE] wrote:

laforge wrote:

roh wrote:

  • make the 4.2V ldo switchable via dtr of SCI (serial1, the one with at-interpreter), since the gpio-in are only sw-controlled and not a real reset or powerbutton and are impulse-triggered and not level triggered inputs (intended for buttons, not remote-control)

I'm not quite following here. why does gpio-in matter? It should be gpio-out, right?

i was referencing it as a input to the modem. sorry for being not clear.

Ok, but then why would that only work if those GPIO-IN are driven via DTR?

  • notes:
    • there seem to be some leakage coming from the modem itself (gone when fpc cable removed), so LED1 is glowing faintly when the modem is off.

this should be investigated further. We need to understand where the leakage is coming from.

i think this is the result of vio still being active. i need to check up if its possible to run the cp2105 without, but i doubt it. even then we'd need the gpios and dtr line working to power up the rest.
i can try adding some buffer which is getting powered down into the lines to the modem, but this will take quite some rework time. (lots of lines)
i will discuss with martin about suitable buffers.

if we need a buffer, then for sure that wouldn't be somethin for rework but rather for the next board
revision.

to be honest, I don't fully understand what is happening here, i.e. in which exact situation you have leakage.
  • you say the leakage is from the modem while the modem is switched off.
  • LED1 is between VCC nad GND, while VCC is suplied by the permanently on LDO from the external power supply. Hence I would expect that LED to be on permanently, as long as a power supply is present
Actions #28

Updated by roh over 3 years ago

laforge wrote:

On Thu, Oct 01, 2020 at 09:51:54PM +0000, roh [REDMINE] wrote:

laforge wrote:

roh wrote:

  • make the 4.2V ldo switchable via dtr of SCI (serial1, the one with at-interpreter), since the gpio-in are only sw-controlled and not a real reset or powerbutton and are impulse-triggered and not level triggered inputs (intended for buttons, not remote-control)

I'm not quite following here. why does gpio-in matter? It should be gpio-out, right?

i was referencing it as a input to the modem. sorry for being not clear.

Ok, but then why would that only work if those GPIO-IN are driven via DTR?

i think something got mangled in transmission here: i meant that using DTR is not making sense in driving the 'button inputs' of the modem when these only trigger on pulses. (and dtr changes state once per open/close)

  • notes:
    • there seem to be some leakage coming from the modem itself (gone when fpc cable removed), so LED1 is glowing faintly when the modem is off.

this should be investigated further. We need to understand where the leakage is coming from.

i think this is the result of vio still being active. i need to check up if its possible to run the cp2105 without, but i doubt it. even then we'd need the gpios and dtr line working to power up the rest.
i can try adding some buffer which is getting powered down into the lines to the modem, but this will take quite some rework time. (lots of lines)
i will discuss with martin about suitable buffers.

if we need a buffer, then for sure that wouldn't be somethin for rework but rather for the next board
revision.

to be honest, I don't fully understand what is happening here, i.e. in which exact situation you have leakage.
  • you say the leakage is from the modem while the modem is switched off.
  • LED1 is between VCC nad GND, while VCC is suplied by the permanently on LDO from the external power supply. Hence I would expect that LED to be on permanently, as long as a power supply is present

the led is powered by the (now switched) 4.2V modem main power(see modifications, the EN pin is switched via dtr)
the leakage is from the 2.8V rail feeding the cp2105 via the datalines into the modem and back to the vcc rail.
switching the 2.8V rail too doesn't work due to henn-egg issues.

i could try adding some series resistors to minimize it - but besides that i am an bit out of ideas without using a buffer.

Actions #29

Updated by roh over 3 years ago

i have gotten the vcc led to switch completely off now (minimized the leakage) but i have not gotten rid of it completely.
most of the leakage was coming from the txd, dtr, rts and txd2 lines.
as a test i have 'isolated' those by using a 74hc4066 running from the 2.8V rail and switching all 4 switches together with the 4.2V ldo enable line (_SHDN). this works nicely, but now i see residual leakage from the cp2105 internal pullups on the input lines.

the remaining issues are:
  • power-on-default (freshly plugged in, no serial opened) seems to be dtr low, so the modem boots immediately (and is accessible via ttyUSB1) even when the serial is closed. (not sure if this is possible to be changed, but it would be nice to have it more deterministic (serial closed, modem off)
  • after first power-on it powers off on serial close (dtr high) but after reopening the serial (dtr low) it needs a low-pulse on the reset button line. (works via gpio on ECI or button). it would be nice if the modem boots by itself every time or never, but not depending on some sequence not obvious to the user.

this is getting a bit insane, and not necessarily due to the cp2105 but the not completely nice behaviour of this modem. as a next test i will completely cut the remaining flowcontrol lines (also inputs) and only wire rx/tx and rx2/tx2 via the 4066 to see if that gets any better.
disabling the (weak, ~100-200k) pullups in the cp can only be done for all its iolines together and would only move the issue to then-to-be-added-external pullups and is thus no help at all.

the current plan is to get it working reliably first (solve remaining leakage/reset issue) and then do another board spin with revised wiring.
probably a single uart cp2102N (the others are NRND/EOL anyhow) which not only features no otprom, but the 'weird' baudrates some people need as well.
the irda-serial with the debug serial will go to a 2.5mm jack as usual for the few people who really want it.

Actions #30

Updated by roh over 3 years ago

  • % Done changed from 70 to 80

i have made some progress over the weekend:

the experiment with completely cutting the remaining flowcontrol lines (also inputs) and only wire rx/tx and rx2/tx2 via the 4066 was performed and the behavior of the modem changed to 'hangs when powered down only for <5-10sec'. (can be revived by reset-pulse as before).
when the power stays off (close serial, raise dtr) for more than ~10sec the modem is 'off enough' to power up properly and have the at-interpreter ready (and yellow led blinking) in a few seconds (2-4) which is great. sadly the continous reworks took their toll and i damaged the rx2 line on the boards cp2105 layout.

next would be to verify/test it with a cp2102 (using the purely mechanical break-out board and mostly some jumperwires) where the behavior should be the same.
any idea where i can find those mschramm ?

then its new board revision time.

Actions #31

Updated by roh about 2 years ago

looking at the supply situation there seems to be no availability of anything usb-serial in 3-digit numbers but the cp2102, without N anyhow.

current plan is to use add s simple monoflop/por circuit/chip to make the modem boot properly on every poweron without needing a manually sequenced reset afterwards.
since the needed timing is yet to be determined chip selection needs to happen afterwards. hopefully a something like a simple mcp120 or similar is enough.

Actions #32

Updated by roh about 2 years ago

going to the next prototype a few details need to be nailed down:
- all lines to and from the modem go through a mux (4066) or a proper dual-rail levelshifter to remove any 2.8V rail leakages.
- is rx-tx only for each serial ok? (no hw flowcontrol) - is there an application which needs this for sure?
- the main (at-hayes) serial is onboard, the secondary aux gets its usual 2.5mm jack for those few who need it.
- power on is handled by the dtr line of the main serial and enables/disables the 4.2V
- reset is by default handled by a power-on-reset circuit slaved to the 4.2V rail coming up. we could add a jumper to allow control via dsr or such (maybe via a cap like on arduino?) - i need more input if this makes sense or if poweroff-on is also an option.

Actions #33

Updated by laforge almost 2 years ago

what's the status here? are there still any open questions or problems?

Actions #34

Updated by mschramm almost 2 years ago

  • Checklist item deleted (develop and test OTP config for cp2105)

yes. Main blocker, procurement situation, seems to have eased a little regarding the CP2102-GM and esp. CP2102N; the latter is in stock @Mouser in five-digit quantities for decent 2 € in QFN20 (QFN28: ~300 pcs. stock @Mouser); see also discussion in #4030.

But #5466 (CP2102N evaluation for burst_ind baudrate) needs to get solved before we move towards the CP2102 N version, no matter what IC package it will be available at that time. cp210x-program is not yet able to work with N series of CP2102.

Actions #35

Updated by mschramm over 1 year ago

Procurement situation has eased a little: Digikey and Mouse stock the N version of CP2102 in QFN-20, -24 and -28 in huge five-digit quantities for about 2€, whereas the old version CP2102-GM is available (both DK and Mouser have about 25k resp. 13k), but only in QFN-28 and for more than twice the price of N version (about 5€), while of course still being NRND. - #5466 still block usage of N version.

Actions #36

Updated by laforge 4 months ago

  • Subject changed from Build + Test GTM900 breakout board prototype to Build + Test CP2102 GTM900 breakout board prototype
  • Status changed from In Progress to Closed

closing this old ticket

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)