Motorola über die USB-Schnittstelle laden? So gehts...

Moin, habe mal bewusst einen "neuen" Beitrag daraus gemacht, damit das mit der Suche gefunden werden kann.


Das Laden geht nur mit den richtigen Widerständen und Brücken.

Code:

Mini-USB Male from front-side

 USB Stecker - Gesehen von vorn in den Stecker hinein

	+---------------+
	\		/
	 +  5 4 3 2 1  +
	 |	       |
	 +-------------+


 Pinbelegungen:

  +--200k-+	 +-------+ 	5,2V=	Netzteil 220V~

  +--200k-+	 +-------+	5,7V=	Autoset2 12V= -> 5,7V=

  5	 4	 3	 2	 1	PINOUTS aus englischen Manuals

 GND	200k	 +-------+	5,0V	Charger Mid 0,5A WallCh

 GND	440k	 +-------+	5,0V	Charger Fast 1,25A

Das ist nur ein Auszug, die an der USB-Buchse befindliche EMU-Schnittstelle kann sehr viel mehr,
so at this piont you have to speak english very well:

Non-adjunct EMU Bus Hardware/Software
Interface Control Document







Motorola, Inc.
Personal Communications Sector
Razor Product Group
October 24, 2003

1. Revision History 6
2. Introduction 7
2.1. Purpose and Scope 7
2.2. Nomenclature and Conventions 7
2.2.1. Acronyms and Abbreviations 7
2.3. Contact Information 7
2.4. References 7
3. Hardware Interface 8
3.1. EMU Block Diagram 8
3.2. Detailed Signal Description 8
3.2.1. Power 9
3.2.2. Communication (USB/RS232) 10
3.2.3. Interrupt and Control 10
3.2.4. Audio 11
3.3. GPIO Usage 12
3.3.1. Statically Configured GPIO 12
3.3.2. Dynamically Defined GPIO 12
4. Software Interface 12
4.1. Neptune Configuration 12
4.1.1. GPIO Configuration 12
4.1.2. External Interrupt Configuration 13
4.2. PCAP Configuration 13
4.2.1. Interrupts 13
4.2.1.2. USB_4_VI 14
4.2.2. General Control 14
4.2.3. A/Ds 14
4.3. Detection and Identification 15
4.3.1. Detection 15
4.3.2. Identification 16
4.4. Device Handling 18
4.4.1. USB CABLE: 18
4.4.2. Factory Mode: 19
4.4.3. SW Regression Mode: 19
4.4.4. Smart SPD or PPD: 19
4.4.5. Chargers (MPx and EMU): 19
4.4.6. EMU SIHFs: 19
4.4.7. Mono EMU Headset 20
4.5. Charging and Metering 20
4.5.1. Hardware Control of Power Paths 20
4.5.2. USB Host Charging 20
4.5.3. Midrate Charging 21
4.5.4. Fullrate Charging 22
4.5.5. Battery Metering 22
4.5.6. Charging Flowcharts 22
4.6. Smart Device Support 28
4.6.1. Smart Device Identification 28
4.6.2. Audio/UART Mode Switching 30
5. Factory Interface 31
5.1. Test Command Requirements 31
5.1.1. EMU_AUDIO (Official Name TBD) Test Command 31
5.1.2. SET_CHARGER Test Command 32
5.2. Test Coverage 32
5.2.1. Test Bay Requirements 32
5.2.2. Testing Details 32
6. Philips ISP1109 Addendum 35
6.1. Hardware Signals 35
6.2. ISP1109 SPI Interface Specification 36
6.2.1. ISP1109 SPI Transfer Settings and Data Format 36
6.2.2. ISP1109 SPI Register Map 36
6.2.3. ISP1109 Register Definitions 37
6.3. Statically Configured GPIO 39
6.4. Dynamically Configured GPIO 39
6.5. Interrupt Handling 39
6.6. Bus Configuration 40
6.7. Factory Mode Detection and Factory Mode 40
6.8. External Power Path Control 40
6.9. Factory Considerations 40
6.9.1. Test Command Requirements 40
6.9.2. Turn On 40
6.9.3. EMU_AUDIO Test Command Changes 40
6.9.4. ID Line Test coverage 41

Figures
Figure 3‑1: Razor EMU Bus Block Diagram 8
Figure 4‑1: PPD_INT_B Debounce 16
Figure 4‑2: Self Powered Device Identification 17
Figure 4‑3: Phone Powered Device Identification 18
Figure 4‑4: Radio Off, No Battery or Vbus device, Attach Vbus device 22
Figure 4‑5: Radio Off, Battery Present, Attach Vbus Device 23
Figure 4‑6: Charge_USB_RX 24
Figure 4‑7: Charge_All_RX 25
Figure 4‑8: Charge_Fast_TX 26
Figure 4‑9: Charge_Mid_TX 27
Figure 4‑10: Charging USB TX 28
Figure 4‑11: Smart Device Identification 29
Figure 4‑12: Phone Initiated Audio to UART Mode Switch Ladder 30
Figure 4‑13: Accessory Initiated Audio to UART Mode Switch Ladder 30
Figure 5‑1: EMU_AUDIO Test Command Flowchart 31
Figure 5‑2: Factory Sequence for Radio Turn-on 33
Figure 5‑3: ID Line Testing Flowchart 34
Figure 6‑1: SPI Transfer Format 36
Figure 6‑2: EMU_AUDIO Test Command (Radio Perspective) 41
Figure 6‑3: ID Line Test Coverage for ISP1109 Based Systems 41

Tables
Table 3‑1: Consolidated Signal Description 9
Table 3‑2: EMU Interrupt Sources 10
Table 3‑3: EMU Control Signals 10
Table 3‑4: Bus Mode Control 11
Table 3‑5: Statically Defined GPIO 12
Table 3‑6: Dynamically Configured GPIO 12
Table 4‑1: GPIO Configuration Reference 13
Table 4‑2: PCAP Interrupts, Sense, and Masks 14
Table 4‑3: PCAP General Control Signals 14
Table 4‑4: A to D Thresholds for Device Identification 15
Table 4‑5: Default Signal States for Detection and Identification 15
Table 6‑1: ISP1109 Based EMU Signals 35
Table 6‑2: ISP1109 Register Map 37
Table 6‑3: MCR1 Bit Definitions 37
Table 6‑4: MCR2 Bit Definitions 37
Table 6‑5: ACR Bit Definitions 38
Table 6‑6: TCR Bit Definitions 38
Table 6‑7: RCR Bit Definitions 38
Table 6‑8: ISR Bit Definitions 38
Table 6‑9: ILR Bit Definitions 38
Table 6‑10: IEN_LOW Bit Definitions 39
Table 6‑11: IEN_HIGH Bit Definitions 39
Table 6‑12: Statically Configured GPIO 39
Table 6‑13: Bus Configuration Settings 40

1. Revision History

