Version: **

Note:
For spec numbers 001-00001 to 001-99999, the KBA number is five digits; for spec numbers 002-xxxxx, add '2' to make it a 6-digit number. For example, for spec 002-12345, the KBA number is 002-212345 to distinguish it from KBA12345 for spec 001-12345.

Question:
How to terminate the unused power pins for CY27410 or CY27430 ?

Answer:
We will use the pin out for CY27410 to understand better.

Power supply pins like VDDIO-D2 or VDDIO-S2 can be left open/floating, if they are unused in the application.

Version: **

Question: Where can I find the RF regulatory certification-related details for CYBLE-343072-02, CYBLE-333073-02, CYBLE-333074-02, CYBLE-343176-02 AIROC™ Bluetooth® LE modules?

Answer: CYBLE-343072-02, CYBLE-333073-02, CYBLE-333074-02, CYBLE-343176-02 AIROC™ Bluetooth® LE modules are fully certified for FCC, ISED, CE, UKCA and MIC/TELEC. The certificates and test reports are attached with this article. The following table lists the compliance of the module to regulations across various regions.

The following table lists the certification IDs of different regulations

* CYBLE-343072-02, CYBLE-333073-02, CYBLE-333074-02, CYBLE-343176-02 have the same Certification ID

Attachments:

• CYBLE-343072-02, CYBLE-333073-02, CYBLE-333074-02, CYBLE-343176-02 Certificates – Contains FCC, ISED, MIC certificates
• CYBLE-343072-02, CYBLE-333073-02, CYBLE-333074-02, CYBLE-343176-02 Test Reports– Contains the test reports for FCC, ISED¹, MIC, CE² and UKCA².

1 The test reports of FCC and ISED are the same.
2 The test reports of CE include AS standards. The test reports of CE and UKCA are the same 

Version: **

In the code, you can read the major version, minor version, patch number, and build number of the Bluetooth^® LE stack library by using the API as follows:

For PSoC™ 4 CY8C4x47xx-BLxxxx MCU with AIROC™ Bluetooth® LE:

The CyBle_GetStackLibraryVersion()API function is used for reading the major version, minor version, patch number, and build number of the Bluetooth® LE stack library. See the following sample code segment:

CYBLE_STACK_LIB_VERSION_T stackVersion;
CYBLE_API_RESULT_T apiResult;

apiResult = CyBle_GetStackLibraryVersion(&stackVersion);
  
printf("BLE Stack Version: %d.%d.%d.%d\r\n", stackVersion.majorVersion, 
                                              stackVersion.minorVersion,
                                              stackVersion.patch,
                                              stackVersion.buildNumber);

For PSoC™ 6 CY8C63x7 MCU with AIROC™ Bluetooth® LE:

The Cy_BLE_GetStackLibraryVersion()API function is used for reading the major version, minor version, patch number, and build number of the Bluetooth® LE stack library. See the following sample code segment:

cy_stc_ble_stack_lib_version_t stackVersion;
cy_en_ble_api_result_t apiResult;

apiResult = Cy_BLE_GetStackLibraryVersion(&stackVersion);

printf("BLE Stack Version: %d.%d.%d.%d\r\n", stackVersion.majorVersion, 
                                             stackVersion.minorVersion,
                                             stackVersion.patch,
                                             stackVersion.buildNumber);

Version: **

Question: Is it possible to stream video from two image sensors using one EZ-USB™ FX3?

Answer:

Yes. You can use a FX3+FPGA solution. A slave FIFO interface can be used to communicate with the FPGA
(refer to AN65974 - Designing with the EZ-USB FX3 Slave FIFO Interface for more details on slave FIFO interface). Streaming from two image sensors using one FX3 can be done by creating two DMA channels.

For example, if two DMA channels created are as follows:

DMA channel - 1 with Producer sockets as CY_U3P_PIB_SOCKET_0, CY_U3P_PIB_SOCKET_1 and Consumer socket as CY_U3P_UIB_SOCKET_CONS_1

DMA channel - 2 with Producer sockets as CY_U3P_PIB_SOCKET_2, CY_U3P_PIB_SOCKET_3 and Consumer socket as CY_U3P_UIB_SOCKET_CONS_2

The FPGA can maintain two FIFOs to store data from the two image sensors. The FPGA code should change the address lines (A0 & A1) depending upon the FIFO from which it fetches the data from and send to FX3.
The sensor1 data should be stored in FIFO 1 of the FPGA and sensor2 data should be stored in FIFO 2 of the FPGA.

