Version: **

Question:
What are the differences in the TCPWM block of the CY8C62x4 devices compared to other PSoC 6 MCU devices?

Answer:
Note: This article presumes the reader has an in-depth knowledge of the TCPWM block in PSoC 6 MCU devices and its various operational modes.

CY8C62x4 (PSoC 6 MCU with 256K flash) devices have a new version of the TCPWM block that is targeted mainly for motor control applications, and Field-Oriented Control (FOC) in particular.

The following is a list of major changes that support this application and their intended example usage:

1. Second Capture / Compare function
   The CY8C62x4 TCPWM block has two compare/capture registers (CC0 and CC1), while the block in other PSoC 6 MCU devices have only one. The functionalities of both CC0 and CC1 are the same. A typical application is the generation of asymmetric PWM signals with a lower CPU load (compared to generation using a single CC function). These signals are widely used in motor control applications for enabling single-shunt current measurement.

2. Immediate PWM kill
   The kill input is synchronized with a faster peripheral clock, while in other PSoC 6 MCU devices, it is a slow counter clock. This gives a better response time in emergency situations to kill the PWM signal, such as a short circuit in the motor control application.

3. Second kill input trigger
   The TCPWM block in CY8C62x4 has two kill input triggers, while the block in other PSoC 6 MCU devices have only one. A common kill input can be selected from the trigger multiplexer block, for allowing synchronous stop/kill operation of multiple PWMs. The dedicated ADC out-of-range trigger can be selected as the additional kill input for allowing real-time hardware stop of a PWM signal.

4. Independent dead times for line and complementary line output signals
   In CY8C62x4, the PWM line and complementary line output signals can be configured to have different dead times, while in other PSoC 6 MCUs, both outputs have a common dead time. Dead time is used to prevent short circuits in motor control applications. This feature gives more control over the gap between outputs.

5. Compare match events can be enabled/disabled independently while counter is up or down counting
   The CY8C62x4 TCPWM block has two compare/capture registers (CC0 and CC1) as explained previously. When the counter is configured to work in up/down mode (counts up until period and then counts back down to zero), the compare match event for CC0 and CC1 can be independently enabled or disabled for either up counting or down counting. This feature is used for asymmetric PWM signal generation.

Resources: Device Datasheets, Technical Reference Manuals

Original KBA: PSoC™ 64: Provisioning and entrance exam procedures fail when VDDIO0 is 2.5 V - KBA234967

Translated by: MaMi_1205306

バージョン: **

プロビジョニングプロセスは、キーやセキュリティポリシーなど保護された資産をPSoC™ 64デバイスに挿入します。これには、eFuseメモリのプログラミングが含まれ、VDDIO0が2.5 Vである必要があります。詳細については、「セキュアブート」SDKユーザーガイドを参照してください。

「CySecureTools」を使用する場合、VDDIO0が2.5 Vであっても、VTARGが2.5 Vでない場合、プロビジョニングと入口検査手順は次のエラーで失敗します:

ERROR: Silicon voltage is out of range. Expected voltage level is in range 2.25 V - 2.75 V. Check the log for details

これは、「CySecureTools」が内部でpyOCDを使用しているために発生し、VDDIO0ではなくVTARG電圧のみを読み取ります。

注釈：この問題は、PSoC™ 64デバイスのプロビジョニングに「CySecureTools」を使用している場合にのみ発生します。

回避策:

まず、VTARGとVDDIO0の両方を2.5 Vでデバイスをプロビジョニングし、プロビジョニングが成功することを確認します。プロビジョニングが成功した場合は、次の回避策のいずれかを使用してください:

注釈：プロビジョニングでは、VDDIO0電圧が2.5 V ± 5 ％である必要があります。 これらの回避策は両方とも、ターゲット電圧チェックを無効にします。 したがって、電圧チェックを無効にする場合は、VDDIO0電圧が範囲内にあることを確認してください。 デバイスが損傷する可能性があります。

• 「CySecureTools」ソースで入試中のターゲット電圧チェックを無効にします。
  「CySecureTools」バージョン3.1.0の場合、<CySecureTools Install Directory>\execute\entrance_exam\にあるexam_mxs40v1.pyの62行目から70行目をコメントアウトします。
  <CySecureTools Install Directory> は、「CySecureTools」のインストールディレクトリを示します。
   ModusToolbox™ 2.4の場合、C:\Users\<user>\ModusToolbox\tools_2.4\python\Lib\site-packages\cysecuretoolsです。

 図1：exam_mxs40v1.pyの62行目から70行目をコメントアウト

• 書き込み機器のVTARGピンをターゲットの2.5VまたはVDDIO0に接続します。

Community Translation: PSoC™ 64: VDDIO0が2.5Vの場合、プロビジョニングと入口検査手順が失敗する - KBA234967

Version: **

The provisioning process injects secured assets such as keys and security policies into the PSoC™ 64 device. It involves the programming the eFuse memory, which require VDDIO0 to be at 2.5 V. See “Secure Boot” SDK user guide for information.

When using “CySecureTools”, even when VDDIO0 is at 2.5 V, if VTARG is not 2.5 V, the provisioning and entrance exam procedures fail with the following error:

ERROR: Silicon voltage is out of range. Expected voltage level is in range 2.25 V - 2.75 V. Check the log for details

This occurs because "CySecureTools” internally uses pyOCD, which reads only the VTARG voltage and not VDDIO0.

Note:  You will observe this issue only when using “CySecureTools” for provisioning the PSoC™ 64 device.

Workaround:

First, try provisioning the device with both VTARG and VDDIO0 at 2.5 V and confirm that the provisioning is successful. If the provisioning succeeds, use one of the following workarounds:

Note: Provisioning requires the VDDIO0 voltage to be at 2.5 V ± 5%. Both these workarounds disable the target voltage check. So, when the voltage check is disabled, ensure that the VDDIO0 voltage is within range. Failing to do so may damage the device.

• Disable target voltage check during the entrance exam in the “CySecureTools” source.
  For “CySecureTools” version 3.1.0, comment out the lines 62 to 70 in exam_mxs40v1.py located in <CySecureTools Install Directory>\execute\entrance_exam\.
  <CySecureTools Install Directory> indicates the installation directory of “CySecureTools”.
  For ModusToolbox™ 2.4, it is C:\Users\<user>\ModusToolbox\tools_2.4\python\Lib\site-packages\cysecuretools.

 Figure 1:  Comment out lines 62 to 70 in exam_mxs40v1.py

• Connect the VTARG pin of the programmer to 2.5 V or VDDIO0 of the target.

Version:**

To fix flash overflow when the application code exceeds the CM0+ flash size range, redistribute flash in the project.
The following steps shows how to change the allocate from 0x2000 to 0x20000.

Environment:

• ModusToolbox™ version: 2.4.0
• Toolchain: GNU MCU Eclipse Arm® Embedded GCC
• TARGET=CY8CKIT-062-BLE

1. Open the CM0+ linker file, and change the flash LENGTH=0x20000.
   
   
   
   

    

   2.Compile the project after changing the CM0+ linker file. It shows the CM0+ flash image overflows with CM4.

   
   
   3.Change the CM4 linker file and confirm that the FLASH_CM0P_SIZE is the same as the CM0p flash LENGTH.
   
   

   
   
   

   4.Open system psoc6.h” and change the CM4 application start address:
   
   

   These steps change the flash memory allocation.

Version: **

• Implementation

In this project, the MUX functionality is implemented with a MUX Component in TopDesign.cysch in PSoC™ Creator while for the UART functionality, it is done without the use of the UART Component. The PDL version used is 3.1.4. The necessary source files have been included (see the following) and reused from another project that had the UART Component in TopDesign.cysch.

UART.h
UART.c
UARTSCBCLK.h
cy_scb_uart.h
cy_scb_uart.c
cy_scb_common.h
cy_scb_common.c
cyfitter.h

The program is tested on CY8CKIT-062-WiFi-BT  kit. The P5[0] and P5[1] pins that are UART Rx and Tx pins for SCB_5 respectively are assigned as MUX input and output pins. To keep the design simple, constant 1 was added to the select line to ensure that only these two pins are checked. A GPIO interrupt is used because the switching between UART and MUX functionality is done with the help of the onboard switch P0[4] (SW2) of the CY8CKIT-062-WiFi-BT kit. The implementation is shown in Figure 1.

Figure 1. Switching between UART and MUX

• Main program flow
  The switching between functionalities takes place through the high-speed input output matrix (HSIOM). With the help of the HSIOM,  Port 5 is configured for the MUX functionality and then switched to connect to the SCB block for the UART functionality. This is handled with the help of code snippets as explained below. See the attached project for details.
  
  Note: For more information on the configuration of the HSIOM for different component functionalities, see the “Multiple alternate functions” table in the device datasheet and the architecture TRM to learn about HSIOM connections through DSI. Also see the register TRM for the values of HSIOM registers.
  
  The code snippet for MUX configuration for Port 5 is –
  
  

  void reconfigure_MUX_and_DEMUX_to_Port5(){

        /* Connect MUX functionality to pins P5[0] and P5[1] through HSIOM */

        /*            .sel0Active = 0x00000318u */

        Cy_GPIO_SetHSIOM(UART_PORT, UART_RX_NUM, 24);

        Cy_GPIO_SetHSIOM(UART_PORT, UART_TX_NUM, 03);

  }
  
  

  The code for UART configuration to Port 5 is –

  void reconfigure_UART1_to_Port5(){   

        /* Connect SCB5 UART function to pins */
         Cy_GPIO_SetHSIOM(UART_PORT, UART_RX_NUM, P5_0_SCB5_UART_RX);           Cy_GPIO_SetHSIOM(UART_PORT, UART_TX_NUM, P5_1_SCB5_UART_TX);
  
        /* Configure pins for UART operation */
        Cy_GPIO_SetDrivemode(UART_PORT, UART_RX_NUM, CY_GPIO_DM_HIGHZ);
        Cy_GPIO_SetDrivemode(UART_PORT, UART_TX_NUM, CY_GPIO_DM_STRONG_IN_OFF);
  
        /* Configure clocks for UART operation */
        Cy_SysClk_PeriphAssignDivider(PCLK_SCB5_CLOCK, UART_CLK_DIV_TYPE, UART_CLK_DIV_NUMBER);
  
        /* Configure Baudrate for UART operation */
        Cy_SysClk_PeriphSetDivider   (UART_CLK_DIV_TYPE, UART_CLK_DIV_NUMBER, 35UL);
        Cy_SysClk_PeriphEnableDivider(UART_CLK_DIV_TYPE, UART_CLK_DIV_NUMBER);

  }

  The toggling of the interrupt flag inside the ISR handles the switching between UART and MUX. Initially, it is set to false, which implies that pins P5[0] and P5[1] are connected to the HSIOM for the MUX functionality. When the onboard switch (SW2) is pressed, the interrupt flag toggles and is set to true, reconfiguring the pins to be connected to the SCB5 block through the HSIOM.

  Interrupt service routine for the GPIO interrupt

  void GPIO0_4_isr_handler ()

  {
       Cy_GPIO_ClearInterrupt(Pin0_4_PORT, Pin0_4_NUM);
       NVIC_ClearPendingIRQ(GPIO0_4_isr_cfg.intrSrc);
       //Your application code
       interrupt_flag = !(interrupt_flag);
  }

   

• Testing
  

  The setup used for testing is shown in Figure 2.

  Initially, the LED is glowing on CY8CKIT-147 kit. The serial terminal is configured for the USB-UART Kitprog3 bridge with the baud rate set to 115200 bps.

  After the device is programmed, the MUX functionality is active because the interrupt flag is initialised to false. To check this, LED at P0[2] on the CY8CKIT-147 is used and is connected to P5[1] i.e., the output pin of the CY8CKIT-062-WiFi-BT kit. The P5[0] pin, being the input pin, is connected to ground. This turns OFF the LED. It clearly implies that ground is being transmitted to P5[1] with the MUX functioning. During this time, no printing takes place on serial terminal.
  
  

  Figure 2. Initial setup for testing

  When switch SW2 on the CY8CKIT-062-WiFi-BT board is pressed, “Working in UART mode” is displayed on the serial terminal as shown in Figure 3. This shows that the UART functionality is active. During this time, grounding the P5[0] pin does not stop the LED from glowing, which means that ground is not transmitted to P5[1] and that the MUX is not functional.
  
  

  Figure 3. Serial terminal output for UART functionality

  When the switch is pressed again, the printing on serial terminal stops. You can check the MUX functionality as mentioned previously to verify that the pins again behave as input and output pins for the MUX.

Version: **

Question:
How to create a basic PSoC^® Creator project implementing UART functionality, without using UART component in TopDesign.cysch?

Answer:
The Universal Asynchronous Receiver/Transmitter (UART) protocol is an asynchronous serial interface protocol. UART communication is typically point-to-point. The interface consists of two signals: transmitter output and receiver input signals. Implementing UART functionality without UART component is useful in the scenarios, when there is a requirement to share hardware resources for different functionalities.

To implement this in the PSoC^® Creator project, there is a need to add all the relevant source files for UART functioning. These files should be included in the ‘Source files’ folder of the PSoC^® 6 core, where the UART program will be executed. These files are mentioned below -

1. To begin with, cy_scb_uart.h header file provides UART API declarations of the SCB driver and cy_scb_uart.c provides UART API implementation of the SCB driver.
2. UART.c file is added to provide the source code to the APIs of the UART component and UART.h header file defines the necessary constants and parameter values for the UART component.
3. UART_SCBCLK.h file takes care of the source code to the APIs for the UART_SCBCLK component.
4. The two files cy_scb_common.h and cy_scb_common.c files are added to the common APIs of the SCB driver and also for the proper implementation of the other linked header files such as cy_scb_uart.h.

Note: The above files can be used from the “Generated files” folder of an existing project, that has a UART component in TopDesign.cysch.

A basic PSoC^® Creator project implementing the above has been explained further. It aims at printing the statement “Working in UART mode” in the serial terminal, without using the UART component in TopDesign.cysch.

1. Add the necessary source files as explained above under the CM4 (core 1) of PSoC^® 6 as shown in Error! Reference source not found..
   
   Figure 1 Source files for UART
2.  Include “UART.h” header file in the main.c to include all the API usage for UART functionality.
3. The GPIO pins are configured to function as UART pins. The HSIOM register must be configured to connect dedicated SCB UART pins to the SCB block. Also, the UART output pins must be configured in Strong Drive Input off mode and UART input pins in Digital high-Z. This is shown in the below code:
   
   

   /* Assign pins for UART on SCB5: P5[0], P5[1] */
   #define UART_PORT               P5_0_PORT
   #define UART_RX_NUM             P5_0_NUM
   #define UART_TX_NUM             P5_1_NUM
   

   /* Connect SCB5 UART function to pins */
   Cy_GPIO_SetHSIOM(UART_PORT, UART_RX_NUM, P5_0_SCB5_UART_RX);      Cy_GPIO_SetHSIOM(UART_PORT, UART_TX_NUM, P5_1_SCB5_UART_TX);   

   /* Configure pins for UART operation */      Cy_GPIO_SetDrivemode(UART_PORT, UART_RX_NUM, CY_GPIO_DM_HIGHZ);
   Cy_GPIO_SetDrivemode(UART_PORT, UART_TX_NUM, CY_GPIO_DM_STRONG_IN_OFF);

4. A clock source must be connected to the SCB block to oversample input and output signals. The system clock driver APIs are used to provide the UART clock divider type and number.
   

   /* Assign divider type and number for UART */
   #define UART_CLK_DIV_TYPE      (CY_SYSCLK_DIV_8_BIT)
   #define UART_CLK_DIV_NUMBER    (0U)

   /* Configure clocks for UART operation */
   Cy_SysClk_PeriphAssignDivider(PCLK_SCB5_CLOCK, UART_CLK_DIV_TYPE, UART_CLK_DIV_NUMBER);

5. To get the UART to operate with the desired baud rate, the clk_scb frequency and the oversample must be configured. For example, in this project the baudrate is set to 115200 bps(standard mode). The calculation is explained below:
   

   UART baud rate = (clk_scb/oversample)
   For clk_peri as 50 MHz, the divider value = 36 and get clk_scb (SCB Clock) = (50 MHz / 36) = 1,389 MHz.
   Select oversample = 12. These setting results in UART data rate = 1,389 MHz / 12 = 115750 bps.
   /* Configure Baudrate for UART operation */     
   Cy_SysClk_PeriphSetDivider   (UART_CLK_DIV_TYPE, UART_CLK_DIV_NUMBER, 35UL);
   Cy_SysClk_PeriphEnableDivider(UART_CLK_DIV_TYPE, UART_CLK_DIV_NUMBER);

6. The initialization code for the UART block uses the configuration structure as shown below:
   

   /* Initialize the UART operation */
   cy_en_scb_uart_status_t uart_status;
   uart_status = Cy_SCB_UART_Init(UART_HW, &UART_config, &UART_context);
   Cy_SCB_UART_Enable(UART_HW);

7. Perform printing of the statement inside for loop() for the output of the project as shown in Figure 2.
   

   Figure 2 Printing on the serial terminal

Version: **

PSoC™ 6 MCU with AIROC™ Bluetooth® LE connectivity supports two types of events: Bluetooth® LE stack events and service-specific events.

These events are defined in cy_ble_stack.h and cy_ble_event_handler.h files. To access these files, in PSoC™ Creator, go to Generated_Source\PSoC6\PDL\Middleware\BLE. In ModusToolbox™ software, go to libs\bless. Alternatively, you can access these files at https://github.com/Infineon/bless/.

Bluetooth® LE stack events: These events are declared in cy_ble_stack.h. Events are enumerated datatype elements declared inside the enum cy_en_ble_event_t and are classified as follows:

Generic events: 0x1000 to 0x1FFF
HCI events: 0x2000 to 0x2FFF
Vendor events: 0x3000 to 0x3FFF
GAP events: 0x4000 to 0x4FFF
GATT events: 0x5000 to 0x5FFF
L2CAP events: 0x6000 to 0x6FFF
Qualification events: 0x7000 to 0x7FFF
Future use: 0x8000 to 0xFFFE 

Service-specific events:  These events are declared in cy_ble_event_handler.h. All events are declared inside the enum cy_en_ble_evt_t which starts from 0x10000. For example, CY_BLE_EVT_BLSS_INDICATION_ENABLED is an event that is specific to the Blood Pressure service, which will be triggered when Indication is enabled for the Blood Pressure Service Characteristic.

Version: **

Related products: PSoC™ 6 MCU with AIROC™ Bluetooth® LE

You can use the Cy_BLE_GATTS_EnableAttribute() and Cy_BLE_GATTS_DisableAttribute() API functions to dynamically enable or disable a GATT service or characteristic as shown in the following:

Enabling an attribute

Use the following code snippet to enable the attribute entry for a service or characteristic logical group in the GATT database registered in the Bluetooth® LE stack:

cy_stc_ble_gatts_db_attr_enable_info_t handle;
cy_en_ble_gatt_err_code_t gattError;

handle.attrHandle = CY_BLE_BLE_THROUGHPUT_SERVICE_HANDLE;
GattErrCode = Cy_BLE_GATTS_EnableAttribute(&handle);

Disabling an attribute

Use the following code snippet to disable an attribute entry for a service or characteristic logical group in the GATT database registered in the Bluetooth® LE stack:

cy_stc_ble_gatts_db_attr_disable_info_t handle;
cy_en_ble_gatt_err_code_t gattError;   

   handle.attrHandle = CY_BLE_BLE_THROUGHPUT_SERVICE_HANDLE;
   GattErrCode = Cy_BLE_GATTS_DisableAttribute(&handle);

See this API in the BLE middleware PDL documentation. In PSoC™ Creator, right-click the BLE Component, and select Open PDL Documentation or go to C:/Program Files(x86)/Cypress/PDL/3.1.0/doc/ble_api_reference_manual/html/index.html

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: **

PSoC™ 6 MCU devices with USB support have dedicated pins for the D+ and D- USB lines (pins P14[0] and P14[1]). If the USB functionality is not required in your application, you can use these pins as regular GPIOs. When configured as GPIO, USB pins do not support drive modes other than CMOS_OUT (Strong drive) and HI_Z_ANALOG (High Impedance Analog)

Do the following to use the USB pins as GPIO:

1. Set the IOMODE bit of the USBDEV_USBIO_CR1 register HIGH for GPIO functionality and LOW for USB operation.
2. Set he GPIO drive mode for DM/DP I/O pad by configuring the DM_M and DM_P bits of the USBFS0_USBLPM_USBIO_CTL register.
   0x0: OFF: Mode 0: Output buffer off (High-Z). Input buffer off.
   0x1: INPUT: Mode 1: Output buffer off (High-Z). Input buffer on.
   Other values are not supported.

Use the following code snippet to configure the USB pins as GPIO:

/*Set USBIO to GPIO mode*/

*(uint32 *) CYREG_USBFS0_USBDEV_USBIO_CR1 |= (0x01u << CYFLD_USBFS_USBDEV_IOMODE__OFFSET);

/* Set GPIO input enable */

*(uint32 *) CYREG_USBFS0_USBLPM_USBIO_CTL |= ((0x01u << CYFLD_USBFS_USBLPM_DM_P__OFFSET) |(0x01u << CYFLD_USBFS_USBLPM_DM_M__OFFSET));

See the registers TRM of the respective PSoC™ 6 MCU device.