MSCLP (Multi-Sense Converter Low-Power)

The MSCLP HW block represents the low power family of the fifth-generation CAPSENSE™ devices. More...

Modules
	Macros
	Functions
	Data Structures
	Enumerated Types

Detailed Description

The MSCLP HW block represents the low power family of the fifth-generation CAPSENSE™ devices.

It enables multiple sensing capabilities on PSOC™ devices, including the self-cap and mutual-cap capacitive touch-sense solutions and flyback inductive sensing solution.

The CAPSENSE™ solution includes:

• The CAPSENSE™ Configurator tool, which is a configuration wizard to create and configure CAPSENSE™ widgets. It can be launched in ModusToolbox™ from the MSCLP personality as well as in standalone mode. It contains separate documentation on how to create and configure widgets, parameters, and algorithm descriptions.
• An API to control the design from the application program. This documentation describes the API with code snippets about how to use them.
• The CAPSENSE™ Tuner tool for real-time tuning, testing, and debugging, for easy and smooth design of human interfaces on customer products. The Tuner tool communicates with a device through a HW bridge and communication drivers (EzI2C, UART, etc.) and allows monitoring of widget statuses, sensor signals, detected touch positions, gestures, etc. The application program does not need to interact with the MSCLP driver and/or other drivers such as GPIO or SysClk directly. All of that is configured and managed by the middleware.

CAPSENSE™ Solution

This section describes only the MSCLP driver. Refer to the corresponding sections for documentation of middleware supported by the MSCLP HW block.

The MSCLP driver is a low-level peripheral driver that provides an interface to a complex mixed signal of the MSCLP HW block.

The MSCLP driver alone does not provide system-level functions. Instead, it is used by upper-level middleware to configure the MSCLP HW block required by an application.

The MSCLP HW block can support only one function at a time. To allow seamless time-multiplex implementation of functionality and to avoid conflicting access to hardware from the upper level, the MSCLP driver also implements a lock semaphore mechanism.

The MSCLP driver supports re-entrance. If a device contains several MSCLP HW blocks, the same MSCLP driver is used to configure any HW block. For that, each function of the MSCLP driver contains a base address to define the MSCLP HW block to which the MSCLP driver communicates.

There is no restriction on the MSCLP Driver usage in RTOS.

Usage

The MSCLP driver is a simple wrapper driver specifically designed to be used by higher level middleware. Hence, it is highly not recommended to use the MSCLP driver directly in the application program. To incorporate MSCLP HW block functionality in the application program, an associated middleware should be used.

The MSCLP Driver can be used to implement a custom sensing solution. In such a case, the application program must acquire and lock the MSCLP HW block prior to accessing it.

Setting up and using the MSCLP driver can be summed up in these four stages:

• Define configuration in the config structure.
• Allocate context structure variable for the driver.
• Capture the MSCLP HW block.
• Execute the action required to perform any kind of conversion.

The following code snippet demonstrates how to capture the MSCLP HW block for custom implementation:

cy_stc_msclp_context_t msclpContext = CY_MSCLP_CONTEXT_INIT_VALUE;

    /*
    * Scenario: Capture MSCLP HW block to perform a conversion.
    * This scenario does not cover Pins, Clock, Interrupt, configuration.
    */

    /*...*/
    cy_en_msclp_key_t key;
    cy_en_msclp_status_t status;

    /* Allocates MSCLP configuration structure and initialize it with user's configuration */
    const cy_stc_msclp_base_config_t customConfig = CUSTOM_CONFIG;

    /* Checks if the MSCLP block if free */
    key = Cy_MSCLP_GetLockStatus(MSCLP0, &msclpContext);
    if (CY_MSCLP_NONE_KEY == key)
    {
        /* Captures the MSCLP block and initialize it with user's configuration */
        status = Cy_MSCLP_Init(MSCLP0, &customConfig, CY_MSCLP_USER_DEFINED_KEY, &msclpContext);
        /* Checks if the MSCLP block was captured successfully */
        if (CY_MSCLP_SUCCESS == status)
        {
            /* Block is captured successfully. User's application code can be placed and executed here. */
        }
    }
    /*...*/