During the blanking period, FPGA can switch the FIFO and change the address lines to select the appropriate DMA channel of FX3 for streaming the data; that is, if the data is coming from FIFO 1, the 2-bit address line A0:A1 should be driven with 00 or 01 alternatively i.e. in ping-pong manner to select CY_U3P_PIB_SOCKET_0 or CY_U3P_PIB_SOCKET_1 of DMA channel 1.

Similarly, if the data is coming from FIFO 2, then the FPGA should drive the 2-bit address lines A0:A1 as 10 or 11 alternatively to select CY_U3P_PIB_SOCKET_2 or CY_U3P_PIB_SOCKET_3 of DMA channel 2.

Note: Refer to sections 3 and 4 of the AN75779 - How to implement an image sensor interface using EZ-USB FX3 in a USB video class (UVC) framework to understand ping-pong DMA buffer.

The video data received by the PIB sockets corresponding to the DMA channel as mentioned in the above example, will be transferred to USB block through DMA channel. As two video streams from two sensors will be streamed using two DMA channels, the device should enumerate as a composite device with two UVC interfaces i.e. FX3-UVC-1 and FX3-UVC-2. In the host application like AmCap, VLC media player, user will get option to choose a UVC interface to start streaming video. If streaming from both the sensors is to be started simultaneously, two instances of host application should be opened and appropriate UVC interface should be selected.

Figure 1. Composite device with two UVC interface

For the device to enumerate with two UVC interfaces, the USB descriptors should be modified to support two sets of UVC descriptors. In addition to this, the firmware should also handle UVC specific requests for both the interfaces.

A template firmware with two UVC interfaces and UVC specific request handling is attached with this KBA. The header file for GPIF state machine (cyfxgpif2config.h) used with the firmware is a dummy state machine. The user is expected to use a custom GPIF state machine header file based on the application. Two CY_U3P_DMA_TYPE_MANUAL_MANY_TO_ONE DMA channels are used in the firmware to stream two 640* 480 (VGA) YUY2 at 30 FPS video streams. As per the default AN75779 UVC firmware, the UVC header is added in the firmware. The cyu3imagesensor.c and cyu3imgagesensor.h are also created and saved in this project. The cyu3imagesensor.c file is used to configure and control the image sensor and FPGA. In this file, some structures are defined without a valid value. You need to replace these values with actual settings. Generally, used APIs such as CyFx3_ImageSensor_Sleep, CyFx3_ImageSensor_Wakeup, and CyFx3_ImageSensor_Trigger_Autofocus are also available the cyu3imagesensor.c and cyu3imagesensor.h files. Add the corresponding codes into these definitions.

Note: The firmware attached with the KBA is a template project and should be modified according to user application.

Version: **

Question: Why do keyboard commands not work in modus-shell?

Answer: The modus-shell tool included with ModusToolbox™ software is based on the latest version Cygwin. The latest version of Cygwin does not support some keyboard shortcuts, such as Ctrl + V (paste) and Ctrl + F (find).

Workaround: Use the context menu from the Title bar and select various commands shown under Edit.

Version: *A

A reference design kit based on Infineon’s EZ-USB™ CX3 USB 3.0 camera controller and EN801/EN805 image signal processor (ISP) from the Eyenix website. This camera kit uses an IMX307 image sensor from Sony with a manual focus lens.

  Figure 1. Kit block diagram

Eyenix ISP has a 4-lane MIPI-CSI2 RX interface for connecting image sensors and a 4-lane MIPI CSI-2 TX interface for connecting to EZ-USB™ CX3.

Infineon EZ-USB™ CX3 enables USB 3.0 connectivity to EN801/EN805 using a MIPI-CSI2 interface with data speed up to 1 Gbps per lane.

 Figure 2. Kit photo

Key features of the kit:

• Bandwidth: 4x CSI-2 lanes, 1 Gbps per lane
• Color formats supported: YUV422 8-bit
• USB camera protocol: UVC
• Supported resolutions:
  
  • 720p @30/50fps
  • 1080p @25/30fps
  • 1080p @50/60fps
  • 1440p @25/30fps (supported by EN805 + IMX335)

Eyenix EN801/EN805 ISP has the following features:

• RGB interpolation
• WDR
• Digital noise reduction
• Adaptive contrast enhance (ACE)
• Histogram equalizer for defog
• Lens shading compensation
• Down and up scaler
• Defect pixel correction
• Hue controller
• High light masking
• Auto exposure, Auto white balance, Auto focus
• Edge enhancement
• Gamma correction
• On-screen display (OSD)
• Adaptive lighting control