Revision Date Author(s) Reason
0.1 10/1/2003 Don La Monica
Tim McCune Initial Draft. Incomplete Release.
0.2 10/24/2003 Don La Monica
Tim McCune Initial Release for review. Major additions/editing. Smart device section incomplete (not needed for phase 1 or Razor SA).
0.3 10/27/2003 Tim McCune
Don Lamonica Corrected SW_BP_EN to PA6 in tables 3-5 and 4-1
Corrected PPD_DET_I to PPD_DET_B in section 4.3.1.2
General corrections (spelling/grammar)
“Apps” added in figure 4-6
Corrected USB_PS description
Swapped Mono Headset and not used in Table 3-4
Changed 0 and 1 to ASSERTED and DEASSERTED for clarity in table 3-4
Corrected HAPI_USB_HW and HAPI_USB_HW_5 in table 4-1
Changes related to dual path charging
PA13 Changed to MID_RATE_CTRL
SW_CUR_SEL removed
Changes to device handling for USB cable
PE12 Changed to FACT_DET (High voltage ID detect)
Added content to Factory Interface Section
Charging Sections changed to reflect modified dual path architecture.
0.4 12/16/03 Tim McCune
Don La Monica PPD identification flow chart changed to reflect changes in the EMU specification.
Changed MUX lines to original configuration (due to leakage paths)
Added current check prior to turn on.
Clarification on stereo tests (only SPKR_R needs to be tested).
Added FACT_DET control of external power path
Removed HV_FLASH
Added HAPI signal cross-reference for all hardware signals
Added ISP1109 (Philips EMU IC) Addendum
Added Charge_USB_RX flow chart
Updated Charge_MID_TX
0.5 3/17/2004 Tim McCune Updated title to reflect expanded scope.
Updated software regression and factory modes wrt charging.
Updated SPD detection for SHIF
Added SET_CHARGER test command

2. Introduction
2.1. Purpose and Scope
This document is meant as a design guide for the hardware and software implementation of the EMU bus based on the use discrete components or Philips ISP1109 IC, Neptune LTE, and PCAP2. The upper layers of EMU bus support (anything above rtime) should not change when moving to a fully integrated solution; however some degree of low level change is expected.
Once completed all aspects of the HW/SW interface for this EMU bus implementation will be covered within this document
2.2. Nomenclature and Conventions
2.2.1. Acronyms and Abbreviations
USB Universal Serial Bus
EMU Enhanced Mini USB
PPD Phone Powered Device
SPD Self Powered Device
SE1 Singled Ended 1
ISR Interrupt Service Routine

2.3. Contact Information
Any document issues, questions, or input should be relayed to the following:

Tim McCune Tim.McCune@motorola.com +1-847-523-2735
Don La Monica D.Lamonica@motorola.com +1-847-523-8285
2.4. References
All EMU bus specifications can be found at:
compass.mot.com/go/emu

EMU Bus: Audio Architecture
EMU Bus: Power Architecture
EMU Bus: Detection, Identification, and Control
3. Hardware Interface
3.1. EMU Block Diagram

Figure 3‑1: Razor EMU Bus Block Diagram
3.2. Detailed Signal Description


Signal Connection Description
VBUS Mini USBßàEMU control logic & power Supplies power to the radio from SPD’s. Acts as SW_B+ for PPD’s. Used in SPD detection
D+ Mini USBßàEMU control logic & muxing Used for device identification. Acts as D+ for USB mode, UART RXD in UART mode
MIC_IN in audio mode
SPKR_R in stereo mode
D- Mini USBßà EMU control logic & muxing Used for device identification. Acts as D- for USB mode, UART TXD in UART mode
SPKR_OUT in audio mode
SPKR_L in stereo mode
ID Mini USB ßà EMU control logic & sense Used for PPD detection,
Device identification.
Acts as MUTE to SIHF (controlled by SNP_INT_CTL)
Acts as SEND/END for headset
MID_RATE_CTRL Neptune à EMU charging control logic Controls the external power supply path
SNP_INT_B*** EMU Detection hardware à Neptune Signal Negotiation Protocol Interrupt
CHRG_DET_PU_B*** Neptuneà EMU control logic
SNP_INT_CTL*** EMU Detection hardware à Neptune Control signal to pull the ID line low.
USB_EN_B*********** Neptune à EMU Power control
MUX1*************** Neptune à Audio/Data selection mux Function multiplexor selection line
MUX2*************** Neptune à Audio/Data selection mux Function multiplexor selection line
SW_BP_EN******* Neptune à EMU Power control Switched B+ enable
PPD_INT_B********* EMU Detection hardware à Neptune Phone Powered Device Detect
SPKR_R PCAPà Audio/Data selection mux Speaker right input to audio/data mux
SPKR_L PCAPà Audio/Data selection mux Speaker left input to audio/data mux. Also used for SPKR_OUT for headset/car kit
MIC_IN Audio/Data selection mux à PCAP MIC input to PCAP from audio/data selection mux
FACT_DET EMU Control logic ßà Neptune Indicates factory mode entered by elevated ID voltage at power up. Used to enable the external power path under SW control
EMU_2.8 2.8V reg à EMU logic
EMU_3.3 3.3V reg à EMU logic
AD6 IDà PCAP Used to sense the voltage on the ID line
USB_PWR EMU control à PCAP Gated version og VBUS to PCAP USB power input.
USB_TXENB Neptune à PCAP Used in USB mode to enable USB TX. Controlled from USB module
USB_VPIN PCAP à Neptune Used for VPIN in USB mode. Used to sense the D+ state for PPD identification.
USB_XRXD PCAP à Neptune USB receive data for USB mode
USB_SE0 Neptune à PCAP Single ended 0 generation in USB mode
USB_VMIN PCAP à Neptune VMIN during USB mode. Used to sense the D- state during device identification. Used as UART RXD in UARTmode
USB_VPOUT Neptune à PCAP USB TX data in USB mode. UART TXD in UART mode
Table 3‑1: Consolidated Signal Description
3.2.1. Power

The EMU bus allows charge current to be supplied by the VBUS pin. Supported VBUS sources will be Motorola Chargers, CEA-936 compliant Car-kits, USB hosts, or a factory mode supply. The charger path will be a dual-path topology with a hardware controlled discharge lockout when connected to a USB host prior to software charge current negotiation.

A Fast-Rate Charger (>1Amp capability) and a Mid-Rate Charger (>450mA capability) will be standard Motorola EMU accessories. Razor will charge from either of these charger types once they are identified as being valid. Validity will be based on a valid USB_ID value as well as a valid voltage range (4.7V-5.25V). Both will be treated as a Standard Charger in RX due to power dissipation constraints. If charger is invalid, software will not charge. EMU Chargers are not compatible with P2k or LCA.

A Factory Mode can be entered by applying VBUS voltage to the USB_ID pin. The purpose of Factory Mode is to allow power-up to occur without a battery.

When VBUS is supplied by a USB host, hardware detection will default charger to off until SW powers up and negotiates 500mA with host. If 500mA is negotiated, software will begin to charge battery. If 500mA is denied, then charging will not occur and the USB host will be treated as a data cable only.

The Radio will also have the capability to supply a switched B+ supply to VBUS originating from the battery. This supply will allow phone powered accessories to receive power from the phone. This supply will be controlled by SW_BP_EN.
3.2.2. Communication (USB/RS232)
Along with the standard USB communication between a phone and a host, another UART based protocol will also be supported. This protocol will allow a phone to communicate with a CEA-936 compliant device without the expense of requiring it to be a USB Host.

Standard USB communication will occur by utilizing the base band USB controller and UART. USB and UART muxing will occur in PCAP2.

Software will need to put PCAP in the appropriate mode by driving USB_EN_B.
3.2.3. Interrupt and Control
The following Interrupts will be generated to indicate changes in EMU Bus state.