Note

User's application code should follow these recommendations:

1. The last sensor configuration in the frame should have the LAST bit of SNS_CTL register set.
2. The START_FRAME bit of FRAME_CMD register should be set prior to calling the Cy_MSCLP_ConfigureScan() API. It should be set once per frame if the frame contains multiple sensor configurations, and each frame if the frame contains only one sensor configuration.
3. The START_SCAN bit of SNS_CTL register should be set in the sensor frame to start the conversion.

The entire solution, like CAPSENSE™, in addition to the MSCLP HW block, incorporates the following instances:

• Clocks
• Interrupts
• GPIO Pins

The MSCLP driver does not configure those blocks and they should be managed by an upper level. When using CAPSENSE™, those blocks are managed by the middleware.

Clocks

The MSCLP HW block requires a low frequency clock (clk_lf) for LF-AoS operation. It can be enabled either:

• Using the Device Configurator (System tab).
• Using the SysClk (System Clock) driver. See the Internal Low-Speed Oscillator (ILO) section for more details.

Also the MSCLP HW block uses internal MRSS clock source for LF-AoS operation, see the Cy_MSCLP_MrssStart() function.

If middleware is used, the clocks are managed by the middleware.

GPIO Pins

CAPSENSE™ provides the ability to form a user interface using widgets. Each widget consists of one or more sensors. These sensors are connected to the GPIO pins.

The CAPSENSE™-related GPIO pins can be divided into three groups:

1. Legacy GPIO sensor pads - all the GPIOs, where the CSD_SENSE/CSD_SHIELD HSIOM connections are supported, the AMUXBUS-A/B are used to connect the sensor and CAPSENSE™ HW block. Required an update of GPIO registers (Drive mode and the HSIOM selection) for this group of pins in order to set the sensor to the specific state (GND, High-Z, Tx, Rx, etc...).
2. MSCv3LP-compatible GPIO sensor pads - a subset of GPIOs, that can be controlled by the MSCLP HW block directly, the AMUXBUS-A/B are used to connect the sensor and CAPSENSE™ HW block. Not required an update of the GPIO registers (Drive mode and the HSIOM selection) for this group of pins in order to set the sensor to the specific state (GND, High-Z, Tx, Rx, etc...).
3. New MSCv3LP GPIO Cmod pads - dedicated pads for the external integration capacitors. Similarly to the MSCv3LP-compatible GPIOs, Cmod pads can be controlled by the MSCLP HW block directly and can be used as extra sense pins. These IOs have lower resistance compared to the legacy GPIOs and MSCv3LP-compatible GPIOs.

Usage of the MSCv3LP-compatible GPIO sensor pads under the CAPSENSE™ MW has the following advantages:

• The CAPSENSE™ MW pre-calculates all needed configurations in advance (during initialization)
• The CAPSENSE™ MW triggers the next scanning by writing to several registers of the MSCLP HW block (instead of disconnecting a previously scanned sensor and connecting a new sensor).

A GPIO input can be assigned to the MSCLP HW block using the following methods:

• Using the Device Configurator (Pins tab).
• Using the GPIO (General Purpose Input Output) driver. Refer to the GPIO (General Purpose Input Output) driver section.

If middleware is used, pin configuration is managed by the middleware. Under the MSCLP driver custom implementation, the application program must manage the pin connections.

Each AMUXBUS can be split into multiple segments. Ensure that the MSCLP HW block and a GPIO belong to the same bus segment or join the segments to establish the connection GPIO-to-MSCLP HW block.

For more information about pin configuration, refer to the GPIO (General Purpose Input Output) driver.

Interrupts

The MSCLP HW block implements two interrupts:

• Active domain interrupt
• Deep Sleep domain interrupt.

The Active domain interrupt can be triggered by the following events:

• Sub Sample: A valid CIC2 sub-sample is complete.
• Sample: A single sample is complete.
• Scan: A single scan is complete.
• Init: Coarse initialization is complete.
• Frame: A single frame is complete.
• CIC2 Error: A CIC2 error is detected.

The Deep Sleep domain interrupt can be triggered by the following events:

• Signal Detect: LP-AoS has detected a signal wakeup.
• Frame Timeout: LP-AoS has detected a frame timeout.
• Frame: A single frame is complete.
• CE Done: Channel Engine done signal. Asserted '1' at the end of the Channel Engine processing pipeline.
• IMO Up: MSCv3LP logic has turned on the MRSS IMO.

The Active domain interrupt can wake up the device from the Sleep power mode. The Deep Sleep domain interrupt can wake up the device from the Deep Sleep power mode.

If CAPSENSE™ MW is used, the interrupt service routine is managed by middleware. When using the MSCLP driver for custom implementation or other middleware, the application program must manage the interrupt service routine.

Implement an interrupt routine and assign it to the MSCLP interrupt. Use the pre-defined enumeration as the interrupt source of the MSCLP HW block. The MSCLP interrupt to the NVIC is raised any time the intersection (logic AND) of the interrupt flags and the corresponding interrupt masks are non-zero. The peripheral interrupt status register should be read in the ISR to detect which condition generated the interrupt. The appropriate interrupt registers should be cleared so that subsequent interrupts can be handled.

The following code snippet demonstrates how to implement a routine to handle the interrupt. The routine is called when a MSCLP interrupt is triggered.

    void snippet_Cy_MSCLP_IntHandler(void)
    {
        uint32_t intrStatus;

        /* Reads interrupt status register */
        intrStatus = Cy_MSCLP_ReadReg(MSCLP0, CY_MSCLP_REG_OFFSET_INTR);

        /* Checks the 'single scan is complete' event that triggered the interrupt */
        if ((intrStatus & MSCLP_INTR_SCAN_Msk) == MSCLP_INTR_SCAN_Msk)
        {
            /* End of scan occurred, get the result and do something with it here */
        }

        /* Clears the pending interrupts */
        Cy_MSCLP_WriteReg(MSCLP0, CY_MSCLP_REG_OFFSET_INTR, intrStatus);
        (void)Cy_MSCLP_ReadReg(MSCLP0, CY_MSCLP_REG_OFFSET_INTR);
    }

    void snippet_Cy_MSCLP_IntHandlerLp(void)
    {
        uint32_t intrStatus;

        /* Reads interrupt status register */
        intrStatus = Cy_MSCLP_ReadReg(MSCLP0, CY_MSCLP_REG_OFFSET_INTR_LP);

        /* Checks the 'signal detection' event that triggered the interrupt */
        if ((intrStatus & MSCLP_INTR_LP_SIG_DET_Msk) == MSCLP_INTR_LP_SIG_DET_Msk)
        {
            /* The signal detection occurred, setup a further scanning */
        }

        /* Clears pending interrupts */
        Cy_MSCLP_WriteReg(MSCLP0, CY_MSCLP_REG_OFFSET_INTR_LP, intrStatus);
        (void)Cy_MSCLP_ReadReg(MSCLP0, CY_MSCLP_REG_OFFSET_INTR_LP);
    }

The following code snippet demonstrates how to configure and enable the MSCLP interrupt:

    /* Scenario: initialize both regular and LP interrupt for the MSCLP block */

    const cy_stc_sysint_t MSCLP_ISR_cfg =
    {
        .intrSrc = msclp_interrupt_IRQn,    /* Interrupt source is the MSCLP0 interrupt */
        .intrPriority = 3u,               /* Interrupt priority is 3 */
    };

    const cy_stc_sysint_t MSCLP_ISR_LP_cfg =
    {
        .intrSrc = msclp_interrupt_lp_IRQn, /* Interrupt source is the MSCLP0 LP interrupt */
        .intrPriority = 3u,               /* Interrupt priority is 3 */
    };

    /* Configures the interrupt with vector at snippet_Cy_MSCLP_IntHandler() */
    (void)Cy_SysInt_Init(&MSCLP_ISR_cfg, snippet_Cy_MSCLP_IntHandler);

    /* Configures the interrupt with vector at snippet_Cy_MSCLP_IntHandlerLp() */
    (void)Cy_SysInt_Init(&MSCLP_ISR_LP_cfg, snippet_Cy_MSCLP_IntHandlerLp);

    /* Enables the interrupt */
    NVIC_EnableIRQ(MSCLP_ISR_cfg.intrSrc);

    /* Enables the LP interrupt */
    NVIC_EnableIRQ(MSCLP_ISR_LP_cfg.intrSrc);

    /* Enables the MSCLP SCAN interrupt mask */
    Cy_MSCLP_WriteReg(MSCLP0, CY_MSCLP_REG_OFFSET_INTR_MASK, MSCLP_INTR_MASK_SCAN_Msk);

    /* Enables the MSCLP LP SIG DET interrupt mask */
    Cy_MSCLP_WriteReg(MSCLP0, CY_MSCLP_REG_OFFSET_INTR_LP_MASK, MSCLP_INTR_LP_MASK_SIG_DET_Msk);

For more information, refer to the SysInt (System Interrupt) driver.

Alternatively, instead of handling the interrupts, the Cy_MSCLP_GetConversionStatus() function allows for firmware polling of the MSCLP block status.

Power Modes

The MSCLP HW block can perform scans in Active, Sleep, and DeepSleep MCU power modes if it is configured for operation in the AS_MS or LP_AOS modes. If MSCLP HW block is configured for operation in the Interrupt Driven (CPU) mode, it can perform scans only in in Active or Sleep MCU power modes.

Note

1. The MSCLP driver does not provide a callback function to facilitate the MCU low-power mode transitions. The responsibility belongs to an upper level that uses the MSCLP HW block to ensure the MSCLP HW block is ready to a power mode transition.
2. MCU transition to Deep Sleep power mode is not recommended if the MSCLP HW block operates in Interrupt Driven (CPU) mode and it is busy. Unexpected behavior may occur. The MSCLP HW block status must be checked using the Cy_MSCLP_GetStatus() function prior to a power mode transition in this case. This restriction is not applicable to Sleep mode and the device can seamlessly enter and exit Sleep mode while the MSCLP HW block is busy.

Refer to the SysPm (System Power Management) driver for more information about low-power mode transitions.

More Information

Important information about the CAPSENSE™ technology overview, appropriate Infineon device for the design, CAPSENSE™ system and sensor design guidelines, different interfaces and tuning guidelines necessary for a successful design of a CAPSENSE™ system is available in the Getting Started with CAPSENSE™ document and the product-specific CAPSENSE™ design guide. Infineon highly recommends starting with these documents. They can be found on the Infineon web site at www.infineon.com

For more information, refer to the following documents:

• CAPSENSE™ Overview:
  • CAPSENSE™ Middleware Library
  • CAPSENSE™ Middleware API Reference Guide
  • ModusToolbox™ CAPSENSE™ Configurator Tool Guide
  • ModusToolbox™ CAPSENSE™ Tuner Tool Guide
  • CAPSENSE™ Design Guide
• ModusToolbox™ Overview:
  • ModusToolbox™ Software Environment, Quick Start Guide, Documentation, and Videos
  • ModusToolbox™ Device Configurator Tool Guide
• Infineon Kits:
  • Information will be available later. In case of urgency, contact the technical support group.
• General Information:
  • PDL API Reference
  • Infineon Technologies GitHub
  • Infineon Technologies

Note

The links to another software component's documentation (middleware and PDL) point to GitHub to the latest available version of the software. To get documentation of the specified version, download from GitHub and unzip the component archive. The documentation is available in the docs folder.

Changelog

Version	Changes	Reason for Change
2.0	Changed name of defines: CY_MSCLP_IMO_24_MHZ -> CY_MSCLP_IMO_25_MHZ, CY_MSCLP_IMO_36_MHZ -> CY_MSCLP_IMO_38_MHZ, CY_MSCLP_IMO_48_MHZ -> CY_MSCLP_IMO_46_MHZ	Names consistency with HW frequency.
1.0	The initial version