The kit also supports control through an on-screen display (OSD) menu. This menu can be navigated using the Python-based camera control tool as shown in Figure 3. The tool controls the ISP menu via USB CDC class through a PC.

  Figure 3. Menu control tool

Figure 4. On-screen display (OSD) menu

See the Eyenix website for more information on this camera control software and applications including surveillance cameras, webcams, document scanners, and machine vision systems.

Version: **

Question:
Why does my legacy BTSDK project (version 2.7.1 or older) fail to build in ModusToolbox™ 2.4?

Answer:
There have been changes with the build system in more recent versions of the software that affect older projects. You may see errors like the following:

COMPONENT_fw_upgrade_lib/ota_fw_upgrade_common.c: In function 'wiced_ota_fw_upgrade_init':
<command-line>: error: 'DLConfigSSLocation' undeclared (first use in this function)
COMPONENT_fw_upgrade_lib/ota_fw_upgrade_common.c:204:26: note: in expansion of macro 'SS_LOCATION'
  204 |     nv_loc_len.ss_loc  = SS_LOCATION;
      |                          ^~~~~~~~~~~
<command-line>: note: each undeclared identifier is reported only once for each function it appears in

Workaround:

1. Identify the location of the current BSP:
   
   1. Open the modus-shell terminal and navigate to the application folder.
   2. Run the following:
      make get_app_info | grep 'SHAREDLIBS='
   3. Look for the following output with the path relative to the application folder. For example:
      

      ./../../../wiced_btsdk/dev-kit/bsp/TARGET_<bsp_name>
      That is the location of the active BSP.

2. Navigate to the folder discovered in step 1c.
   
   
3. Edit the BSP Makefile. This file is located in the BSP folder and named after the BSP name. For example:  <bsp_name>.mk
   
   
4. Search in the file for the comment line:
   

   # split up btp file into "x=y" text

5. Place the following lines immediately above that comment line:
   

   CY_EMPTY=
   CY_SPACE=$(CY_EMPTY) $(CY_EMPTY)

6. Save the file and retry to build the project.

The legacy project should build successfully in the ModusToolbox™ 2.4 environment.

Version: **

1. Is the XENSIV^TM PAS CO2 sensor affected by acoustic and vibration noise?
   XENSIV^TM PAS CO₂ sensor has a robust packaging, and is acoustically isolated from the surrounding noise. The sensor has been designed in such a way that only CO₂ molecules can diffuse within the measurement chamber, while significantly attenuating the surrounding noise. As shown in Figure 1, the sensor performance remains within the specifications up to 101 dB SPL for pink noise, which is one of the most common signals in biological systems and is widely present in modern-day music.
   Figure 1. Acoustic robustness of XENSIV^TM PAS CO₂
   
   

   Infineon recommends that you isolate the sensor from vibration sources. The operating frequency of the sensor is 40 Hz. If vibration is expected at exactly 40 Hz with very high acceleration (≤ 0.3 g), you should do the following to minimize the vibration impact:

   • Mount the sensor in the X-direction of vibration.
   • Enable the denoiser filter.
   • Operate the sensor in continuous mode.

However, for a typical application, the impact of vibration is minimal. As shown in Figure 2, for a test setup with three sensors mounted on a commercially available air purifier, the test result shows that with the denoiser filter enabled, the sensor is robust against the vibration generated by a different fan of the air purifier.

 Figure 2. Vibration robustness of XENSIV^TM PAS CO₂

For more details, visit the CO₂ sensor website and see the application note, General design in guidelines for XENSIV™ PAS CO2 sensor.

2. How much indoor area can be covered by one sensor for a typical application?
   Even though CO₂ is generated locally, after a certain period, the CO₂ concentration is distributed throughout the room. Therefore, irrespective of the room size and number of people, the sensor is capable of accurately estimating the indoor CO₂ concentration within an indoor environment. For more details, see the application note, General design in guidelines for XENSIV™ PAS CO2 sensor.
   
   