Hardware Source Logical Interrupts Function
PCAP_INT USB4VI Indicates when VBUS added or removed. Currently proposed not to be used. All SPD insertion and removal shall be performed using MOBPORTBI
MOBPORTBI indicates when charger is added or removed
SNP_INT_B NA Indicates accessory is initiating communication with radio
PPD_INT_B NA Allows radio to initiate communication with accessory
Table 3‑2: EMU Interrupt Sources
The following signals will be used for EMU Bus Control


Signal Function
MUX1 Switches appropriate signals on D+ / D- of min-USB connector
MUX2 Switches appropriate signals on D+ / D- of min-USB connector
SNP_INT_CTRL interrupts accessory to request it to enter UART mode
FACT_DET Detects elevated ID voltage factory mode. Also used to enable the external power path via software.
MID_RATE_CTRL Controls the external power path connection
CHRG_DET_PU Connects a pull-up resistor on D+ when radio is not in USB mode
USB_EN_B Used to control the VBUS pass device to allow PCAP to detect the voltage on VBUS and switch to USB mode.
SW_BP_EN Enables the supply to phone powered devices. Also places phone powered devices in low power mode.
Table 3‑3: EMU Control Signals
3.2.3.1. Device to Device Communication Usage
The following signals are required to communicate with accessories:

PPD_INT_B: A falling edge indicates that a phone powered device has been inserted. This interrupt should be masked when a self powered device is detected. This interrupt will be asserted in conjunction with the SNP_INT_B for a self powered device due to the nature of the hardware.

SNP_INT_B: A falling edge indicates a smart device request to enter UART mode and begin communication. This interrupt should be masked during a MSà Accessory SNP_INT_B initiated by asserting SNP_INT_CTL. This signal also serves the SEND/END functionality for the EMU headset. There will be different ISR’s registered for this interrupt based on bus mode.

SNP_INT_CTL: Software will control the bus mode (audio or UART) to CEA-936 compliant accessories by driving SNP_INT_CTL as necessary (see x.x.x). This hardware signal is also used for MUTE control of the SIHF. In this mode its polarity is reversed (H = SIHF un-muted, L= SIHF muted). For maintainability it may be useful to define a separate HAPI signal the SIHF MUTE functionality.

MUX1, MUX2, USB_EN_B: The truth table below indicates how MUX1, MUX2 and USB_EN are used to place the bus in the appropriate state to switch in the correct signals.


Mode MUX1 MUX2 USB_EN_B
USB mode 0 0 ASSERTED
UART mode 0 0 DEASSERTED
Not used 0 1 X
Mono headset / carkit 1 0 X
Stereo mode 1 1 X
Table 3‑4: Bus Mode Control
SW_BP_EN: See Table 3‑3

3.2.3.2. Internal Control Usage
The following signals are used to control devices internal to the radio to allow charging, detection and for some mode changes:

MID_RATE_CTRL: See Table 3‑3

FACT_DET: This signal is used to detect fatory mode at power up. After check initial states this signal acts as the software control signal to enable the external power path. It should be set low when there is no external power present to conserve power. FACT_DET should be driven high whenever software must ensure the external power path remains connected (e.g. during Charger/SIHF identification).

CHRG_DET_PU: See Table 3‑3
3.2.4. Audio
Audio and data share the same pins on the mini-USB connector (D+ and D-). Supported Audio accessories will be a mono-headset with send/end, a car-kit (mono audio and mic) and possibly a stereo headset. The audio interface will meet the CEA-936 requirements. Note that Razor will not have a separate headset-jack due to space constraints and thus will have a mini-USB based headset. The gains will be same for a car-kit and headset (with amplifiers in the headset to change gain as needed). Echo cancellation will need to be disabled when headset audio is being sent.
3.3. GPIO Usage
3.3.1. Statically Configured GPIO
These signals retain the same GPIO configuration regardless of the operating mode of the bus. This section serves as a quick reference for the GPIO connectivity; signal definitions and usage are covered in other areas of this specification.


GPIO Pin Signal(s) Neptune Module Reuse from Triplets
PA6 SW_BP_EN MCU GPIO Y
PA11 CHRG_DET_PU MCU GPIO N
PA12 PPD_INT_B EXT INT 3 N
PA13 MID_RATE_CTRL MCU GPIO (Y)
PD8 USB_EN_B MCU GPIO N
PD10 USB_TXENB USB Y
PD11 USB_VPIN USB Y
PD13 USB_XRXD USB Y (no RTS)
PD15 USB_SE0 USB Y
PE1 SNP_INT_CTL MCU GPIO N
PE3 SNP_INT_B EXT INT 4 N
PE10 MUX1 MCU GPIO N
PE11 MUX2 MCU GPIO N
PE12 FACT_DET MCU GPIO N
Table 3‑5: Statically Defined GPIO
3.3.2. Dynamically Defined GPIO
These GPIO are used for different signals depending on the bus state.


Signal Neptune Module
USB Mode UART Mode USB UART
PD12 USB_VMIN URXD1 USB UART1 Y
PD14 USB_VPOUT UTXD1 USB UART1 Y
Table 3‑6: Dynamically Configured GPIO
4. Software Interface
4.1. Neptune Configuration
4.1.1. GPIO Configuration
Table 4‑1 contains the information required for the GPIO configuration. The required defines used by HAPI can be generated by placing “HAPI_GPIO_” prior to the hardware signal, port, and data direction columns. Those signals that have HAPI signals defined in this table already have all the required defines in hapi_gpio_defs.h, and hapi_neptune_portlist.h. They also have the required table entries in place in hapi_neptune_portlist.c. Entries with HAPI signals listed in () have the equivalent physical configuration as the listed HAPI signal, but different logical usage.

GPIO initialization states are indicated in the default column. If a pin has multiple uses the GPIO selection muxes and direction should reflect the setting for the signal that has an entry in the default column. The default state (ACTIVE/INACTIVE) of signals with an * in the default column is not configurable. For those signals with a default state indicated the corresponding bit in MCU data register for the corresponding port should be set to this state.


Hardware Signal Port Pin Data Direction Output Selection Input Selection Default Active State HAPI signal
SW_BP_EN PORT_A 6 OUTPUT 0 - INACTIVE HIGH HAPI_SW_BPLUS_EN
CHRG_DET_PU_B PORT_A 11 OUTPUT 0 - ACTIVE LOW HAPI_CHRG_DET_PU_B
PPD_INT_B PORT_A 12 INPUT - 0 * LOW HAPI_PPD_INT_B
MID_RATE_CTRL PORT_A 13 OUTPUT 0 - INACTIVE HIGH HAPI_SW_CUR_SEL
USB_EN_B PORT_D 8 OUTPUT 0 - ACTIVE LOW HAPI_USB_EN_B
USB_TXEN_B PORT_D 10 OUTPUT 2 - * LOW HAPI_USB_HW_2
USB_VPIN PORT_D 11 INPUT - 0 * NA HAPI_USB_HW_6
USB_VMIN PORT_D 12 INPUT - 0 * NA HAPI_USB_HW_5
URXD1 PORT_D 12 INPUT - 2 NA HAPI_UART1_RX1_DATA
USB_XRXD PORT_D 13 INPUT - 0 * NA HAPI_USB_HW_3
USB_VPOUT PORT_D 14 OUTPUT 2 - * NA HAPI_USB_HW_4
UTXD1 PORT_D 14 OUTPUT 5 - NA HAPI_UART1_TX1_DATA
USB_SE0 PORT_D 15 OUTPUT 2 - * HIGH HAPI_USB_HW
SNP_INT_CTL PORT_E 1 OUTPUT 0 - INACTIVE HIGH HAPI_SNP_INT_CTL
SNP_INT_B PORT_E 3 INPUT - 1 * LOW HAPI_SNP_INT_B
MUX1 PORT_E 10 OUTPUT 0 - ACTIVE HIGH HAPI_MUX_1
MUX2 PORT_E 11 OUTPUT 0 - ACTIVE HIGH HAPI_MUX_2
FACT_DET PORT_E 12 INPUT 0 0 * HIGH HAPI_FACT_DET
Table 4‑1: GPIO Configuration Reference
4.1.2. External Interrupt Configuration
There are only three physical external interrupt sources used for EMU bus. These are the PCAP interrupt connected to INT1 and configured exactly as it is in Triplets (no code changes required); the PPD_INT_B connected to INT2 and configured exactly as the Option select 2 interrupt in Triplets (probably should create a new signal for clarity, but can copy defines); and the SNP_INT_B which must be reconfigured based on the attached accessory.
4.2. PCAP Configuration
4.2.1. Interrupts
PCAP interrupts will be indicated to software by the PCAP_INT signal. Software will then read the ISR and PSTAT registers to determine source of interrupt and debounce as required.

