Skip navigation
Home > All Places > Product Forums > MCU & PSoC > PSoC 6 MCU > Blog > 2017 > March


March 2017 Previous month Next month

PSoC 6 SysClk

Posted by MichiyukiY_91 Mar 31, 2017



Thought I'd give an introduction on SysClk in PSoC 6 MCUs. PSoC 6 has an Frequency Locked Loop (FLL) and a Phase Locked Loop (PLL). Both can be used to create High Frequency system clock. For example you can use the FLL to create a clock to run the CM4 and CM0+ cores, while the PLL can be used to clock the audio subsystem. The FLL can achieve an output frequency of up to 100 MHz, while the PLL can reach the device maximum of 150 MHz. The input of the PLL and FLL can be the on board 8 MHz IMO, and external crystal oscillator (ECO), among several other sources.


The PSoC 6 device also contains several programmable clock dividers that can be used to clock peripherals such as Serial Communication Blocks (SCBs), Timer/Counter/.PWMs (TCPWMs), and Universal Digital Blocks (UDBs). There are 8 x 8-bit dividers, 16 x 16-bit dividers, 4 x 16-bit fractional dividers with 5 fractional bits, and 1 x 24-bit divider with 5 fractional bits.


Feel free to ask questions and leave comments!

Hello there!


PSoC 6 device family provides the functional safety to protect a system crash, like the LVD(low voltage detection), the BOD(brown-out Detection), the watchdog, etc. The LVD block can protect the system from a serious power loss as one of the safety function.


The key features are:

  • Monitoring the main power supply voltage(VDDD)

The LVD monitors VDDD and it simply generates an interrupt.


  • Interrupt generation

The LVD generates an interrupt to cause the system to take preventive measures/do some housekeeping before energy runs out.


  • User programmable trip voltage

The trip point of LVD is programmable.


  • Automatic disabling in the deep sleep and hibernate mode

The LVD is disabled when entering the ultra-low power modes to prevent false interrupts during wakeup.


  • No force system reset

The LVD does not reset system, unlike the function of the BOD circuits, but firmware may initiate a system reset if desired.


  • Interrupt edge selection

The LVD can monitor not only falling edge but also rising edge. The rising edge can utilize to check the VDDD settling when system boots up.


Thank you!


PSoC 6 CapSense Block

Posted by VibheeshB_36 Mar 29, 2017

Hello there!

Here is a quick overview of the capacitive touch-sensing solution (CapSense) available in the PSoC 6 device family. Cypress’ PSoC 6 device family features the 4th generation CapSense solution along with enhanced performance and flexibility for system integration.

The key features are:

  • Flexible
    • Supports both self-cap and mutual-cap sensing methods on a single chip.
    • Self-cap sensing based designs are simpler, lower in cost, and work on a single layer (PCB) sensor stack-up.
    • Self-cap sensing provides faster refresh rates and long distance field projections, enabling sensing through thick overlays and various glove materials, and can help implement hover effects.
    • Self-cap sensing is ideal for proximity sensing, enabling system-level ultra-low-power designs. For example, the system can remain in an extremely low-power state with only a proximity sensor activated to wake the system from a low-power state when a user is near to or approaching the system.
    • Mutual-cap sensing is ideal for sensor designs with higher parasitic capacitances such as sensors on a large front panel or on a flex PCB, where multiple PCB layers are stacked very near to each other.
    • Mutual-cap sensing provides superior touch accuracy and enables multi-touch sensing.
    • Cypress’ CapSense solution provides APIs to quickly and dynamically switch between self-cap and mutual-cap sensing methods in the same application, enabling you to exploit the best of both the worlds.
    • Self-cap and mutual-cap sensing on a single chip greatly benefits optimizing system-level power and enhances robust system performance, superior noise-immunity, rejecting spurious conditions, and implementing wet finger tracking, liquid tolerance, etc.
  • Purpose built
    • The PSoC 6 device family offers best-in-class CapSense for user interfaces, ultra-low-power LCD drive for displays, world class BLE for connectivity and CRYPTO for embedded security on a single chip – an attractive solution for IoT, wearables, and industrial products.
    • A Single-chip solution provides advantages for solving system integration issues such as interference between CapSense and BLE or LCD drives.
    • CapSense can perform scanning without either of the CPUs (CM0+ and CM4 cores) and can work in parallel with all other peripherals on the chip.
    • Noise reduction techniques such as multi-frequency scanning and spread spectrum clocking do not affect system clocks and other peripherals that require precision timing.
    • A 10-bit ADC is also available within the CapSense hardware block, enabling measurement of slow-changing signals, such as battery voltages.
  • Performance
    • A linear-feedback shift register based spread spectrum clock offers superior immunity against external noise sources and reduced radiated emission levels.
    • In addition to all the above, the industry leading Cypress CapSense solution offers superior SNR > 300:1, which delivers robust noise immunity, liquid tolerance, and proximity detection.
    • CapSense solution is also capable of measuring capacitance ranging from femto-farads to pico-farads for any of your custom designs.