3. Are scientific literature available indicating the harmful effects of CO₂ for human body?
   Several studies have been done on the effect of CO₂ on the human body at various concentration levels. The summary is provided in the chart. See Source [1] for the details of the study.
   
   

   Figure 3. Impact of CO₂ on the human body at various concentration levels

   Source
   

   1. https://www.sciencedirect.com/science/article/pii/S0160412018312807
   2. https://books.google.de/books?hl=en&lr=&id=TEnO6lILSj4C&oi=fnd&pg=PR8&dq=Co2+sensors+and+health&ots=Xy1umDNsmq&sig=ZjljEpPMeRBse75NgUiwbh01KuM&redir_esc=y#v=onepage&q=Co2%20sensors%20and%20health&f=false
   3. https://ieeexplore.ieee.org/abstract/document/8767280

4. Is it possible to obtain MEMS separately from the module along with the compensation software to integrate them into a custom DSP solution?
   No, currently it is not possible to purchase MEMS separately.
   
   
5. How is the sensor calibrated? Does it need recalibration after delivery?
   Each sensor is calibrated in the factory when it is shipped from Infineon. For the final product, you  will not have to perform calibration. However, you should use the automatic baseline offset correction (ABOC) feature during operation to minimize errors due to aging. See the application note, FCS_ABOC_XENSIV™ PASCO2.
   
   
6. How can I generate a known level of CO₂ in ppm?
   CO₂ sources are numerous such as bike tire CO₂ inflators, soda water, and human breath. To arrive at a known level, capture the CO₂ gas in a Tedlar bag and pump it into a gas chamber using a 6-V diaphragm pump. CO₂ concentration can easily reach more than 10000 ppm in such a setup. A reference CO₂ sensor can be used to measure the known level. See the application note, Recommended performance evaluation methodology for XENSIV™ PAS CO2 sensor.
   
   

   One such setup is as follows:
   

7. Can the XENSIV^TM PAS CO₂ sensors be battery-powered?
   XENSIV^TM PAS CO₂ can be used for battery-powered applications. Infineon has a reference design which can help operate the sensor at 3.3 V (a low-cost boost converter circuitry along with the sensor). For details, see the application note,

   XENSIV™ PAS CO2 for low-power application.

8. When is the CO₂ sensor available? Where can I get eval kits?
   

    

   Evaluation kits are already available with major distributors.

9. What are the power requirements of the XENSIV^TM PAS CO₂ sensor?
   The average power consumption to power up the sensor is 29.7 mW. During the measurement phase, the power consumption is 26.4 mW. Infineon provides a power calculator based on Microsoft Excel that helps in determining the average power consumption based on the end application.
   

   Figure 4. Average power consumption

   For more information, see Section 3 of the application note, XENSIV™ PAS CO2 for low-power applications.

10. What is the long-term stability of these sensors?
    

     With the automatic baseline offset correction (ABOC) feature enabled, the sensor accuracy drifts by 1% every year.

    

    Figure 5. Values of pressure and acoustic stability

    See Section 4.1.5 - Transfer function table in the datasheet.

11. How can I reduce a high CO₂ level?
    According to ASHRAE, an ideal living room should not have more than 1100 ppm of CO₂. Therefore, as soon as the CO₂ level increases beyond 1100 ppm, you should ventilate the room.
    
    
12. How is the sensor calibration done?
    
    • Does the sensor calibrate single gas or more gases?
    • How long does the calibration process take?
    • What is the required equipment?
    • How often calibration must be done?
    • Can the calibration be done anywhere or only in the laboratory?
    • Does the sensor have automatic calibration or auto leveling?

Each sensor is calibrated during our production for the complete operating range. Production calibration is done with highly accurate CO₂ gas bottle and verified with an ideal reference sensor.

The sensor might show small amount of offset after assembly due to stress generated from the assembly process on the light source. Therefore, to get the best performance, this offset should be corrected using either FCS or ABOC.

For the FCS calibration, you need to have a reference sensor. In the ABOC mechanism, the device keeps track of the minimum value recorded over a week. The offset to the reference baseline is computed and used to calculate the correction factor to be applied for the week after.

Figure 6. Operation of the ABOC feature

See the application note, After-assembly calibration scheme for XENSIV™ PAS CO2 for more details.

13. Can this device be installed on a microcontroller/system-on-chip such as Arduino/Raspberry Pi?
    Yes. Infineon provides C/C++ libraries for interfacing the sensor.
    See the following GitHub repos:
    
    • For devices compatible with Arduino.
    • For PSoC™ 6 MCU library.

14. Does the response time (T63 = 75s) meet the certification requirements and accuracy for medical applications?
    The sensor is not specifically designed to cover medical applications. However, the response time is defined based on the diffusion process.