The following PCAP interrupts will be used:


Interrupt PCAP Register Bit Bit Definition
MOBPORTBI Reg 0: ISR 10 1=interrupt generated, write 1 to clear
MOBPORTBM Reg 1: IMR 10 1=MobportBI is masked
MOBPORTBS Reg 2:PSTAT 10 0=MobportB not present, 1=MobportB present
USB4VI Reg 0:ISR 6
USB4M Reg 1:IMR 6
USB4S Reg 2:PSTAT 6
Table 4‑2: PCAP Interrupts, Sense, and Masks
4.2.1.1. MOBPORTI
This interrupt will be used to indicate when any self powered device is attached. It is also used to detect the removal of any SPD (including the USB data cable). An interrupt will be generated on a rising and falling edge of MobportB. MobportI has corresponding sense and mask bit
4.2.1.2. USB_4_VI
Currently this interrupt is unused. Only the USB_4_VS bit is used during identification of the attached accessory.
4.2.2. General Control
The following signals are used for general control and are accessed through PCAP control registers.


Hardware Signal PCAP Register Bit SW Init State Active State HAPI signal
USB_PU 0x14 2 DE-ASSERTED HIGH PCAP1_HAPI_USB_VCCRENB
VUSB_EN 0x14 4 DE-ASSERTED HIGH HAPI_VUSB_EN
USB_PS 0x14 5 ASSERTED HIGH HAPI_USB_PS
RS232ENB 0x14 9 DE-ASSERTED LOW PCAP1_HAPI_RS232_TRANSCEIVER_EN
RS_232_DIR 0x14 10 ASSERTED HIGH HAPI_RS_232_DIR
Table 4‑3: PCAP General Control Signals
USB_PU: Used to enable the 1.5k pull up on the D+ line. Asserted to begin the enumeration process once a USB host is detected.
VUSB_EN: Manually enables the USB transceiver. The USB transceiver must be manually enabled to properly identify PPD’s and during factory mode. Since all currently defined SPD’s will supply > 4V on VBUS the USB transceiver should be enabled simply by asserting USB_EN_B during SPD identification.
USB_PS: This signal is used to select the supply input for the PCAP internal USB regulator. USB_PS should be de-asserted only during PPD device identification and factory mode.

RS232ENB: Enables the RS-232 transceiver when asserted. This signal is overridden if USB power is sensed by PCAP. RS232ENB must be asserted during UART communication modes. It must be de-asserted during audio mode.

RS_232_DIR: Controls the lines to which UART TXD and RXD are connected. Currently this signal should be asserted at all times.
4.2.3. A/Ds
PCAP A/D’s will be used for device identification as well as battery and charge metering.
4.2.3.1. A/D Thresholds
The table below shows the A/D thresholds for PCAP channel AD6 which will be used for device identification. Since a resistor value depicts different accessories depending on context, only the resistor value is shown.


ID Resistor Counts Min Counts Max
Open 215 255
440k 157 214
200k 113 156
102k 52 112
10k 10 51
1k 0 9
Table 4‑4: A to D Thresholds for Device Identification
4.3. Detection and Identification
This section covers the details of configuration and low-level sequencing required for detection and identification of EMU bus accessories. The high level design is available in the EMU Bus Detection and Identification Specification.
4.3.1. Detection
Device detection is accomplished through 2 sources. Self powered device attachment is detected through the MOBPORTBI generated by PCAP2. Phone powered device attachment and removal is detected through the PPD_INT_B signal.
4.3.1.1. Default Signal States for Detection and Identification
The table below provides the required default states of the control signals to enable proper accessory detection.


Signal Idle (no accessory) State Source Notes
USB_EN_B ASSERTED Neptune GPIO Needs to be asserted to allow USB transceiver to be enabled when an SPD is detected for polling D-
CHRG_DET_PU_B ASSERTED Neptune GPIO Connects 200k PU to D+ for charger/smart device identification
SNP_INT_CTL DE-ASSERTED Neptune GPIO Must be de-asserted to allow proper detection/identification of the ID line
USB_PU DE-ASSERTED PCAP Must be de-asserted to avoid being detected by a USB host during detection/identification. Should be switched in by USB driver (no different that CE bus)
MUX1 ASSERTED Neptune GPIO Must be asserted to ensure no load ing from the audio lines.
MUX2 ASSERTED Neptune GPIO Must be asserted to ensure no load ing from the audio lines.
RS232_EN_B DE-ASSERTED PCAP Must be de-asserted to ensure RS-232 transceiver dos not drive TXD line
MOBPORTBM DE-ASSERTED PCAP De-asserted to ensure MOBPORTBI is generated for SPD detection.
Table 4‑5: Default Signal States for Detection and Identification
4.3.1.2. Debounce and Race condition handling
When a self powered device is detected (PCAP interrupt received with the MOBPORTBI bit set) the software should clear the MOBPORTB interrupt and debounce the insertion for TBD ms (current CE bus accessory debounce is 8 x 120ms). The debounce can be accomplished by polling the MOBPORTBS and MOBPORTBI bits in PCAP2. During the debounce of SPD detection both the MOBPORTBI and the PPD_DET_B interrupts should be masked.

Due to the MPx charger there will be cases in which both the PPD_DET_B and MOBPORTBI/S signals will be active. This situation also has an inherent race condition between the tow of these interrupts. It is proposed this race condition be handled within the debounce of the PPD_DET_B interrupt. Below is an example of how to handle the debounce.


Figure 4‑1: PPD_INT_B Debounce
4.3.2. Identification
Device class identification is performed by rtime using a combination of the D+ and D- lines in conjunction with the voltage level on the ID pin (read by AD6). There are four classes of SPD’s and three classes of PPD’s.

SPD device classes are:

USB Host devices which include
a. Standard USB Cable
b. Factory Mode USB
c. Software regression USB
Chargers including
d. Fast charger
e. Mid rate charger
f. MPx Chargers
Dumb self powered audio devices (Fast and mid rate SIHF)
Smart self powered UART device
g. Smart Audio devices
h. Other smart devices

