Version: **

Question: How do I add user code in the PSoC Creator™ USB component in PSoC^® 3, PSoC 4200-L, and PSoC 5LP?

Answer: The PSoC Creator USB component has interrupts associated with each of the Endpoints, SOF, Bus Reset, Arbiter, and Link Power Management. A user may need to add custom code or perform a task when these interrupts are triggered. This can be done using the following two methods:

1. Using the space to add custom code

In this method, you can directly add the custom code in the respective Interrupt handlers between the space provided as shown in Figure 1.

Figure 1: Space to Enter the Custom Code in the Interrupt Handler

The USBFS_episr.c file contains Interrupt handlers for all the interrupts supported by the USBFS component. Figure 1 shows the interrupt handler for Endpoint 1. Regenerating the code does not remove code inserted between the /* `#START EP1_USER_CODE` Place your code here */ and /* `#END` */.

2. Using interrupt callback function

In this method, use the Entry and Exit callback functions present at the beginning and end of each Interrupt handler.

• Define a macro to signal the presence of a callback (in cyapicallbacks.h). This will “uncomment” the function call from the component’s source code.
• Write the function declaration (in cyapicallbacks.h). This will make this function visible to all the project files.

• Write the function implementation in any user file.

The following examples show how to use the entry callback function in case of an SOF Interrupt.

• Define macro USBFS_SOF_ISR_ENTRY_CALLBACK in cyapicallbacks.h. Make sure that the cyapicallback.h is included in the USBFS_episr.c. This will enable the USBFS_SOF_ISR_EntryCallback().

Figure 2: Macro to Uncomment the Callback Function

• Declare the function USBFS_SOF_ISR_EntryCallback() in the cyapicallback.h file

Figure 3: Define the Macro and Function in cyapicallback.h

• Define the USBFS_SOF_ISR_EntryCallback() in any user file (main.c in this case). Refer to the PSoC Creator User Guide and USBFS component datasheet for details on the callback functions associated with the USBFS component.

Figure 4: Define the Function

Version: **

The firmware attached with AN75779 supports streaming the video data over a UVC class interface to the USB host. You can use the modified AN75779 firmware attached with this article to stream video data over a vendor class interface by using the cyusb3 driver instead of the UVC class interface.

In the FX3 firmware, enable the #define CY_DRIVER macro in uvc.h to toggle between UVC and non-UVC (Vendor Class) application.

The main differences between the default AN75779 UVC firmware and the firmware (with the CY_DRIVER macro enabled) attached with this KBA are as follows:

1. The device will enumerate as a USB vendor-class device, i.e., the USB descriptors report to the USB host that the device is a vendor-class device. This enables the device to bind to the  cyusb3.sys driver unlike the default UVC firmware that has USB Video class descriptors and bind to the UVC driver.
2. Vendor commands are used to start and stop streaming rather than UVC Class-specific control /streaming requests. The vendor command 0x99 starts the streaming, while 0x88 stops it in the firmware.
3. The data streaming with the attached firmware can be tested using the streamer application and USB Control Center application from the FX3 SDK.

NOTES:

1. Use the Control Center application for starting and stopping the video stream using vendor commands mentioned in point 2. Streamer application is used to receive the video data. Start the streaming with this application by pressing the “Start” button before passing the vendor command 0x99 (to start the video stream) to the device from the USB Control Center application.
2. Configure the “Packets per Xfer”, “Xfer per Queue”, and “Timeout per Xfer” fields of the streamer application to achieve the required transfer rate.
3. You need to develop a custom host application to view the video.

Figure 1. Streaming 1280 x 720 video image data using USB Control Center and
 C++ streamer application of FX3 SDK

4. No memory is allocated for UVC headers or footers during DMA channel creation and no UVC headers are added to the image data. So, 16 KB of video image data is transferred to the USB host unlike 16 KB minus the 16 bytes for UVC headers in the video image data sent in the firmware attached with AN75779.

Version: **

Question: What needs to be checked if JTAG debugger is not connected?

Answer: If the signal quality of the hardware is not good, do the following:

• Make sure that the JTAG signal wiring on the PCB meets the requirements.
• Check if the JTAG termination circuit is appropriate.