Thank you!



Thought I'd give an introduction to the Bluetooth Low Energy (BLE) peripheral in PSoC 6 BLE MCUs. The PSoC 6 BLE MCU incorporates a Bluetooth Smart subsystem that contains the Physical Layer (PHY) and Link Layer (LL) engines with an embedded security engine. The physical layer consists of the digital PHY and the RF transceiver that transmits and receives GFSK packets at 2 Mbps over a 2.4-GHz ISM band, which is compliant with Bluetooth Smart Bluetooth Specification 5.0.



  • 2.4-GHz RF transceiver with 50-Ω antenna drive
  • Digital PHY
  • Link Layer engine supporting master and slave modes
  • Programmable output power: up to 4 dBm
  • RX sensitivity: –95 dBm
  • RSSI: 1-dB resolution
  • 4.2 mA TX (0 dBm) and 4.4 mA RX (2 Mbps) current with 3.3-V battery and internal SIMO Buck converter
  • Link Layer engine supports four connections simultaneously
  • Supports 2 Mbps LE data rate

Happy reading!

In Software Enablement for PSoC 6 – What to Expect I talked about what the Peripheral Driver Library (PDL) is. In PDL 3.0 – Designed for Flexibility I described the high-level design that supports multiple peripherals working on either core and operating on multiple data streams. You can use the PDL to take advantage of the power inherent in the PSoC 6 family, while simplifying software development.


There is an entirely different level of flexibility, and that's your choice of development tools. Until you get your hands on the PDL 3.0, this remains theoretical. But you’ll have some choices.


First, a tiny bit of background on the Cypress development tools. Then we’ll get back to PSoC 6.


Cypress provides PSoC Creator, an integrated design environment. If you aren’t familiar with PSoC Creator, let me describe it briefly. It enables the concurrent design of both the hardware system and the associated firmware. You drag components into a design, configure them and (when necessary) wire them together. You use a friendly UI to manage component configuration, pin assignments, system clocks, and interrupts. PSoC Creator is an expert system, and analyzes your design for conflicts or potential problems. Based on your design, PSoC Creator generates configuration and initialization code that you can use when writing the firmware. It supports iterative development – change the design, the generated code changes to match. PSoC Creator is free. It runs on the Windows OS.


PSoC Creator is a really good tool, and I thought that long before I joined the Cypress team. I have worked with code generators in one form or another for years, and I really like them. However, a fundamental principle that I subscribe to is, “your mileage may vary.” As much as I like PSoC Creator, you may not. We’re all about enablement, not about limits, and that includes your choice of IDE. This flexibility is designed into the PDL. We won’t make you change IDEs.


At a high level there are three paths you can take when you develop code using the PDL for PSoC 6.


Use PSoC Creator from beginning to end.

Use it for the system design, and as a development environment for your software. It includes a compiler and linker, a programmer to download the executable to the platform, and a debugger. It has all the features you would expect to find in a good IDE, like code browsing.


Use PSoC Creator generated code in your preferred IDE.

There are a couple of ways to do this. For supported IDEs (IAR Embedded Workbench and Keil µVision tools are on the list), PSoC Creator has defined an export/import process for project files. For any IDE, even if not “officially” supported, you can add PSoC Creator generated source files to the project file in your preferred IDE.


Use your preferred IDE from beginning to end.

While PSoC Creator can handle a lot of the system configuration for you (like clocks, setting up interrupts, and so forth), you absolutely can do this yourself. The PDL is, after all, a source code library. Just use the files you need. For example, the PDL includes code to manage the system and peripheral clocks. When PSoC Creator generates code to do this, it uses the PDL function API to get the work done. You can use the PDL source code directly, rather than the generated code.


When you use a third-party IDE from beginning to end, you lose access to only one PSoC feature. PSoC 6 devices have universal digital blocks (UDBs). A UDB contains programmable logic devices that enable you to build logic at the hardware level that links other hardware in your design, or to create a stand-alone block that performs a new function. If you want to develop a UDB, you must use PSoC Creator.


Of course, in the “real” world things can be a lot fuzzier. These three paths are real, but you can also find your personal sweet spot among these choices. For example perhaps you prefer to use snippets of code from the generated source files rather than complete files (a complex configuration structure perhaps). Or you like the PDL driver for one peripheral, but intend to create your own for another peripheral because of your unique requirements.