All SPD device classes are identifiable by rtime. Devices within classes 1 through 3 can be fully identified within rtime. Upper layer interaction (connectivity, apps) is required to fully identify any class 4 device.

PPD device classes are:

USB OTG devices (outside the scope of this document)
Dumb PPD’s (Headset, Quill)
Smart phone powered devices
a. Smart phone powered audio device (eg FM Radio)
b. Other smart phone powered devices

The following sections detail the specifics of device identification for SPD’s and PPD’s.
4.3.2.1. Self Powered Device Identification
Figure 4‑2 diagrams the sequence that should be used for the identification of the various SPD’s.



Figure 4‑2: Self Powered Device Identification
4.3.2.2. Phone Powered Device Identification

Figure 4‑3: Phone Powered Device Identification
4.4. Device Handling
Following are the descriptions of the different modes/devices and the types of messages that should be generated between components. These descriptions can be used for the design and implementation of any new messaging required.
4.4.1. USB CABLE:
Once a USB cable has been identified by rtime the following events should occur:
Note: If the user attaches a charger very slowly there is a chance it will be ID’d as a USB cable. Due to this issue rtime should continue to poll for an SE1 until the radio has enumerated.
If the radio has powered up as a result of cable insertion rtime powers down the radio. With the addition of dual path charging capability there will be no current path from USB_PWR to the battery when the radio is off therefore the radio can remain off when a data cable is inserted.
rtime notifies connectivity of the USB cable attachment (same as CE bus)
rtime notifies SBCM of the attachment of a USB_HOST_CHARGER (new)
SBCM requests current capability through connectivity
Connectivity notifies SBCM of host current capability
If current capability is 500mA, SBCM treats as a midrate charger (end)
If current capability is 100mA no charging is performed. This is a Razor specific implementation. Future EMU bus products may allow trickle charging when the USB host allows only 100mA.

4.4.2. Factory Mode:
This mode is used as a replacement for the generic external power power up case of CE bus. No charging is allowed in this mode. The following events should be generated:
If the radio has powered up as a result of the cable insertion rtime notifies DL of an external power power up.
Assert VUSB_EN, de-assert USB_PS, mask MOBPORTBI. Needed to allow for testing on the USB_PWR signal without disrupting USB communications in the factory.
rtime notifies connectivity of USB cable insertion. Connectivity should not negotiate for charging current.
rtime notifies SBCM of external power present. (may not be needed)

4.4.3. SW Regression Mode:
This mode allows the SW regression test station to power up the radio from external power while maintaining the ability to charge. Charging shall be disabled until a set charger type test command has been received (see section xxxxxxxxxx).
If the radio has powered up as a result of the cable insertion rtime notifies DL of an external power power up.
rtime notifies connectivity of USB cable insertion. Connectivity should not negotiate for charging current.
4.4.4. Smart SPD or PPD:
These modes are covered in Section 4.6.
4.4.5. Chargers (MPx and EMU):
If the radio has powered up as a result of device insertion rtime notifies DL of a charger power up.
rtime sets the current limit according to the type of charger attached notifies SBCM of charger attachment.
4.4.6. EMU SIHFs:
Note: The MUX1/2 lines should be set to the appropriate audio mode prior to enabling the audio amplifiers.
If the radio has powered up as a result of device insertion rtime notifies DL of a charger power up.
rtime notifies DL of SIHF attachment
rtime sets the current limit according to the type of charger attached notifies SBCM of charger attachment.
4.4.7. Mono EMU Headset
Note : The MUX1/2 lines should be set to the appropriate audio mode prior to enabling the audio amplifiers.
rtime notifies DL of headset attachment.
DL notifies audio of device?
rtime registers the SNP_INT_B interrupt for SEND/END functionality.

4.5. Charging and Metering
Battery charging scheme will be similar to P2k/Triplets which is a dual path configuration.
Changes to algorithms will be made to accommodate new voltage and current requirements of EMU Bus. Charge and discharge metering will remain the same as triplets.
4.5.1. Hardware Control of Power Paths
Hardware control in the phone will prevent discharging from the USB bus until software has negotiated 500mA with the host. This control will force a power-up to occur from the battery instead of external power when connected to a host. This means that charging from the host will not be possible if the battery is dead

This hardware control will be active before software is executing and will be overridden by software at power up by MID_RATE_CTRL.

At initial power up, charger detection must occur prior to configuring MID_RATE_CTRL. The following will determine how to configure MID_RATE_CTRL at power up:

No Charger present: MID_RATE_CTRL=1
USB Host present: MID_RATE_CTRL=1
Midrate Charger present: MID_RATE_CTRL=0
Fullrate Charger present: MID_RATE_CTRL=0

In addition, MID_RATE_CTRL must be driven high prior to entering TX mode when a charger is not present. This is to prepare for a USB host or Midrate Charger to be inserted.
4.5.2. USB Host Charging
4.5.2.1. USB Charging in RX
If the battery has enough capacity to allow a power up to occur when connected to a host, software must immediately negotiate 500mA for charging. If 500mA is granted, then software will continue to drive MID_RATE_CTRL high and begin to charge the battery. If 500mA is denied, then software will program the DAC to OFF (this is for future compatibility) and will continue to drive MID_RATE_CTRL high. The user will not see a charge indication and standard discharge metering will be used.

When charging in RX over USB, the standard CC/CV charging algorithm will be used but the phone will be set up in a single path configuration. Because of this, provisions will be made to enter CC mode if voltage drops while in CV mode. Current will be ramped up in steps as is done with a Midrate charger in existing products. The steps and current will be redefined such that:

CHARGE_RX_RANGE_1: Batt<3.3V, Icharge=250mA
CHARGE_RX_RANGE_2: 3.3<Batt<3.7, Icharge=350mA
CHARGE_RX_RANGE_3: 3.7<Batt<4.2V, Icharge=450mA


4.5.2.2. USB Charging in TX
When TX is entered when attached to a USB host, a variant of the Midrate Current Share Mode will be used. Previously, the DAC would be set to 500mA which would collapse the Midrate supply. It is not allowable to collapse the supply of a USB host. Instead, the charge current must be set to different values based on battery voltage for thermal management.

The TX algorithm will operate such that initial charge current will be based on the following:

USB_CHARGE_TX_RANGE_1: Batt<3.3V, Icharge=250mA
USB_CHARGE_TX_RANGE_2: 3.3<Batt<3.7, Icharge=350mA
USB_CHARGE_TX_RANGE_3: 3.7<Batt<4.0V, Icharge=450mA

Note that the above range is the same as RX ranges except that USB_CHARGE_TX_RANGE_3 has a maximum voltage of 4.0V in order to allow DAC to be enabled.

If USB_CHARGE_TX_RANGE_2 or USB_CHARGE_TX_RANGE_3 was valid, it is expected that the battery will charge up to 4.0V. Once 4.0V is reached, the DAC is to be disabled and battery will be allowed to discharge to 3.7V. At 3.7V, DAC will again be enabled to 450mA and DAC will be cycled within USB_CHARGE_TX_RANGE_3 continuously as is done today.