For more information, see the documentation as follows.
AN220270 Hardware Design Guide for the TRAVEO II Family
AN220118 Getting Started with TRAVEO II Family MCUs

Note: This KBA applies to the following series of TRAVEO^™ II MCUs:

• CYT2 Series
• CYT3 Series
• CYT4 Series

Version: **

This article is for CMSIS5. For information about a previous CMSIS version, see KBA90457.

Do the following to include the CMSIS5 Library in a PSoC® Creator™ project:

1. Download the latest Arm® CMSIS pack from here - ARM.CMSIS.5.7.0.pack.
2. Change the extension of the downloaded file from .pack to .zip.
3. Extract the archive file.
4. Copy the Core and DSP folders in the extracted CMSIS folder and place them in your PSoC Creator project directory.
5. Right-click on the project in PSoC Creator Workspace Explorer and open Build Settings.
6. Add .\Core\Include and .\DSP\Include to Additional Include Directories under ARM GCC <version> > Compiler > General as shown.
   

    

    Note: For PSoC 6 MCU devices, Additional Include Directories will be under <ARM_CPU> ARM GCC <version> > Compiler > General, where <ARM_CPU> represents the Arm CPU that you want to use. It can be CM0+ or CM4. Add the configurations only to the CPU that needs to run the CMSIS-DSP code.
7. Add the ARM_MATH_XX preprocessor definition where ‘XX’ stands for the corresponding Arm CPU of the device. Some of the preprocessor definitions for Arm CPUS are – ARM_MATH_CM0, ARM_MATH_CM0PLUS, ARM_MATH_CM3, ARM_MATH_CM4.
8. Add m (math library) under Linker > General > Additional Libraries as follows:
   

    

9. Add the link file in the DSP\Lib\GCC\ directory corresponding to the Arm CPU for the target device in the Additional Link Files field. For example, for an Arm Core M3 device, select DSP\Lib\GCC\libarm_cortexM3l_math.a.
   
   

   Note: For the CM4 CPU in PSoC 6 MCU devices, libarm_cortexM4lf_math.a cannot be used directly because it uses hardfp which cannot be enabled directly using PSoC Creator. See KBA222890 to learn how to enable hardfp for PSoC 6 MCU devices in PSoC Creator.

10. Click Apply and then click OK.
11. Right-click on Source Files in Workspace Explorer, select Add > Existing Item, and add all the necessary source files that you are using. You can also add folders to organize the files.
12. Build the project.

Version: **

Q1) What is Driver Signing?

Windows device installation uses digital signatures to verify the integrity of driver packages and to verify the identity of the vendor (software publisher) who provides the driver packages. In addition, the kernel-mode code signing policy for 64-bit versions of Windows Vista and later versions of Windows specifies that the kernel-mode driver must be signed for the driver to load.

All drivers for Windows 10 (starting with version 1507, Threshold 1) signed by the Hardware Dev Center are SHA2 signed. For details specific to operating system versions, see Signing requirements by version.

Q2) What is Driver resell or sharing a driver with Partner?

Driver resell is a process through which non-Microsoft organizations shares their Microsoft logo certified driver product with their customers and Partners. This process aids the partners to modify the driver package and get Microsoft Certification quickly without running certification test. This driver resell process follows Microsoft Driver Update Acceptable (DUA) process. So, driver package modification has few restrictions that are set by Microsoft DUA process.

Through this process, Cypress shares the Microsoft driver logo certification to the customer through the Windows Hardware Dashboard. By opting for driver resell, there is no need to run HLK compliance test for simple INF changes.

Q3) Why is Driver resell required?

Cypress provides device drivers for use with its USB devices and Bridge controllers ICs. These drivers are available for a number of Operating systems. However, many customers are interested in changing these drivers to reflect their corporate identity through custom USB VID, PID, product names, company names etc. This can be done by editing the driver INF files. However, the original driver logo certification gets cancelled due to the INF file changes.

This is when the customers can opt for Driver resell. The customers can obtain Microsoft certification for their device drivers.

Q4) What are the pre-requisites when opting for Driver resell?

Please refer to the following weblinks from Microsoft to understand about registering in the Windows Hardware Dashboard and obtaining an EV certificate:

>> https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/register-for-the-hardware-program

>> https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate

After creating an account in the Windows Hardware Dashboard, kindly reach out to Technical Support and provide the following details:

• The modified INF file with custom VID/PID for verification.
• The publisher display name.
• The OS for which they want the driver resell? Also mention whether it is needed for x64 OS architecture or x86 OS architecture or both?
• The driver version they want us to resell.
• The silicon chip they are using- FX3 or FX2LP or USB-Serial.

Q5) What are a few points to ensure while submitting the modified driver package?

• The modified INF file shared by the customer should not contain any IFX VID/PID (only valid for FX3/FX2 chips). FX2 and FX3 kits are used just for development purposes and not as end-products. Therefore, legally VID/PID of these kits should not be used by customers in their driver packages.
• The driver file names (inf/sys) should not be changed by the customer. Driver updates are carried out through a process termed DUA (Driver Update Acceptable Process). Driver resell process follows the same process as DUA. The restrictions on changes allowed in the driver package are not imposed by Cypress rather fall under the guidelines of the DUA process. Please refer to Section 2.2 Reselling (Redistributing) Drivers and the Driver Update Acceptable Process in Driver publishing workflow for Windows 10 by Microsoft - https://download.microsoft.com/download/B/A/8/BA89DCE0-DB25-4425-9EFF-1037E0BA06F9/windows10_driver_publishing_workflow.docx
• The INF files for different OS versions are different. To elaborate, the INF files for Windows XP and vista are the same. Similarly, the INF files for Windows 7-8.1 are the same but different from xp inf. The INF for Windows 10 is different from XP & Windows 7-8.1 INFs. Thus, the customers should submit different INF files corresponding to the OS versions for which they want us to do driver resell. For instance, if they want driver resell for all the OS versions, they need to submit 3 different INFs-
  •   for XP and Vista
  •   for Windows 7-8.1
  •   for Windows 10

Kindly check the Drivers folder in the FX3 SDK: https://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit

Q6) Does Cypress performs driver resell for both the Cypress CDC (Virtual COM port) driver and cyusb3 driver?

Yes, we do driver resell (Redistribution) for both CDC (Virtual COM port) driver and cyusb3 driver. The driver resell process is the same for both drivers.

Q7) Does Cypress sign the driver files and create a new CAT file?

No, we do not sign the CAT file. Cypress is not allowed to sign driver package containing non-Cypress VID and PID due to legal constraints. We can help to sign drivers which contain only Cypress VID.

Q8) What should be done after receiving the driver package from Cypress?

Please refer to Section 3. Driver Resell in CyUSB.pdf (<Installation path>\EZ-USB FX3 SDK\1.3\doc\SuiteUSB\CyUSB.pdf) document present in EZ-USB FX3 SDK (https://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit

For details please refer to CyUSB.pdf in the EZ-USB FX3 SDK: https://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit

Windows Hardware Center Dashboard: https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/?redirectedfrom=MSDN

Version: **

The EZ-USB™ SX3 HDMI 4K Capture Card is a USB Video Class (UVC), USB Audio Class (UAC) compliant capture card which is ideally suited for capturing video and audio from any HDMI source and supports up to 4K, 30fps/ 1080p, 60fps in YUV format video. It is based on Infineon^® EZ-USB™ SX3, a USB3.1 peripheral controller, Lattice ECP5 FPGA and HDMI receiver IC.

Figure 1. SX3 HDMI RX 4K capture card block diagram

Any HDMI source such as Laptop, Raspberry Pi, Gaming consoles, Android TV set-top box, media streaming devices like Amazon fire TV, Apple TV, and so on can be used with this kit. The “Microsoft Camera” application, e-CAMView, MPC-HC player or any UVC player application can be used to view this video on a USB Host. This is a form factor kit of size 26-mm × 75-mm.

The kit schematic, BOM, and board files are attached with this document. You can build customized board using these files.

The kit firmware configuration file includes the SX3 configuration and FPGA bit file which are attached with this document.

Figure 2. EZ-USB™ SX3 HDMI 4K capture card - Rev 01

Figure 3. Type-C and HDMI receptacles of EZ-USB™ SX3 HDMI 4K capture card – Rev 01

Follow the below steps to capture the 4K video from HDMI source using EZ-USB™ SX3 HDMI 4K Capture Card:

1. Download and install EZ-USB SX3 Configuration Utility.
2. Connect the EZ-USB™ SX3 HDMI 4K Capture Card Solution Demo Kit to USB 3 port of PC using a USB-C-to-A cable or a USB-C-to-C cable.
3. Download the SX3 Configuration file (sx3_hdmi_4K_capture_card.zip) for EZ-USB™ SX3 HDMI 4K Capture Card from the attachment.
4. Import the sx3_hdmi_4K_capture_card.zip file into SX3 Configuration Utility using the Import Configuration option.

   Figure 4. Import configuration option in SX3 configuration utility

   
5. Select USB boot mode using the boot mode selection switch (available on Rev 02 board).
6. Program the configuration to the connected kit.

   Figure 5. Program configuration option in SX3 configuration utility

   
7. Once the firmware and configuration files are loaded, select SPI boot mode using the boot mode selection switch (implemented on Rev 02 board).
8. Disconnect and re-connect the USB cable.
9. In Windows Device Manager, the kit will be visible as SX3 in the Cameras and Audio Inputs and Outputs section.

   Figure 6. SX3 devices in Device Manager after Enumeration

   
10. Connect any HDMI source to the HDMI port of the kit using the supplied HDMI cable. The HDMI source will stream video and audio. The kit will capture the same and send it over the USB port to PC.
11. To view the video from HDMI source, run the Windows Camera application and choose SX3 in the Devices option. The video from the HDMI kit will be captured on PC screen.

    Figure 7. Video played on HDMI source viewed in Windows camera application

    
12. To listen the audio from HDMI source, perform these steps:
    1. Open the Windows Control Panel.
    2. Click the Hardware and Sound icon.
    3. Click the Sound icon.
    4. Click the Recording tab.
    5. Double click on Digital Audio Interface- SX3.
    6. Click the Listen tab in the Digital Audio Interface Properties dialog box.
    7. Select the Listen to this device checkbox and click the Apply button. You should hear the audio from HDMI in Laptop speakers.
    8. Adjust your speaker volume.

Figure 8. Testing the audio from HDMI source

Figure 9. Enable “Listen to this device” option to route audio from HDMI source to the speaker

Steps to re-program the EZ-USB™ SX3 HDMI 4K Capture Card

In EZ-USB™ SX3 HDMI 4K Capture Card Revision 01, there is no provision available to change the boot option using PMODE pins. To re-program the board, the device will need to boot as USB Bootloader Device.

To erase the on-board firmware and to get back the device to bootloader mode, open the command prompt in the folder where HID_Sample_App.exe is located and enter the reset command as shown below:

HID_Sample_App.exe -vid 0x04b4 -pid 0x00c2 -reset

Replace the vid and pid values with corresponding vendor ID and product ID of the connected device. Once it is successful, the “Erase and Fallback to Bootloader is successful” message is displayed as shown in the below screenshot.

Figure 10: Reset the existing firmware using HID_Sample_App.exe

Download the HID_Sample_App.exe file from the attachments. Once the board falls back to bootloader mode, follow the procedure from step 2 to program the device.

Additional learning resources:

Visit www.cypress.com/sx3 for additional resources like datasheet, and application note, configuration utility user guide.

Attachments with EZ-USB™ SX3 HDMI 4K Capture Card Solution Demo Kit:

1. Schematic: SX3 HDMI 4K CAPTURE CARD Schematic.pdf
2. BOM: SX3 HDMI 4K CAPTURE CARD _BOM.xls
3. Board File: SX3 HDMI 4K CAPTURE CARD _layout.pdf
4. EZ-USB SX3 Configuration File: sx3_hdmi_4K_capture_card.zip
5. HID_Sample_App executable file: HID_Sample_App.zip

Version: **

The Write Enable (WREN 06h) command must be written prior to any command that modifies nonvolatile data. The WREN (06h) command sets the Write Enable Latch (WEL) bit of the Status Register 1 (SR1V[1]) to a “1”. The Write Enable Latch (WEL) bit must be set to a “1” by issuing the WREN (06h) command to enable write, program, and erase commands. CS# must be driven into the logic HIGH state after the eighth bit of the instruction byte has been latched. Without CS# being driven to the logic HIGH state after the eighth bit of the instruction byte has been latched, the write enable operation will not be executed. Write Register (WRR) command following WREN (06h) command modifies non-volatile Status Register and Configuration Registers. The volatile Status Register and Configuration Registers are also automatically updated to the same. The WREN (06h) is supported in all Infineon QSPI Flash families.

The Write Enable Volatile (WRENV 50h) command is written prior to Write Register (WRR) command in the case that only modifies volatile Status Register and Configuration Registers. Non-volatile Status Register and Configuration Registers remain unchanged. This gives more flexibility to change the system configuration and memory protection schemes quickly without waiting for the typical nonvolatile bit write cycles or affecting the endurance of the status or configuration nonvolatile register bits. However, after this operation, the values in volatile and non-volatile Status Register and Configuration Registers may not be the same. Volatile register values decide the flash device behaviors. After power cycle or reset, the volatile registers will be automatically loaded with the values from non-volatile registers.

The WRENV (50h) command will not set the Write Enable Latch (WEL) bit, it is used only to direct the following WRR command to change the volatile status and configuration register bit values. CS# must be driven into the logic HIGH state after the eighth bit of the instruction byte has been latched in on SI/IO0. Without CS# being driven to the logic HIGH state after the eighth bit of the instruction byte has been latched, the write enable operation will not be executed. WRENV (50h) command is only supported in S25FL-L and SEMPER™ Flash with QSPI Interface devices.

Version: **

Question: How can I specify an alternate tools version for my ModusToolbox application?

Answer: You can install multiple ModusToolbox software versions simultaneously on a system. By default, ModusToolbox software uses the most current version of the "tools" directory installed. In some cases, you might want to use a specific older version of the ModusToolbox tools for certain projects.

The ModusToolbox User Guide documents several methods on how to do this, but there is another method that uses the modus-shell (bash) command-line interface, and this article focuses on that method.

The modus-shell is basically a bash terminal that uses Cygwin under the hood. It is used to emulate a UNIX-compatible environment on Windows. For macOS and Linux users, any appropriate bash terminal will do.

Why use modus-shell?

Here are some of the reasons why you would want to use the modus-shell method:

• Specifying the tools version affects only the current session of running modus-shell.
• It is not a global setting like System Variables, so it will not affect other projects.
• It helps the Eclipse IDE to load the correct tools and configurators during startup.

How to use modus-shell

Here are the steps to use the modus-shell command line interface:

1. Navigate to the ModusToolbox installation directory, go to tools_2.x\modus-shell, and run Cygwin.bat.
   Here x is any minor version that is installed.

2. Run the export command to specify the correct tools path.
   For example, if you need to use 2.2 version of the tools, run the following command:

>> export CY_TOOLS_PATHS=C:/Users/<Username>/ModusToolbox/tools_2.2Note: The path separators must be forward slash. On macOS and Linux, use the appropriate path to the tools directory.

3. Navigate to your project directory and run various make commands as needed. For example:
   >> cd ../MyApplication
   >> make build

4. If you want to use the 2.2 version of the Eclipse IDE, run the command to launch it. For example:
   >> cd C:/Users/<Username>/ModusToolbox/ide_2.2/eclipse/
   >> ./ModusToolbox.exe

Note: The path separators must be forward slash. On macOS and Linux, use the appropriate path to the eclipse directory.

You should now see the ModusToolbox application opening with the correct version of the Eclipse IDE and specific tools version needed for your project. Since these settings affect only this particular session of modus-shell, you need to run the export command again the next time you want to use the project.

Version: **

The CCGx Power SDK 3.5 example firmware provides two ways:

1. Change the Retry count from 2 (default value) to 255 by using the EZ-PD™ configuration utility, and then save the configuration into firmware .hex/.cyacd file directly. You can also replace the config.c file in the firmware project and rebuild it.

2. Change the config.h file in firmware project directly without configuration table changes on Over Current Protection and rebuild the firmware project.

1. Locate the config.h file (under the solution folder of Header Files group):
2. Enable delayed infinite fault recovery.
   

    

Version: **

Question:
The ToString operation with the CyUSBStorDevice class of the C# library (CYUSB.NET) returns wrong manufacturer and product string. How can we fix it?

Answer:
The support for the mass storage class has been removed from the C# library (CYUSB.NET). The details are still maintained in the documentation for the existing customers. It is not recommended to use this class in new designs.