USER MANUAL
FUSB15200 Dual Port USB
Type-C/PD Controller
Software Programming
Guide UM70103/D

Introduction

The FUSB15200 firmware codebase is a highly optimized dual−port Type−C/PD controller driver that supports the integrated Arm Cortex ® −M0+ processor. Together with the FUSB15200DV EVB, this driver provides customers with a complete platform for evaluating a Type−C/PD solution.
The firmware provides the flexibility of supporting new power delivery (PD) messages as well as any additional Type−C state flows.
The firmware also allows easy modification of the hardware−specific characteristics because of its Type−C/PD platform−agnostic architecture. When supplied with a desired configuration, the codebase can be used to quickly configure the device.
The code organization offers modularity, as it separates source code for application, hardware abstraction layer, platform dependent code, and the USB Type−C/PD core. Default configurations supported by the FUSB15200 Type−C/PD are listed in Table 2. FUSB15200
Supported Configuration in Port.
The PD core features are configurable using project build options or by modifying the vendor info file. The codebase includes a sample Eclipse project that can be compiled using the Eclipse based onsemi IDE, thus allowing a faster bring−up to evaluate the Type−C/PD standalone controller.
Supported Power Delivery
Table 1 FUSB15200 Supported Device Characteristics (60 W PDP) summarizes the PD options available on the FUSB15200DV.
Table 1. FUSB15200DV SUPPORTED DEVICE CHARACTERISTICS (60 W PDP)

NOTE: The PDOs supported are power supply dependent.

Port Configuration

UM70103/D
Firmware Build Options
The reference firmware and its default configuration support the FUSB15200 EVB platform for a complete evaluation of the Type−C/PD solution. By following the instructions in section Firmware Build Instructions, a firmware binary can be built and loaded into the EVB. The FUSB15200 default supported values are listed in Table 3 Supported Build Configurations.
Table 3. SUPPORTED BUILD CONFIGURATIONS

UM70103/D
Firmware Build Instructions
Build the firmware by performing the following steps:

• Download and install the onsemi IDE:
  ♦ Click on this link: onsemi IDE.
  ♦ Click Design Tools.
  ♦ Click onsemi IDE installer and download it to a location in your system.
  ♦ Follow the prompts to install the onsemi IDE.
• Download the 15200 firmware code release:
  ♦ Click on this link.
  ♦ Click FUSB15200 Reference Code and download the zip file.
  ♦ Unzip the contents into a directory of your choice.
  NOTE: Make sure that the codebase has the directory structure as shown in section Code Organization.
• Open the onsemi IDE and load the project:
  ♦ From the top menu, choose File.
  ♦ Choose Open Projects from File System….♦ From Import Source, click on Directory… .
  ♦ From the firmware source directory, choose Go to fw_fusbdev → IDE → FUSB15200 → usbpd then select ON_IDE
• Build the FUSB15200DV firmware:
  ♦ From the Project Explorer tab, right click on FUSB15200 USBPD (in ON_IDE), and select Build Project.♦ Upon a successful build, the binary FUSB15200 USBPD.bin is copied under IDE\FUSB15200\usbpd\ON_IDE\Debug\.
  ♦ Refer to the document FUSB15200 Dual Port USB TYPE−C/PD Controller Flash Programming Guide for the steps to program the FUSB15200DV.
• Optional: Changing build configuration:
  We recommend that you keep the default build configuration to test the EVB.
  Advanced users, can follow the steps below to change the config parameters listed on Table 3. Supported Build Configuration.
  ♦ Press Alt−Enter to display the Properties for FUSB15200 USBPD.
  ♦ Go to C/C++ General > Paths and Symbols > Symbols > GNU C.

Firmware Architecture
This section outlines the firmware architecture of the FUSB15200. Initially it covers in paragraphs Code Organization and Port Configuration a high−level overview of the code. Gradually, it tries to give a more in−depth description in subsequent paragraphs.
Code Organization
Table 4. FUSB15200 Project Subdirectory Descriptions outlines the directory structure and describes the content of each subdirectory.
Table 4. FUSB15200 PROJECT SUBDIRECTORY DESCRIPTIONS

Firmware Composition
The FUSB15200 platform integrates an Arm Cortex−M0+ processor with a nested vector interrupt controller, a wakeup interrupt controller, and a debug access port. The codebase includes peripheral drivers and support for multiple external source interrupts for peripheral devices.

• PD Device Policy Manager
  The firmware codebase provides reference code for the device policy manager (DPM). The sample DPM can manage platform−specific PD message requests and responses using event subscriptions and notification callbacks. It uses a hardware abstraction layer (HAL) to prevent policy engine or Type−C state machine direct access to hardware registers.
  The DPM manages a private structure that encapsulates TCPD (Type−C/PD) driver and port structure.
• PD Policy Engine Core
  The PD policy engine (PE) state machine is platform−agnostic. Most PE functions are statically defined and are only accessible through the TCPD driver, except for PE state machine core functions, PE state machine enable/disable
  functions, and a PE hard reset message interrupt handler. The Type−C/PD core in this codebase can support characteristics other than the ones listed in Table 1. FUSB15200 Supported Device Characteristics. These options are configurable, as described earlier in this document.
  Policy engine functions: void policy_pd_enable(struct port *port, bool source)
  This function enables the PE state machine, used on startup. It can be used in certain contexts with policy_pd_disable() when your device cannot offer power delivery. void policy_pd_disable(struct port *port)
  This function disables the PE state machine. This function is primarily used when the device cannot supply USB Type−C power delivery. void policy_receive_hardreset(struct port*port)
  This function processes a hard reset when a PD message is received through the PD controller interrupt bit.
  Void policy_engine(struct port *port)
  This is the main function for the PE core state machine.
  In the most recent code bases this function changed. In order to save space and avoid an excess of if, else if we switched to a function pointer approach. Since a state is a numeric enumerated data that is created at build time by CREATE_XXX_POLICY_STATES() for SRC, SNK, DRP, VDM and USB4 so therefore the state is associated to a numerical index. We used that same index to build a function pointer array whose array element index matches the state enum.
  For example, the index 0 in the enum policy_state_t is PE_SRC_Startup.
  At index 0 of the array policy_state_run[] we placed the function pointer to service that state; which is in this case; policy_state_source_startup().
  IMPORTANT: The lineup of the states and the servicing functions have to match and ought to be aligned.
  The index alignment must be validated if any new additional state is added.
• PD PE Message Handling
  A few PE message handling function examples are listed below. A full list of PD message handlers can be found in policy.c. These functions are only accessible from the policy engine. static void policy_state_source_get_sink_cap(struct port *port)
  This function is called when a PD provider sends a request for sink capability. static void policy_state_source_give_sink_cap(struct port *port)
  This function is called when a PD provider responds to a request for sink capability. static void policy_state_source_send_drswap(struct port *port)
  This function is used for a PD provider to request drswap. static void policy_state_source_evaluate_drswap(struct port *port) This function is used for a PD provider to evaluate a received drswap request.
• PD PE Message Queuing
  New to the PE this release is the abstraction of message requests in a 32 bit message queue of bitmasks. By modifying port→msgtx variable you can easily queue supported messages on the FUSB15200. A list of compliance tested messages that are enabled by default on Source and Sink can be found in: policy_reset_message_queue(struct port * port)
  This function is used to reset the message queue when messages need to be requeued into the message queue. This is called by default on attach and on Hard Reset.
  When setting the msgtx bit for a message, you must also ensure that the bit is cleared. For the default set of enabled messages and some additional tested messages, this bit is cleared upon successful receipt of the message, but other messages must have bit clear behavior defined.
• PD PE VIF Message Queuing
  VIF Messages are now handled through the same Message Queuing structure, and has been abstracted into two functions: source_vif_message_requests(struct port * port)
  This function is used to queue up source vif messages when the vif would demand a message be sent to the port partner. sink_vif_message_requests(struct port * port)
  This function is used to queue up sink vif messages when the vif would demand a message be sent to the port partner.
• Type−C State Machine
  Port detection on attach/detach of a Type−C device is handled inside the USB TypeC state machine function, typec_sm(). As with PD, this is also platform−agnostic, and all access to the hardware is controlled by the TCPD driver.
• Observer Files
  These files are shared between the device policy manager and the policy engine. observer.c contains the function definitions of event_subscribe, event_unsubscribe, and event_notify. observer.h has all the declarations of all the event ID and structure definitions necessary for events. Event Handling The PD event messaging between DPM and PE is handled with no assumption that DPM subscribes to every notification. This provides flexibility for the DPM to only subscribe to events that are needed for the intended application. It also allows reduction of the binary size.
• Adding New Events
  While the events that are already defined might be adequate in the supported platform, if an application requires more event subscriptions/notifications between the policy engine and the device policy manager, additional events can be
  added as needed. To add a new event, add a definition to the enum type event_t in observer.h.
  • Registering Event Handlers
  Event subscription/callback notification is used by the policy engine and the device policy manager to pass on PD message requests/responses and/or platform specific behavior changes to the Type−C/PD controller.
  An event is registered using the function event_subscribe following this format:
  event_subscribe(EVENT_ID, callback_handler)
  The device policy manager subscribes to applicable events, and the policy engine uses these events to notify the DPM by using the function event_notify, following this format: event_notify(EVENT_ID, struct* tcpd_device, void *ctx) Events in Table 5. Supported Events are defined in observer.h.
  IDs are declared as an enumerated type and use the ##preprocessor to generate the EVENT with “EVENT_” prepended to each ID in Table 5.
  Example: Event ID “TC_ATTACHED” Generates an event with descriptor “EVENT_TC_ATTACHED”.

UM70103/D
Table 5. SUPPORTED EVENTS

Table 5. SUPPORTED EVENTS