15. What are the design rules for integrating the CO₂ sensor into a package for airflow speed and direction?The device must be positioned in such a way that the diffusion of CO₂ molecules can happen easily, with a large enough opening. The recommended opening is at least 14 mm x 14 mm.
    

     

    Figure 7. Airflow direction

 See the application note, General design in guidelines for XENSIV™ PAS CO2 sensor for details.

16. What is the time constant (CO₂) of the sensor?
    Time constant/response time of the sensor is the time it takes to measure the CO₂ concentration. This is due to the diffusion time of CO₂ molecules.
    For VDD3.3 = 3.3 V, VDD12 = 12 V, Tamb = 25°C, % RH = 30 %, p = 1013 hPa, the response time, T63 = 75 seconds.
    See Section 4.1.5 of the datasheet for more information.
    
    
17. What are the response times in different airflows?
    The response time is independent of the airflow. You should not place the sensor directly within the airflow. For more details, see the application note, General design in guidelines for XENSIV™ PAS CO2 sensor.
    
    
18. How do I waterproof the sensor board for wet environments?
    The sensor is not designed for applications where it must be waterproofed. The sensor may be damaged if submerged in water.
    
    
19. Is the CO₂ sensor tested in an environmental chamber?
    A test chamber is used, which  ensures that there is no leakage, and it can maintain laminar flow while exposing the sensor to the target gas concentration. Inside the test chamber, you should accommodate a reference CO2 sensor. Additionally, to get an overview of the complete test conditions, the pressure sensor, humidity sensor, and temperature sensor should also be considered.
    For more information, see the application note, Recommended performance evaluation methodology for XENSIV™ PAS CO2 sensor.
    
    
20. Can the sensor be used within battery-driven consumer goods, with a supply voltage lower than 12V, such as 3.3 V?
    Infineon has addressed the requirement; a reference design is available to ease the design process. You can use this design to realize 12V with relatively low effort. For more information, see the application note, Reference design Sensor2Go kit, and the detailed knowledge base article (KBA).
    
    
21. What are the major technologies used in the sensor?
    The sensor uses a microphone, emitter (MEMS + filter), and the embedded software that implements the sensing algorithm

Note: For more information, see the Community webpage for CO2 sensor where you can find answers to your questions and ask your own.

Version: **

V_LKO is the lock-out voltage of the core power supply (V_CC). The intention of V_LKO is to make sure that device is on expected V_CC level before program/erase to avoid unintentional program/erase operation during V_CC power-up and down transitions. When V_CC is below V_LKO, the entire flash memory array is protected against a program or erase operation. This ensures that no spurious alteration of the memory content can occur during power transition.
V_LKO is a single-value threshold parameter; every device has a different V_LKO. Min/Max is an estimated range of V_LKO. All the devices have V_LKO within this range.

During power-down or when V_CC drops below V_LKO, the V_CC and V_IO voltages must drop below the V_CC Reset (V_RST) minimum for a period of t_PD for the part to initialize correctly when V_CC and V_IO again rise to their operating ranges. See Figure 1.
In system implementation, you should use the maximum value for V_LKO in all devices. For example, monitor V_CC; if it drops below V_LKO(max), make sure that V_CC and V_IO voltages drop below the V_CC Reset (V_RST) minimum for a period of t_PD so that the device is correctly initialized.

Figure 1 Power down and voltage drop

Figure 1 shows the power down and voltage drop diagram and VLKO. See Figure 10 in S29GL01G/512T datasheet Rev.L.
This diagram applies to all Infineon GL series Parallel NOR flash families.

Version: **

Wait states and dummy cycles are the same. Read latency is superset of wait states (or dummy cycles). Read latency equals the sum of clocks for mode bits and wait states. 

To understand the concepts, here are the definitions from JESD216 standard:

• Mode bits: Optional control bits that follow the address bits and are driven by the controller if they are specified.
• Wait states: Required clock cycles between the address bits or optional mode bits and the start of data when reading from the flash device. Some device data sheets describe these as dummy cycles because no information is transferred between the controller and memory during these cycles. Neither controller nor memory are required to drive the data lines during these cycles.
• Read latency: On flash read instructions, the total number of clocks between the end of address and the start of data. The sum of clocks for mode bits and clocks for wait states equals the read latency.
  Read latency equals dummy cycles (wait states) when mode bits are not specified by controller; see Figure 1. Read latency equals the sum of clocks for mode bits and dummy cycles (wait states) when mode bits are specified by controller; see Figure 2.

Figure 1 Read latency without mode bits

Figure 2 Read latency with mode bits