All of this is possible. The PDL is an enablement tool. You get all the source code. You can use it as you see fit.


Finally, you should be aware that choosing to use PSoC Creator components in your design presents some interesting benefits, and tradeoffs. I talk about that in a separate post, PSoC 6 Components and PDL Drivers.

PSoC 6 Security

Posted by MichiyukiY_91 Mar 24, 2017



Thought I'd give an introduction on some of the built-in security features integrated into the PSoC 6 architecture. The PSoC 6 architecture provides hardware-based Trusted Execution Environments (TEEs) with secure data storage, for applications requiring security, such as the many IoT products on the market today. The chain of trust in PSoC 6 starts with internal ROM and user programmable OTP (One Time Programmable) memory. These blocks provide a method to lock down code and settings to make the transition from a normal system to a secure system.  It also offers scalable secure memory for multiple, independent user-defined security policies. In addition, an internal hardware accelerated crypto engine that supports standards such as AES-CMAC, RSA-2048, SHA-256, etc, and dual CPUs (CM0+ and CM4) is also included to speed up the code and data verification process.


Happy reading!


Posted by MichiyukiY_91 Mar 24, 2017



Thought I’d give a quick overview of the General Purpose Input Output (GPIO) pins available on PSoC 6. In general they share the high level of configuration and routing flexibility found in PSoC 4 MCUs. The key features are:

  • Several 8-pin ports include Smart_IO logic, which can be used to perform Boolean operations on signals going to, and coming from pins. Can avoid off chip logic and allow device to enter low power modes by offloading CPU processing.
  • Eight drive strength modes
    • Analog input mode (input and output buffers disabled)
    • Digital Input only
    • Weak pull-up with strong pull-down
    • Strong pull-up with weak pull-down
    • Open drain with strong pull-down
    • Open drain with strong pull-up
    • Strong pull-up with strong pull-down
    • Weak pull-up with weak pull-down
  • Hold mode for latching current pin state state in Hibernate mode minimizing system power requirements.
  • Selectable slew rates for dV/dt-related noise control to improve EMI and assist with regulatory compliance testing.
  • A multiplexing network known as a high-speed I/O matrix (HSIOM) is used to multiplex up to 32 analog and digital signals that connect to each I/O pin. Route options include routing peripheral signals to multiple pins and routing Digital System Interconnect (DSI) signals to almost any pin. Routing flexibility simplifies PCB board layout and greatly reduces effort spent allocating pin resources.
  • Every I/O pin can generate an interrupt if enabled and each I/O port has an interrupt request (IRQ) and interrupt service routine (ISR) vector associated with it. Improved pin interrupt functionality and register access makes pin ISR configuration and interaction easy.
  • Standard GPIO pins are rated up to 3.3V.
  • Four GPIO pins are capable of overvoltage tolerant (OVT) operation where the input voltage may be higher than VDD. These may be used for use cases like I2C to allow powering the chip off while maintaining physical connection to an operating I2C bus without affecting its functionality.


Happy reading!

The Peripheral Driver Library v3, for PSoC 6, is more than a driver library. It’s a complete software development kit. I talked about what the PDL is in Software Enablement for PSoC 6 – What to Expect. In this article I want to give you some insight into the very high level design of the PDL drivers. I’ve seen a lot of code in my time, and the PDL is really well designed.


Although this article is about the PDL, just as a teaser, in a coming post or two I'll talk about how PSoC Creator and PDL are integrated. They work together seamlessly. But I get ahead of myself. Back to PSoC 6 and PDL.


The underlying hardware capabilities of the PSoC 6 present unique challenges. For one thing (and it’s a big thing), PSoC 6 is a dual-core architecture, with both a Cortex® M4 and a Cortex M0+ device. Among the many complications you might have to deal with are:

  • Different cores with different instruction sets
  • Drivers for each core
  • Inter-processor communication
  • Sharing resources between the cores


The PDL makes a lot of the complexity go away, from a software perspective. We’re doing our best to make this as easy as possible.


The first big design choice is that the cores use the same register and memory maps for all peripherals. The PDL source code takes advantage of that choice. With very few exceptions, either core can use any peripheral driver. For example, if you want to implement a real-time clock in your design, you create a single RTC driver, not separate CM4 and CM0+ RTC drivers. Write once, use for either core.


It gets better.


The set of available peripherals varies per device. In some cases there are multiple instances of the same peripheral; for example, there are multiple Serial Communication Blocks (SCB). On top of that, each peripheral instance may itself operate on multiple instances of user data.


