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.

Version: **

Context

The PSoC™ 6 MCU has several Arm^®-specified advanced high-performance bus (AHB) interface masters such as Arm^® CM4 CPU core, Arm^® CM0 CPU core, Datawire0, Datawire1, Crypto, and debug access port (DAP).

Since different bus masters may try to access the bus simultaneously, this makes any access to data movement over the bus subject to arbitration with other masters. Actions such as fetching the descriptor or data can be stalled by arbitration. It is possible to configure the bus arbitration priority setting that these masters have over the AHB.

Example Scenario

For example, if you are using both Data Wire 0 and Data Wire 1 in your project, how do you increase the priority of Data Wire 0 over Data Wire 1 or vice versa?

Solution

The arbitration of the bus is based on the arbitration scheme configured by the PRIO bits of the PROT_SMPU_MSx_CTL register. Each of the bus masters has a PROT_SMPU_MSx_CTL register corresponding to it. You can increase the priority of the bus by writing '0' (highest priority) to the  PRIO bits (bits 8 and 9) of the PROT_SMPU_MSx_CTL register. You can refer to the respective Register TRM of the PSoC™ 6 device for more details.

For information on  which PROT_SMPU_MSx_CTL register to write to, refer to the psoc6_02_config.h file (in the case of PSoC™ 62) that is present in the .....project_workspace\mtb_shared\mtb-pdl-cat1\release-v2.2.0\devices\COMPONENT_CAT1A\include directory, as shown in the following image:

The en_prot_master_t enum contains the different bus masters and their corresponding PROT_SMPU_MSx_CTL register.

In the above example, to increase or decrease the bus priority for Data wire 0 you need to write to thePROT_SMPU_MS2_CTL register. Similarly, for the DMA controller, you need to write to the PROT_SMPU_MS4_CTL register.

Note: Masters with the same priority setting form a "priority group". Within a "priority group", round-robin arbitration is performed.

Version: **

Affected products: PSoC™ 4 and PSoC™ 6 MCUs with AIROC™ Bluetooth® LE.

In Bluetooth^® LE GAP Peripheral role, when a device is advertising, you can change the advertisement and scan response data by using APIs as follows:

For PSoC^™ 4 CY8C4x47xx-BLxxxx MCU with AIROC^™ Bluetooth^® LE:
The CyBle_GapUpdateAdvData API function is used for setting the advertisement and scan response data while advertising is ongoing. This API function must be called when CyBle_GetBleSsState() returns the CYBLE_BLESS_STATE_EVENT_CLOSE state. See the following sample code segment:

if(CyBle_GetBleSsState() == CYBLE_BLESS_STATE_EVENT_CLOSE)
     {
        /* Update the ADV and Scan Response data */
        cyBle_discoveryModeInfo.advData->advData[5]=0x06;
        cyBle_discoveryModeInfo.scanRspData->scanRspData[5]=0x05;
        /* Update the ADV and Scan Response data */
        CyBle_GapUpdateAdvData(cyBle_discoveryModeInfo.advData,
        cyBle_discoveryModeInfo.scanRspData);

     }

For PSoC^™ 6 CY8C63x7 MCU with AIROC^™ Bluetooth^® LE:
The Cy_BLE_GAPP_UpdateAdvScanData API function is used for setting the advertisement and scan response data while advertising is ongoing. On completion of this operation, the GAP Peripheral application receives the CY_BLE_EVT_GAPP_UPDATE_ADV_SCAN_DATA_COMPLETE event. This API function must be called when Cy_BLE_StackGetBleSsState() returns the CY_BLE_BLESS_STATE_EVENT_CLOSE state. See the following sample code segment:

     if(Cy_BLE_GetAdvertisementState() == CY_BLE_ADV_STATE_ADVERTISING)
     {
        if(Cy_BLE_StackGetBleSsState() == CY_BLE_BLESS_STATE_EVENT_CLOSE)
        {
           /* Updating the ADV and SCAN Response data */
           cy_ble_discoveryModeInfo->advData->advData[5]='A';
           cy_ble_discoveryModeInfo->scanRspData->scanRspData[5]='A';
           /* Updating the ADV and SCAN Response data */
           Cy_BLE_GAPP_UpdateAdvScanData(cy_ble_discoveryModeInfo);
        }
     }

Version: **

Question: What is the workaround for the connection issue between HTerm  and KitProg3 COM port after the KitProg3 firmware update?

Answer: After updating the KitProg3 firmware version to 2.21.1005, the HTerm tool, which is a serial terminal, fails to connect to the KitProg3/MiniProg4 COM Port. The following error message appears: “OpenPort::Baudrate Value not supported” (see Figure 1). However, in other serial terminals like Tera Term, the connection is established with the same baud rate settings.

Figure 1. HTerm error on Connect

This error occurs because starting from KitProg3 firmware version 2.21, KitProg3 returns the actual baud rate at which the UART operates that differs slightly from the standard UART baud rates that we set in the serial terminal tool. HTerm compares the baud rate set and the baud rate returned by the KitProg3 device. So, in the case of HTerm, the baud rate set, for example, 115200 does not match with the baud rate returned by KitProg3, 115384. However, this comparison is not done in other serial terminal tools which is why the COM port gets connected without any issue.

Workaround:

Set the actual KitProg3 UART baud rate in HTerm. You can calculate the actual baud rate by following these steps –

Divider=(Master Clock)/(COM Port baud rate)

If in case the divider is a decimal, round it off to the nearest integer. For example, in the case of 115200 –

Divider=24MHz/115200=208.33≈208

After calculating the divider, calculate the actual baud rate –

Actual baud rate=(Master Clock)/Divider

Actual baud rate=24MHz/208 ≈115384

Some of the common baud rates are mentioned in the following table:

After setting the actual KitProg3 UART baud rate in the HTerm tool, the tool connects to the COM port without an error as shown in Figure 2.

Figure 2. COM Port connected

Version: **

After reset, the boot code is the first to run, which performs the following sequence of actions:

1. Executes any hardware-specific initialization code.
2. Verifies whether TOC2  (Table of Contents) in the user flash is valid.
3. Gets the App0 Reset Handler.
4. Configures the SWD/JTAG pins.
5. Delays execution for a period of time (Wait Window / Listen Window).
6. Launches the user application.

For more details on boot code, see the “Boot Code” chapter of the PSoC 6 Architecture TRM.

The timing diagram of the operations on reset is shown below:
Figure 1. Startup Timing Diagram (see PSoC 6 Programming Specifications)

Thus, the total startup time t_startup = t_{lite_up} + t_boot + t_listen

The following table lists the different time labels along with their values and operations done in that period (see  PSoC 6 Programming Specification for these values):

You can create a simple application to toggle a pin in the CM0+ application to see how long it takes for the application to start after reset. Here’s a scope shot of the total time taken to execute the user application from reset:

The value is approximately 21 ms (values may vary). This startup time may not be suitable for applications that require the device to respond quickly after reset.

Why is the startup time around 21 ms?
You can observe that the majority of the time is contributed by the listen window (~20 ms).

In PSoC 6 MCU, the listen window is controlled by the TOC2 (Table of Contents). It is a data structure that provides information about the location of specific content in the user flash such as the security image, user application, and flash boot parameters. The detailed TOC2 format is shown below. See the “Boot Code” chapter of the PSoC 6 Architecture TRM for details:

To configure the listen window, modify bits 2:4 (LISTEN_WINDOW).

Note that if you set the listen window to 0 ms or change other bits (SWJ_PINS_CTL by disabling SWJ, for example), you will no longer be able to program the device again. Ensure that you change only the LISTEN_WINDOW bits.

Set the listen window to 1 ms, which should be suitable for most applications. In the attached projects, the TOC2 structure is modified to set the LISTEN_WINDOW to 1 ms (value = 2) using the FLASHBOOT_WAIT_1MS macro. The CY8CKIT-062-WIFI-BT kit was used for testing.

/** Flashboot parameters */
#define FLASHBOOT_FLAGS ((FLASHBOOT_VALIDATE_NO << TOC_FLAGS_APP_VERIFY_POS) \
                                | (FLASHBOOT_WAIT_1MS << TOC_FLAGS_DELAY_POS) \
                                | (FLASHBOOT_CLK_50MHZ << TOC_FLAGS_CLOCKS_POS))

/** TOC2 in SFlash */
CY_SECTION(".cy_toc_part2") __USED static const cy_stc_toc_t cy_toc2 =
{
    .objSize     = sizeof(cy_stc_toc_t) - sizeof(uint32_t),     /**< Object Size (Bytes) excluding CRC */
    .magicNum    = 0x01211220,                /**< TOC2 ID (magic number) */
    .appAddr1    = 0x10000000u,               /**< Application start address */
    .tocFlags    = FLASHBOOT_FLAGS,           /**< Flashboot flags stored in TOC2 */
    .crc         = 0UL                        /**< CRC populated by cymcuelftool */
};

When the values of TOC2 are changed, the CRC value used to validate the TOC2 also needs to be updated. This is done automatically by the CyMCUElfTool when the build completes in PSoC Creator.

In ModusToolbox, add the following post-build command to the Makefile to sign the application to generate TOC2 CRC.

1. Copy cymcuelftool.exe from the tools_2.x folder in your ModusToolbox installation directory and paste it inside the application directory (already done for you in the attached project).
2. Edit this command to provide the absolute path to the application before performing the build.