It is possible that battery will not be charged in TX and instead the radio will power off if the radio load exceeds the charge current. As battery is discharged in this scenario, there will 75mV of hysteresis in the downward direction within the ranges after 4.0V has initially been reached. For example, if DAC was disabled at 4.0V and battery voltage decreased to 3.7V, DAC would be set to 450mA to charge the battery. If the battery voltage dropped to less than 3.7V, then no change would occur until the battery voltage continued to drop to 3.625V (3.625V=3.7V – 75mV). At 3.625V then next lower range would be entered which would force DAC to be set to 350mA. If Battery voltage rises and exceeds 3.7V, then the next range will immediately be entered and current will be set to 450mA.
4.5.3. Midrate Charging
4.5.3.1. Midrate Charging in RX
Charging algorithm in RX will be the same for a Midrate Charger and a Fullrate Charger. The same CHARGE_RX_RANGE values will be used to determine current in constant current mode.
4.5.3.2. Midrate Charging in TX
When Charging in TX with a Midrate a variant of existing Midrate Current Share mode will be used. The exception is that MID_RATE_CTRL will be driven high instead of existing MIDRATE_1 and MIDRATE_2 lines, and the DAC will be set to 750mA instead of 500mA. As is done today, it must be verified that the Midrate Charger supply has collapsed by measuring voltage drop across charger path.
4.5.4. Fullrate Charging
4.5.4.1. Fullrate Charging in RX
Charging in RX will be the same for a Midrate Charger and a Fullrate Charger. The same CHARGE_RX_RANGE values will be used to determine current in constant current mode.
4.5.4.2. Fullrate Charging in TX
Charging in TX with a Fullrate charger will be the same as is done today. The battery will not be charged and instead the charger will supply the radio current through the standard discharge path. Upon identification of a fullrate charger, MID_RATE_CTRL must be driven low which will enable the external discharge path.
4.5.5. Battery Metering
Discharge and Charge Metering will be implemented the same as is done on Triplets.
4.5.6. Charging Flowcharts

Figure 4‑4: Radio Off, No Battery or Vbus device, Attach Vbus device


Figure 4‑5: Radio Off, Battery Present, Attach Vbus Device


































Figure 4‑6: Charge_USB_RX











Figure 4‑7: Charge_All_RX















Figure 4‑8: Charge_Fast_TX

Figure 4‑9: Charge_Mid_TX




Figure 4‑10: Charging USB TX
4.6. Smart Device Support
This section details smart device operation. Smart device operation is currently not fully defined within the CEA-936 specification
4.6.1. Smart Device Identification
Smart device identification is covered in this section. It is assumed that rtime has already identified the device as a smart device. Refer to section 4.3.2 for device class identification. Figure 4‑10 diagrams the flow of smart device identification within the device layer.


Figure 4‑11: Smart Device Identification

4.6.2. Audio/UART Mode Switching

Figure 4‑12: Phone Initiated Audio to UART Mode Switch Ladder

Figure 4‑13: Accessory Initiated Audio to UART Mode Switch Ladder
5. Factory Interface
This section covers the factory test requirements/sequencing and SW requirements for new test commands.
5.1. Test Command Requirements
Currently there is only one new test command required for EMU bus coverage in the factory. The majority of the testing can be completed using GPIO test commands to set and read the various GPIOs.
5.1.1. EMU_AUDIO (Official Name TBD) Test Command
It is required to test the audio paths through the EMU bus connector. This will be accomplished through the use of a new test command which will operate as follows:

The test station shall send the EMU_AUDIO test command
The radio will ACK the test command, then wait for 3ms (wait is negotiable)
After the 3ms wait the radio will switch to audio mode with the EMU mic path looped back to the EMU mono speaker path.
During audio loopback the radio shall monitor the state of the PPD_INT_B and SNP_INT_B signals. When the PPD_INT_B is asserted the radio will disable loop back.
If the SNP_INT_B signal is not asserted at this point the radio will switch into EMU stereo mode and generate tomes on the SPKR_L and SPKR_R lines (For factory test purposes only SPKR_R need be verified since SPKR_L was verified during loopback). During this time the radio will continue to monitor the state of the SNP_INT_B signal.
When the SNP_INT_B signal is asserted the radio will power down.

The flowchart below shows the sequence described above.


Figure 5‑1: EMU_AUDIO Test Command Flowchart
5.1.2. SET_CHARGER Test Command
In order to support testing of charging during software regression a test command must be added to set the charger type. Upon receiving this test command SBCM should be notified of the presence of the charger type indicated in the test command data. The charger type supported shall be:

CHARGER_TYPE_NONE
CHARGER_TYPE_USB_CHARGER
CHARGER_TYPE_MID_RATE
CHARGER_TYPE_FAST
5.2. Test Coverage
5.2.1. Test Bay Requirements
In order to effectively test EMU bus functionality the test bay must be capable of:
Controlling the D+ and D- connections to the PC.
Shorting D+ and D- together.
Selectively biasing the ID pin with 4V or any resistor value from Table 4‑4
Providing an audio signal input on the D+ line (when D+ is disconnected from the PC) and monitoring the audio signal present on D- when in audio loop-back mode
Controlling the voltage present at the USB_PWR pin.
5.2.2. Testing Details
5.2.2.1. Radio Turn On
The following sequence will be used to turn the radio on:

Figure 5‑2: Factory Sequence for Radio Turn-on
This sequence must be completed within 500ms and tests the following sub-circuits; D+/D- short detector, ID 4V detector, hardware path enable to B+, external power connectivity to the radio.
5.2.2.2. ID Line Test Coverage
Once the radio has enumerated the ID line must be tested for A/D values, PPD_INT_B and SNP_INT_B detection, and SNP_INT_B generation (via SNP_INT_CTL).
The A/D values may be verified by either connecting the various pull-down values or by applying the corresponding voltage to the ID line and reading AD6 through the a/D test command. Using the various pull-down values will most likely be the more generic testing method as the actual voltage on the ID line for a given pull-down could vary from product to product.
PPD_INT_B can be tested by checking for a high on PA12 through the GPIO test command, then applying a 102k pull-down to the ID line and checking for a low on PA12.
SNP_INT_B and SNP_INT_CTRL can be tested at the same time. First SNP_INT_B should be verified as high by reading PE3. Next SNP_INT_CTL should be asserted by driving PE1 high. SNP_INT_B should be read again and should be low.


Figure 5‑3: ID Line Testing Flowchart

6. Philips ISP1109 Addendum
This section covers the use of the Philips ISP1109 Addendum. Every effort has been made to map the signals defined in the discrete solution to the functional equivalents in the IC.
6.1. Hardware Signals
The hardware interface to the ISP1109 consists of various GPIOs and the base-band SPI interface.


Signal Connection Description
BB_SPI_CLK Neptune à ISP1109, ATI, PCAP2, FL Base-band SPI clock
BB_MOSI Neptune à ISP1109, ATI, PCAP2, FL Base-band Master Out Slave In
BB_MISO ISP1109, ATI, PCAP2 à Neptune Base-band Master in Slave Out
ISP1109_CS (USB_EN) Neptune à ISP1109 ISP1109 SPI chip select. Active High
EMU_INT_B (PPD_INT_B) ISP1109 à Neptune This signal replaces the individual hardware interrupts of the discrete solution. Some PCAP functionality has also been transferred to this interrupt. The actual interrupt source must be determined by reading the status register.
ISET_SENSE
(FACT_DET) ISP1109 à Neptune This signal is used in conjunction with the SE1 SPI bit to detect Factory Mode
VBUS Mini USBßàISP1109, PCAP2 Supplies power to the radio from SPD’s. Acts as SW_B+ for PPD’s. Used in SPD detection
D+ Mini USBßàISP1109 Used for device identification. Acts as D+ for USB mode, UART RXD in UART mode
MIC_IN in audio mode
SPKR_R in stereo mode
D- Mini USBßà ISP1109 Used for device identification. Acts as D- for USB mode, UART TXD in UART mode
SPKR_OUT in audio mode
SPKR_L in stereo mode
ID Mini USB ßà ISP1109 Used for PPD detection,
Device identification.
Acts as MUTE to SIHF (controlled by SNP_INT_CTL)
Acts as SEND/END for headset
MID_RATE_CTRL Neptune à EMU charging control logic Controls the external power supply path
SW_BP_EN******* Neptune à EMU Power control Switched B+ enable
SPKR_R PCAPà ISP1109 Speaker right input to audio/data mux
SPKR_L PCAPà ISP1109 Speaker left input to audio/data mux. Also used for SPKR_OUT for headset/car kit
MIC_IN ISP1109 à PCAP MIC input to PCAP from audio/data selection mux
AD6 IDà PCAP Used to sense the voltage on the ID line
USB_TXENB Neptune à ISP1109 Used in USB mode to enable USB TX. Controlled from USB module
USB_VPIN ISP1109 à Neptune Used for VPIN in USB mode. Used to sense the D+ state for PPD identification.
USB_XRXD ISP1109 à Neptune USB receive data for USB mode
USB_SE0 Neptune à ISP1109 Single ended 0 generation in USB mode
USB_VMIN ISP1109 à Neptune VMIN during USB mode. Used to sense the D- state during device identification. Used as UART RXD in UARTmode
USB_VPOUT Neptune à ISP1109 USB TX data in USB mode. UART TXD in UART mode
Table 6‑1: ISP1109 Based EMU Signals
6.2. ISP1109 SPI Interface Specification
6.2.1. ISP1109 SPI Transfer Settings and Data Format
Data is transferred to the ISP1109 in 32 bit words, MSB first. The format of the data is shown in figure





Figure 6‑1: SPI Transfer Format

The chip select for the ISP1109 SPI should be configured in the following manner:
Chip Select Settings (CS2, CSCFG2A & B)
o CLKDIV = 0 (13MHz SPI Clock)
o M_L_SEL = 0 (MSB First)
o CSPL = 0 (CS polarity High)
o DOPH = 0 (Clock out on falling edge, device clocks in on rising)
o DIPH =0 (Device clocks out on falling edge, SPI clocks in on rising)
o DAT_CNT = 1 (1 clock delay between transfers)
o DBC_CNT = 0 (No delay before 1st transfer)
Queue configuration (which queue used is left to the discretion of the programmer)
o QBRST: Left to the programmer
o QRC: Left to the programmer (QBRST has impact on this)
o QBL = 4 (32 bit message)
6.2.2. ISP1109 SPI Register Map
The following table provides the register map of the ISP1109. Read/Write registers (RW) have separate addresses for setting and clearing bits and can be read from either of these addresses. For RW registers the Address column contains the set address. Read only (RO) registers have only one address.



Register Type Address Clear Address Description
Vendor ID Low RO 0x00 N/A Low byte of Philips Vendor ID
Vendor ID High RO 0x01 N/A High byte of Philips Vendor ID
Product ID Low RO 0x02 N/A Low byte of ISP1109 Product ID
Product ID High RO 0x03 N/A High byte of ISP1109 Product ID
Version ID Low RO 0x14 N/A Low byte of ISP1109 IC Version ID
Version ID High RO 0x15 N/A High byte of ISP1109 IC Version ID
MCR1 RW 0x04 0x05 Mode Control Register 1
MCR2 RW 0x12 0x13 Mode Control Register 2
ACR RW 0x16 0x17 Audio Control Register
TCR RW 0x18 0x19 Timer Control Register
RCR RW 0x06 0x07 Resistor Control Register
ISR RO 0x08 N/A Interrupt Source Register
ILR RW 0x0A 0c0B Interrupt Latch Register
IEN_LOW RW 0x0C 0x0D Interrupt Enable Low Transition (Falling edge)
IEN_HIGH RW 0x0E 0x0F Interrupt Enable High Transition (Rising Edge)
Table 6‑2: ISP1109 Register Map

6.2.3. ISP1109 Register Definitions
This section details the various bits/bit fields within each of the registers and their default states. HAPI signals are given for those bits that have equivalents.


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0 SPEED_REG 01 1 0=Low Speed, 1= High speed. TDB (may not be needed since this is not going to be a dynamic setting)
1 SUSPEND_REG 01 0 0 = Active Mode, 1 = Suspend Mode PCAP_HAPI_USB_SUSPEND_MODE
2 DAT_SE0 1 1 0 = VP/VM mode, 1 = DAT-SE0 mode TDB (may not be needed since this is not going to be a dynamic setting)
3-5 RESERVED 0 Reserved NA
6 UART_EN 0 0 Enables the UART !PCAP1_HAPI_RS232_TRANSCEIVER_EN
7 UART_PIN_SEL 0 0 Determines the connection of URXD and UTXD to D+ and D- !HAPI_RS_232_DIR
1. These bits are don’t care at power up as they are overridden by the states of the hardware pins because SPD_SUSP_CTRL is 0 by default.
Table 6‑3: MCR1 Bit Definitions


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0 PWR_DN 0 0 Set to power down the IC. IC will wake up on SPI and interrupt activity NA
1 SPD_SPSD_CTRL 0 1 Selects hardware or software control over suspends and speed TDB (may not be needed since this is not going to be a dynamic setting)
2 BI_DI 0 0 Selects Bi-directional or uni-directional transceiver interface TDB (may not be needed since this is not going to be a dynamic setting)
3-4 RESERVED 0 Reserved NA
5 AUDIO_EN 0 0 Enables the audio muxes and disables the USB transceiver when high. TBD (MUX1 and MUX2 were formerly used for the Audio Mode Selection)
6-7 RESERVED 0 0 Reserved NA
Table 6‑4: MCR2 Bit Definitions


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0 AUDIO_MONO 0 1 0 = Stereo Mode, 1 = Mono Audio TBD (MUX1 and MUX2 were formerly used for the Audio Mode Selection)
1 SW_MIC_SPKR_L 0 0 Audio Loop-back test: 0 = SPKR_L not looped back to MIC, 1 = loop-back enabled TDB (may not be needed since this is not going to be a dynamic setting)
2 SW_MIC_SPKR_R 0 0 Audio Loop-back test: 0 = SPKR_R not looped back to MIC, 1 = loop-back enabled TDB (may not be needed since this is not going to be a dynamic setting)
3 ISET_DRV_EN 0 0 0 = ISET controlled by hardware, 1 = ISET controlled by ISET_STATE TBD (could share whatever FACT_DET signal is called as an output)
4 ISET_STATE 0 1 Used for SW control over ISET TBD (mat not be needed, could just be set and use ISET_DRV_EN to control the ISET line)
5 DP_SRP_EN 0 0 Enables the D+ pullup resistor regardless of VBUS state. TBD (HAPI_DP_SRP_EN)
6 PH_ID_INT 0 0 Generates a low on ID interrupt for a time Tph_id_wt (covered in the CEA-936 specification). Auto clears TBD
7 PH_ID_ACK 0 0 Generates a low on ID interrupt for a time Tph_id_wt (covered in the CEA-936 specification). Auto clears TBD
Table 6‑5: ACR Bit Definitions


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0-3 TMR_DP_INT 0000b 0000b Used to set the time for the DP interrupt for 4 wire CEA-936. Motorola has chosen to use 5 wire so this bit will not be used. NA
4-8 TMR_SE1 0001b 0001b Sets the SE1 detection time in 1ms increments. TDB (may not be needed since this is not going to be a dynamic setting)
Table 6‑6: TCR Bit Definitions


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0 DP_PULLUP 1 0 Enables the 1.5 D+ pull up resistor if VBUS is present PCAP1_HAPI_USB_VCCRENB
1 DP_WKPU_EN 01 1 Enables the charger detection pull up !HAPI_CHRG_DET_PU_B
2 DP_PULLDOWN 0 0 Enables the D+ pull down NA
3 DM_PULLDOWN 1 0 Enables the D- pull down NA
4 ID_PULLDOWN 0 0 Enables the ID pull down HAPI_SNP_INT_CTL
5 RESERVED 0 0 Reserved NA
6 VBUS_DISCHRG 0 0 Discharges VBUS through a pull down NA
7 VBUS_CHRG 0 0 Charge VBUS through a pull up NA
1. This is the default state of the initial parts. Production parts will default to 1.
Table 6‑7: RCR Bit Definitions


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0 VBUS_DET NA NA Indicates VBUS > 3.6V TBD
1 SESS_VLD NA NA Indicates VBUS > 2.0V TBD
2 DP_HI NA NA Indicates D+ is high TBD
3 ID_GND NA NA Indicates the ID line is grounded (SNP_INT) (HAPI_SNP_INT_B)
4 SE1 NA NA Indicates a single ended 1 is detected TBD
5 ID_FLOAT NA NA Indicates ID pin is floating (HAPI_PPD_INT_B)
6 RESERVED NA NA Reserved NA
7 DP_INT NA NA Only used in 4 wire implementations NA
Table 6‑8: ISR Bit Definitions


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0 VBUS_DET_INT NA NA TBD
1 SESS_VLD_INT NA NA TBD
2 DP_HI_INT NA NA TBD
3 ID_GND_INT NA NA TBD
4 SE1_INT NA NA TBD
5 ID_FLOAT_INT NA NA TBD
6 RESERVED NA NA TBD
7 DP_INT_INT NA NA TBD
Table 6‑9: ILR Bit Definitions


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0 VBUS_DET_IEL 0 0 TBD
1 SESS_VLD_IEL 0 0 TBD
2 DP_HI_IEL 0 0 TBD
3 ID_GND_IEL 0 1 TBD
4 SE1_IEL 0 0 TBD
5 ID_FLOAT_IEL 0 1 TBD
6 RESERVED 0 0 TBD
7 DP_INT_IEL 0 0 TBD
Table 6‑10: IEN_LOW Bit Definitions