Vendor Info File
Device Vendor information is in file vif.info.h. If modifications are needed, follow the steps below:
a. If the information is already available in the header file, you only need to modify the default value there.
b. If the information is not yet defined in the header file, modify the header file by adding the new information to the applicable port, and add the entry to PORT_VIF_T, which represents the newly added information in vif_info.c.
Examples:
♦ Changing max current in PDO 4 from 20V/3A to 20V/3.25A in the Port: Current PDO values:
#define PORT_A_SRC_PDO_VOLTAGE_4 400 // 20000 mV
#define PORT_A_SRC_PDO_MAX_CURRENT_4 300 // 3.00A New PDO values:
#define PORT_A_SRC_PDO_VOLTAGE_4 400 // 20000 mV
#define PORT_A_SRC_PDO_MAX_CURRENT_4 325 // 3.25A
♦ Removing support for chunked extended messages in Port: Current value:
#define PORT_A_CHUNKING_IMPLEMENTED_SOP 1 New Value:
#define PORT_A_CHUNKING_IMPLEMENTED_SOP 0
♦ Adding new entry in the vif_info.h in the Port:
a. #define PORT_A_NEW_ENTRY. 1
b. Add an entry in PORT_VIF_T in Device/FUSB15200/vif_info.c.
TCPD Driver – Changes from Previous Versions
The current firmware driver is based on a hardware abstraction layer software design. This design provides abstraction to/from PE and Type−C state machine. Neither PD nor Type−C can directly change the platform−specific behavior. The TCPD driver implements access to the port HAL and other supported peripherals. Differently from before, the code has removed pointer dereferencing to access HAL functions. Instead, driver function permissions are given to files that require it in order to function. This allowed saving a large amount of space and saving several kB of function pointer storage and pointer dereferencing. In addition, several high level interfaces built upon the high level HAL abstraction have been removed to save space.
Old flow example:
PE changes VBUS value for a contract being negotiated: the following logic path would be followed: PE → port_vbus_src() → FUSBDEV HAL with Drivers Abstracted (port→dev→driv→XXX) port→dev→driv→set_pd_source()→TCPD HAL Driver with Devices Abstracted (fusb15xxx_XXX) fusb15xxx_set_pd_source()→HAL Driver with Registers Abstracted (XXX_DRIVER) TCPORT_DRIVER.pd.Source() → Register level logic New flow example:
PE changes VBUS value for a contract being negotiated: the following logic path would be followed: PE() → port_vbus_src() → FUSBDEV HAL Abstraction with Drivers Abstracted (fusbdev_tcpd_XXX) fusbdev_tcpd_set_pd_source()→TCPD Driver with Devices Abstracted (fusb15xxx_XXX) fusb15xxx_set_pd_source()→HAL Driver with Registers Abstracted (XXX_DRIVER) TCPORT_DRIVER.pd.Source() → Register level logic
Arm and Cortex are registered trademarks of Arm Limited (or its subsidiaries) in the EU and/or elsewhere.
onsemi, , and other names, marks, and brands are registered and/or common law trademarks of Semiconductor Components Industries, LLC dba “onsemi” or its affiliates and/or subsidiaries in the United States and/or other countries. onsemi owns the rights to a number of patents, trademarks, copyrights, trade secrets, and other intellectual property. A listing of onsemi’s product/patent coverage may be accessed at www.onsemi.com/site/pdf/Patent−Marking.pdf. onsemi reserves the right to make changes at any time to any products or information herein, without notice. The information herein is provided “as−is” and onsemi makes no warranty, representation or guarantee regarding the accuracy of the information, product features, availability, functionality, or suitability of its products for any particular purpose, nor does onsemi assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation special, consequential or incidental damages. Buyer is responsible for its products and applications using onsemi products, including compliance with all laws, regulations and safety requirements or standards, regardless of any support or applications information provided by onsemi. “Typical” parameters which may be provided in onsemi data sheets and/or specifications can and do vary in different applications and actual performance may vary over time. All operating parameters, including “Typicals” must be validated for each customer application by customer’s technical experts. onsemi does not convey any license under any of its intellectual property rights nor the rights of others. onsemi products are not designed, intended, or authorized for use as a critical component in life support systems or any FDA Class 3 medical devices or medical devices with a same or similar classification in a foreign jurisdiction or any devices intended for implantation in the human body. Should Buyer purchase or use onsemi products for any such unintended or unauthorized application, Buyer shall indemnify and hold onsemi and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that onsemi was negligent regarding the design or manufacture of the part. onsemi is an Equal Opportunity/Affirmative Action Employer. This literature is subject to all applicable copyright laws and is not for resale in any manner.

ADDITIONAL INFORMATION
TECHNICAL PUBLICATIONS:
Technical Library: www.onsemi.com/design/resources/technical−documentation
onsemi Website: www.onsemi.com
ONLINE SUPPORT:
www.onsemi.com/support
For additional information, please contact your local Sales Representative at www.onsemi.com/support/sales

Documents / Resources

onsemi FUSB15200DV Dual Port USB Type-C PD Controller Software [pdf] User Guide FUSB15200DV, FUSB15200DV Dual Port USB Type-C PD Controller Software, Dual Port USB Type-C PD Controller Software, USB Type-C PD Controller Software, Type-C PD Controller Software, PD Controller Software

References

• User Manual