POSTBUILD=./cymcuelftool.exe --sign "<path_to_application>/mtb-psoc6-reduce-startup-time/build/CY8CKIT-062-WIFI-BT/Debug/mtb-psoc6-reduce-startup-time.elf" --output "<path_to_application>/mtb-psoc6-reduce-startup-time/build/CY8CKIT-062-WIFI-BT/Debug/mtb-psoc6-reduce-startup-time.elf" --hex "<path_to_application>/mtb-psoc6-reduce-startup-time/build/CY8CKIT-062-WIFI-BT/mtb-psoc6-reduce-startup-time.hex"

The archive attached contains both the ModusToolbox and PSoC Creator projects.

• ModusToolbox project: Toggles pin 10.1 in the CM4 application and sets the listen window to 1 ms. It uses the pre-built CM0p image.
  Because the CM0p application is the one that starts first, you can use the dual-CPU application template and toggle the pin in the CM0p application. This will provide more accuracy because there is usually a few microseconds delay between the start of CM0p to CM4 based on when the CM4 application is started from the CM0p application.

• PSoC Creator project: Toggles the pin 10.0 and 10.1 in the CM0p and CM4 applications respectively, and sets the listen window to 1 ms.

Connect the logic analyzer and press the reset switch on the kit. You should see the startup time from XRES to CM0p executing the application to be around 2 ms, which is a major improvement from 21 ms.

For the ModusToolbox application, you can take the reading from the reset to the start of the CM4 application.

The project contains other macros that you can experiment with. Note that incorrect values may make your device inoperable.

Here’s the scope shot for different values of the macro:

FLASHBOOT_WAIT_20MS:

FLASHBOOT_WAIT_10MS:

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

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

Both ModusToolbox and Cypress Programmer use OpenOCD underneath to communicate with the device. So, to change the programming clock speed, you will have to modify the configuration files (.cfg files) in OpenOCD in both cases.

ModusToolbox:

The OpenOCD commands in ModusToolbox are in the Debugger tab of Run Configurations (Run > Run Configurations). The commands call the appropriate configuration files according to the target device selected. For example, for the CY8CKIT-062-WiFi-BT device, the psoc6.cfg file is called as follows:

The OpenOCD files and folders are in <ModusToolbox installation directory>\tools_2.x\openocd. The psoc6.cfg file calls the psoc6_common.cfg file, which in turn calls the mxs40_common.cfg file. This file contains the adapter speed 2000 command, which sets the programming clock speed to 2 MHz.

Change this command to alter the programming clock frequency. Note that file names and file locations may change; if these files do not exist or do not contain the command, traverse through the configuration files starting with the file in the Config options.

For PSoC 6 2M device, the sequence is psoc6_2m.cfg > psoc6_common.cfg > mxs40_common.cfg. Similarly, for PSoC 64 and PSoC 4 devices, corresponding configuration files are called, which contain the adapter speed command.

The following table provides details on the files that need to be edited for all the devices. File names and locations correspond to ModusToolbox 2.3 release that uses OpenOCD 4.2.0.

Note:

• The file locations are relative to ModusToolbox tools directory. By default, the tools directory is - C:\Users\<user_name>\ModusToolbox\tools_2.x

Cypress Programmer:

Cypress Programmer installation includes OpenOCD. The openocd folder in the installation directory contains all the configuration files.

You can determine the configuration file used by Cypress Programmer for a particular device from the generated logs.

For example, for the CY8CKIT-062-WiFi-BT device, the kit_CY8CKIT_062_WiFi_BT.cfg file is used as shown. This file in turn calls cpu_CY8CKIT_062_WiFi_BT.cfg, followed by cpu_CY8CKIT_062_BLE.cfg and psoc6.cfg, psoc6_common.cfg.

The psoc6_common.cfg file contains the adapter speed 2000 command, which needs to be modified to change the programming clock speed. Note that the filenames and file locations may change in the future; if these files do not exist or do not contain the command, traverse through the configuration files starting with the file in the generated log.

The following table provides details on the configuration files that need to be edited for all the devices. File names and locations correspond to Cypress Programmer 3.0 release, which uses OpenOCD 3.0.0.

 
Note:

• The file locations are relative to the Cypress Programmer installation directory. The default installation directory is - C:\Program Files (x86)\Cypress\Cypress Programmer 3.0\  

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

Author: VitaS_81           Version: **

Background: This issue occurs because during the “Erase Chip" operation, the whole flash of device is erased including the Cypress Secure Bootloader allocated in the main flash area, which is not protected from erasing.

Solution: Use the "Erase Sectors" operation in J-Flash tool instead of “Erase Chip".

If you have already performed an Erase Chip operation, reprogram the Cypress Secure Bootloader into PSoC 64 MCU by using the re-provisioning instructions from PSoC® 64 Secure MCU Secure Boot SDK User Guide.