Bit(s) Name Reset Value SW Default Value Description HAPI Signal
0 VBUS_DET_IEH 0 0 TBD
1 SESS_VLD_IEH 0 0 TBD
2 DP_HI_IEH 0 0 TBD
3 ID_GND_IEH 0 1 TBD
4 SE1_IEH 0 0 TBD
5 ID_FLOAT_IEH 0 1 TBD
6 RESERVED 0 0 TBD
7 DP_INT_IEH 0 0 TBD
Table 6‑11: IEN_HIGH Bit Definitions
6.3. Statically Configured GPIO
These signals retain the same GPIO configuration regardless of the operating mode of the bus. This section serves as a quick reference for the GPIO connectivity; signal definitions and usage are covered in other areas of this specification. Signals that have the same functionality as Razor are not covered in the ISP1109 addendum section of this ICD.



GPIO Pin Signal(s) Neptune Module Reuse From Razor
PA6 SW_BP_EN MCU GPIO Y
PA12 EMU_INT_B EXT INT 3 N
PA13 MID_RATE_CTRL MCU GPIO Y
PD8 ISP1109_CS MQSPI (CS2) N
PD10 USB_TXENB USB Y
PD11 USB_VPIN USB Y
PD13 USB_XRXD USB Y
PD15 USB_SE0 USB Y
PE12 ISET_SENSE MCU GPIO (Y)
Table 6‑12: Statically Configured GPIO
6.4. Dynamically Configured GPIO
The dynamically configured IOs are identical to Razor.

6.5. Interrupt Handling
Interrupt handling differs slightly from the discrete solution when using the ISP1109. PCAP2 will still be used for the MOBPORTB interrupt (SPD detection) while the PPD_INT_B and SNP_INT_B signals will be replaced by one interrupt, EMU_INT_B, generated by the ISP1109. When this interrupt is detected software must poll the ILR for the active source and then use the ISR for any subsequent debouncing. The interrupt handler for the ISP1109 should be architecturally very similar to the PCAP interrupt handler.
6.6. Bus Configuration
All bus configuration (Audio, USB, RS-232) is implemented through the ISP1109 SPI bits UART_EN, AUDIO_EN, and AUDIO_MONO. The table below details the settings for the various bus modes.


Mode UART_EN AUDIO_EN AUDIO_MONO
USB mode 0 0 X
UART mode 1 0 X
Mono headset / carkit 0 1 1
Stereo mode 0 1 0
Table 6‑13: Bus Configuration Settings
6.7. Factory Mode Detection and Factory Mode
Factory mode detection differs from the discrete implementation slightly. With the ISP1109 solution the ISET_SENSE (formerly FACT_DET) line must be read. If a high is detected then the SE1 bit of the ISR must be checked. If low then the radio should enter factory mode. Logically:

Factory mode = (ISET_SENSE && !SE1)

Once factory mode has been detected the DP_SRP_EN bit should be set to ensure USB communication remains uninterrupted.
6.8. External Power Path Control
The eternal power path is controlled by software through the use of the ISET_DRV_EN and ISET_STATE bits of the ACR register. In order to reduce the number of writes required to the ISP1109 it is suggested the ISET_STATE bit be initialized high and the ISET_DRV_EN be used to control the state of the pin.
6.9. Factory Considerations
6.9.1. Test Command Requirements
Though there are no hard requirements for new test commands with the ISP1109, new test commands could be spec’ed to ease factory implementation. All verification can be completed using the SPI read and write commands. Potential test command additions would be those that abstract the SPI reads/writes to the individual bits of the ISP1109
6.9.2. Turn On
The radio turn-on sequence should match that of Razor.
6.9.3. EMU_AUDIO Test Command Changes
Due to the nature of integrating functionality the specifics of this test command will change when using the ISP1109. These changes should be abstracted in HAPI (MUX lines changing to the audio control lines within the ISP1109). The modified sequence for the EMU_AUDIO test command is shown below.

Figure 6‑2: EMU_AUDIO Test Command (Radio Perspective)
The ISP1109 also includes the ability to loop-back audio internal to the radio which allows testing of the audio connectivity with no external support required. This is the preferred method for testing audio connectivity going forward; however this method will require a design spanning both the DSP and MCU domains. Due to the extensive design required for this method it will most likely not be ready during the life of the ISP1109.
6.9.4. ID Line Test coverage
Since the interrupt generation and control of the ID line is integrated into the ISP1109 the factory testing of the ID line can be reduced to ensuring in spec A/D’s and connectivity to the ISP1109. This test reduction is based on the assumption the IC is a known good part.


Figure 6‑3: ID Line Test Coverage for ISP1109 Based Systems