Imagine if you will (because this is in fact how it works), a platform where you create a peripheral driver used by either or both cores. Where you configure and customize each peripheral. Where you have multiple instances of peripherals, each configured differently. Where each of those peripherals can operate on multiple instances of data. Imagine multiple SCBs, each operating on multiple data buffers, with status and indices into each buffer. All of this happening in a dual-core environment with all the corresponding issues involving potential resource and timing conflicts.


There are many, many ways to make this complicated. The PDL is designed to make it easy. The PDL implements a simple, consistent design based on three fundamental concepts.


Base Hardware Address: At the hardware level, peripheral features and behavior are controlled by registers. Each peripheral instance has its own base hardware address that points to the registers for that instance. The PDL uses this base address to access the necessary registers. Constants for each base address are defined in device-specific header files. It’s easy to find what you need.


Configuration Structure: Each peripheral instance is configurable. You modify values in a PDL configuration structure to change behavior to fit your requirements. When you initialize, enable and use a peripheral, the PDL manages register access using the base hardware address.


Context Structure: A single peripheral instance (however configured) may work on multiple instances of data. For example, an SCB configured as a UART operates on data buffers, and maintains status information about those buffers. The peripheral does not allocate this memory. The PDL defines the necessary data structure on which the peripheral operates. You allocate the structure in memory and provide it to the peripheral.


Many PDL API function calls require a parameter representing one or more of these three concepts. The precise details vary per peripheral, but the design is consistent throughout the PDL. When you look at the actual wording of function prototypes, you will discover that not only is the design consistent, so are the parameter names. The base hardware address is always called base. The configuration structure is always called config.


It’s a little thing, name consistency. Someone new to PDL 3.0 may not even notice. But it has a big impact. Once you get it, you’ve got it! There is no need to figure out, ok, so how is this driver put together? Of course each driver is functionally different, with its own API. But each uses the same parameters for the same things. And that will make your life as a developer a lot easier.

Interrupts in PSoC 6

Posted by MichiyukiY_91 Mar 20, 2017

Hello out there!

This is an update on PSoC 6 interrupts and its features/capabilities. Feel free to read through and leave a comment!


  • PSoC 6 BLE has 139 device interrupt sources from various peripherals such as TCPWM, GPIO, IPC, UDB, SCB, RTC, MCWDT, DMA and many more. These can be connected to either of the two cores - the CM4 which has 240 NVIC lines or the CM0+ which has 32 NVIC lines. Since CM0+ has lesser number of NVIC interrupt lines than the device interrupt sources, a 240:1 multiplexer structure is present on each of the 32 lines to select one of the 139 device interrupt sources.
  • There are 33 interrupt sources that are capable of waking up the core from deepsleep mode. CM4  NVIC lines 0 to 32 and CM0+ NVIC lines 0 to 7 support these deepsleep capable device interrupt sources. 
  • CM4 supports configurable priority from 0 to 7 and CM0+ supports configurable priority from 1 to 3. Priority 0 in CM0+ is reserved for system calls. CM0+ has 32 NVIC lines out of which 4 interrupts are reserved for IPC system calls, IPC Crypto, and IPC pipe interrupts.


Happy reading!

As a developer, working on new hardware is pretty common. The product team says “We’re going to use X in the next version.” About the first question on your mind when this happens is, “How do I write software for this platform?”


Let me give you a quick peek into what’s coming for PSoC 6. It’s pretty sweet. It is called the Peripheral Driver Library (PDL), The version for PSoC 6 is version 3.0. The PDL  is much more than just a driver library. It is actually a complete software development kit. It will look something like this:



The PDL includes:

  • All the device-specific header files and startup code, for every PSoC 6 part and package
  • A driver library provided in source code that you can easily configure for customized drivers
  • Fully-integrated middleware, like the Cypress BLE stack
  • FreeRTOS


In short, it will have everything you need to fill the gap between your application and the hardware. It supports every functional block on the device. The code for each function in each driver is fully documented. The same library works for both the CM0+ and the CM4 cores on the PSoC 6.


PDL 3.0 for PSoC 6 is entirely new, just like the PSoC 6 family, and a lot more comprehensive than earlier versions of the PDL. PDL 3.0 will support PSoC 6 only. I am personally up to my eyeballs helping to get this ready for you. And that’s pretty exciting.


If you've got a topic you'd like to see discussed, about the PDL or software development for PSoC 6, let me know in the comments. I'll see what I can do. For now, I recognize this is all theoretical, until you can get your hands on the actual software. Stay tuned, there’s a lot of neat stuff coming.

Filter Blog

By date:
By tag: