FreeCalypso > hg > freecalypso-docs

comparison FC-handset-spec @ 51:7933c3a1b5e0

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
FC-handset-spec: power domain mess documented
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 11 Jun 2021 08:04:44 +0000
parents da1a2a32c260
children cfe8623b915d
comparison
equal deleted inserted replaced
50:da1a2a32c260 51:7933c3a1b5e0
774 inconvenience. Back in the days of Openmoko, someone must have had a similar 774 inconvenience. Back in the days of Openmoko, someone must have had a similar
775 experience, as I remember reading about a hack where someone built a debug board 775 experience, as I remember reading about a hack where someone built a debug board
776 functional equivalent that fits inside the Neo, in some otherwise unused space. 776 functional equivalent that fits inside the Neo, in some otherwise unused space.
777 777
778 Hence the new design for our planned FC Libre Dumbphone handset: the USB port 778 Hence the new design for our planned FC Libre Dumbphone handset: the USB port
779 will have a built-in FT2232D subsystem (USB to two UARTs) connected to it, 779 will have a built-in FT2232D (or perhaps FT2232H) subsystem (USB to two UARTs)
780 interfacing to both Calypso UARTs, while the charging on/off switch will make it 780 connected to it, interfacing to both Calypso UARTs, while the charging on/off
781 possible to use this interface for low-level development and bring-up without 781 switch will make it possible to use this interface for low-level development
782 presenting VCHG to the chipset. In this architecture this FT2232D subsystem 782 and bring-up without presenting VCHG to the chipset. In this architecture this
783 should be considered the primary "owner" of the handset's USB port, while the 783 FT2232x subsystem should be considered the primary "owner" of the handset's USB
784 charging function is secondary and optional, enabled or disabled with a switch. 784 port, while the charging function is secondary and optional, enabled or disabled
785 To put it another way, if our USB port is connected to a regular USB host (as 785 with a switch. To put it another way, if our USB port is connected to a regular
786 opposed to a Dedicated Charging Port power-only source), that USB host will 786 USB host (as opposed to a Dedicated Charging Port power-only source), that USB
787 always enumerate the FT2232D and see two ttyUSB devices, whereas charging may 787 host will always enumerate the FT2232x and see two ttyUSB devices, whereas
788 or may not take place depending on the switch setting. 788 charging may or may not take place depending on the switch setting.
789
790 1.12.1. Set of UART signals
791
792 The set of signals to be connected between Calypso and FT2232x for the Modem
793 UART is almost complete:
794
795 USB UART
796 DTE signal Calypso signal
797 ------------------------------
798 TxD RX_MODEM
799 RxD TX_MODEM
800 RTS CTS_MODEM
801 CTS RTS_MODEM
802 DTR GPIO3
803 DCD GPIO2
804 RI GPIO8
805
806 Only DSR is omitted for the Modem UART channel, all others are included. The
807 second debug UART channel is only two wires:
808
809 USB UART
810 DTE signal Calypso signal
811 ------------------------------
812 TxD RX_IRDA
813 RxD TX_IRDA
814
815 However, as shown in the next section, these signals cannot be simply connected
816 between Calypso and FT2232x, and a more complicated scheme needs to be
817 implemented instead.
818
819 1.12.2. USB and mobile power domains
820
821 Our FC Libre Dumbphone handset will have two principal power domains in it: the
822 main battery-powered mobile domain, and the USB domain. This power domain
823 situation presents some very significant challenges, a problem generally
824 referred to as "partial power-down". There are two PPD scenarios to be
825 concerned about:
826
827 1) In normal operation the phone is mobile and not connected to USB. In this
828 state the mobile power domain is on, whereas USB-powered circuits in the
829 FT2232x subsystem have no power. The two challenges in this state are:
830
831 1a) We need to ensure that no currents flow from the powered-on mobile domain
832 into powered-down USB domain circuits, as any such currents would be an
833 unacceptable drain on the battery.
834
835 1b) Calypso UART inputs that come from the USB domain when the latter is active
836 need to have defined logic levels on them when the USB domain has no power:
837 no floating, no mid-way levels that would cause higher currents in CMOS
838 input structures, and furthermore, some Calypso inputs need to be high in
839 this state, while others need to be low.
840
841 2) A reverse PPD scenario occurs when the USB domain has power, but the
842 Calypso+Iota chipset is in its switched-off state per Iota VRPC. This
843 scenario can occur when the charging switch is set to off, or when the
844 battery is critically low and undergoing precharge. The main concern in
845 this state is to avoid feeding power from the USB domain into the Calypso
846 chipset's V-IO rail - our experience on Caramel2 boards conclusively
847 demonstrates that Calypso does not like this condition and can behave oddly,
848 erratically feeding current into its outputs that are supposed to be low or
849 Hi-Z, and thereby erratically turning on various peripherals.
850
851 If we were to naively connect our UART signals between Calypso and FT2232x, the
852 result would be bad: all of the above concerns would be violated. Instead we
853 need to insert carefully designed isolating buffer circuits in both directions.
854
855 1.12.2.1. Calypso to FT2232x signal direction
856
857 If these signals were connected directly, significant current (in the mA range)
858 would flow from Calypso outputs into powered-down FT2232x inputs, which is not
859 acceptable. Our solution is to insert an LVC buffer (probably 74LVC541A, for
860 the 5 signals that are needed) between Calypso outputs and FT2232x inputs, with
861 the buffer powered from USB domain 3.3V supply. With mobile on and USB power
862 absent, the LVC buffer's Ioff spec will apply, which is listed in Nexperia's
863 74LVC541A datasheet as 0.1 uA typical, 10 uA maximum.
864
865 An unfortunate consequence of this design is that in the opposite PPD scenario
866 (USB connected to a host, charging switch off, mobile chipset in its off state)
867 the inputs to the LVC buffer will float, with FT2232x inputs receiving garbage
868 as a result. Adding pull-up resistors to a USB-domain supply would cause other
869 problems, hence the Mother's position is that we'll just live with a few
870 floating inputs in this particular condition - and it is a condition that
871 should not persist for extended lengths of time. There is also a software
872 consideration stemming from this floating input situation: when you are doing
873 low-level programming and development operations in this state, don't open the
874 Modem UART ttyUSB device, and only operate via the other debug UART. The latter
875 is a 2-wire UART without any flow control or modem control signals, hence there
876 will be less bogosity for the Linux host to see in this state.
877
878 1.12.2.2. FT2232x to Calypso signal direction
879
880 This direction is even more difficult, and we will need to insert two chained
881 LVC buffers: the signals will first pass through an LVC buffer powered from the
882 USB domain, and then through another LVC buffer powered from the Calypso+Iota
883 chipset's V-IO rail. There will be pull resistors inserted between the two
884 buffers: either pull-up to VBAT (raw battery positive rail) or pull-down to GND,
885 depending on the needed signal sense.
886
887 The LVC buffer powered from Calypso V-IO is needed in order to prevent current
888 feeding into Calypso when the mobile is switched off - the buffer's Ioff spec
889 will apply. Pull-up and pull-down resistors in front of this buffer are needed
890 so that Calypso inputs will receive the desired states when no USB host is
891 connected. Pull-ups are being made to VBAT instead of V-IO to eliminate the
892 possibility of current feeding into V-IO through these resistors. (Feeding
893 from 3.3V logic signals into the battery can't happen when the battery is above
894 3.3 V, and if the battery is below 3.3 V, then we are only adding a little to
895 the precharge current.)
896
897 The other LVC buffer (the one powered from USB-domain 3.3V) is needed because
898 in the absence of this buffer, current will flow through pull-up resistors and
899 into powered-down FT2232x output pins, the resulting pull-down resistance will
900 be lower than the pull-up, and the next buffer won't receive the desired logic
901 level, not to mention unwanted current flowing. With the other LVC buffer
902 added, that buffer's Ioff spec will apply.
903
904 The value of pull-up resistors to VBAT will be 22 kOhm. With maximum 15 uA
905 current flowing through each resistor (worst-case Ioff of one buffer plus
906 worst-case Ii of the other buffer), the maximum voltage drop on the 22 kOhm
907 resistor will be 330 mV. In order for the LVC buffer's input structure to not
908 draw extra current, the input voltage needs to be 2.8 V or higher - thus with
909 22 kOhm resistors we'll keep satisfying this condition until the battery falls
910 to about 3.1 V, which is below the operational range for switched-on mobile.
911
912 One downside of having pull-ups to VBAT (which can be as high as 4.2 V) on
913 signals that are output from a 3.3V-powered buffer is that when the buffer
914 output is high, there may be current flowing into that high output (not sourcing
915 out of it as normally expected), which is a bad condition for CMOS outputs.
916 However, this current will be limited to a maximum of about 40 uA
917 ((4.2-3.3 V) / 22 kOhm), and my feeling is that such small current won't hurt
918 Nexperia LVC buffers.