Skip navigation
Home > All Places > PSoC 6 MCU Community > Blog
1 2 3 Previous Next

PSoC 6 MCU Community

34 posts

FreeRTOS is a class of RTOS that is designed to be small enough to run on a microcontroller - although its use is not limited to microcontroller applications. It provides the core real time scheduling functionality, inter-task communication, timing and synchronization primitives only. This means it is more accurately described as a real time kernel, or real time executive. Additional functionality, such as a command console interface, or networking stacks, can then be included with add-on components.

Cypress’ PSoC 6 MCUs is supporting FreeRTOS and designers can develop PSoC 6 MCU systems for IoT applications.

See it in a PSoC 6 project here, FreeRTOS for PSoC 6 MCUs.

Also, check out code examples and articles based on FreeRTOS.

Lastly, if you have any feedback, comments, or questions, feel free to leave them here, we appreciate the discussions!


PSoC 6 CapSense design

Posted by ShanmathiN_06 Moderator Jul 11, 2018

Hello everyone!


Here is some information on how to design CapSense sensors while developing Capacitive sensing applications in PSoC 6.


Schematic design:

After selecting PSoC device, while designing schematic you can refer to the following documents:


1) PSoC 6 datasheet (depends on the selected device)

2) Schematic Rule checklist section in AN85951 - PSoC 4 and PSoC 6 MCU CapSense Design Guide (

3) AN218214 - Hardware design considerations (

Layout design:

While designing PCB, refer to the following documents:


1) Design considerations section in AN85951 - PSoC 4 and PSoC 6 MCU CapSense Design Guide (

2) Specifically, layout rule checklist section in AN85951

3) For proximity sensor design, refer to AN64846 - Getting Started with CapSense ( and AN92239 - Proximity Sensing with CapSense (


Following the above mentioned guidelines in various documents will help achieve high SNR, better performance and electromagnetic compatibility.


Feel free to leave comments and ask questions, we appreciate the feedback!

Hello PSoC MCU Developers!

One of our very own Field Apps Engineers, Darrin Vallis has worked with Express Logic to implement the world’s most adopted RTOS, ThreadX, on a PSoC 6 MCU using its native IDE, PSoC Creator. ThreadX, part of the X-WARE IoT PLATFORM, is a high-performance RTOS, best-suited for safety critical designs in areas such as aviation, medical, and industrial.


To find out more on this collaboration, visit and, where you will find example projects and a white paper on this implementation.



Here is part 2 of the Serial Memory Interface (SMIF) feature in PSoC 6.


As described in a earlier post, the Serial Memory Interface (SMIF) in PSoC 6 operates in two modes of operation, the Command mode (MMIO) and Memory Mapped mode (XIP).  The memory mapped mode configures the external memory to be mapped into the PSoC 6 address space. This lets the user execute code from external memory or even use the external RAM memories as System RAM. The SMIF hardware implements two cache memory blocks of 4KB each. These cache are for improving performance of the memory mapped mode. These two blocks are available to serve CM0+ and CM4 masters independently.


One of the main focuses of the PSoC 6 family of devices is its emphasis on security. One important feature in this aspect for SMIF is encryption. The SMIF block has an inbuilt 128-bit AES encryption engine. This encryption hardware is dedicated for the SMIF block. This encryption is available for usage in both the Memory mapped (XIP) and command (MMIO) mode of operation. In the XIP mode the cryptography hardware supports on the fly encryption in write operations and on the fly decryption for read operations. Encryption support can be enabled/disabled, for individual external memory device slaves. Thus once configured initially the encryption feature is automatic and almost invisible.


The SMIF interface will be supported by a feature-rich SMIF driver and an associated GUI based configuration tool. The driver will provide easy to use functions for the users to set up the SMIF block for XIP mode. The driver will also have functions to create command formats in command (MMIO) mode of operation. This will be used to implement special commands supported by different memory vendors.


A GUI based tool is also distributed with the driver. The GUI based configuration tool can be used to configure different preset memory devices to different slave slots in the SMIF. New memory devices can also be added to the data base using a simple interface. The GUI also provides an easy way of defining the addresses to map the memories and also their attributes like encryption. The tool is then used to generate the code that can be used along with the SMIF driver.


Feel free to leave comments and ask questions!



There are a lot of peripherals present in the PSoC 6 device. Quite often, in a system we will need to trigger an action in a peripheral based on an event in another peripheral. An example would be something like the ADC’s End of Conversion (EoC) triggering a DMA channel to transfer data from the ADC result register to a memory buffer. In this case you would route the ADC’s EoC line to the DMA’s trigger input (tr_in) line. What is the resource used to accomplish this routing?

PSoC 6 has a dedicated hardware block called the trigger multiplexer block. The trigger multiplexer block is simply a large group of multiplexers that lets you route trigger signals from any source peripheral to a destination peripheral. The trigger multiplexer block covers all potential trigger sources on its input side and lets user route them to destination peripherals. The trigger multiplexer block is a dedicated hardware and does not consume any of the programmable digital resources like the Universal Digital Block (UDB). The trigger multiplexer block also has a way for the user to generate a software trigger on a trigger route.


Feel free to leave comments and ask questions, we appreciate the feedback!


PSoC 6 I2S Feature

Posted by MichiyukiY_91 Jun 6, 2017



Here is an update on the PSoC 6 I2S feature we have.

PSoC 6 has one I2S hardware block able to produce/receive digital audio streaming data to/from external I2S devices, such as audio codecs, microphones or simple DACs. The frames generated by the IP can be configured to generate data word length of 8-bit/16-bit/18-bit/20-bit/24-bit/32-bit per channel. The channel length is also configurable. The hardware IP provides two hardware FIFO buffers, one each for the Tx block and Rx block. Any writes and reads to/from the FIFOs can be handled by DMAs or CPU.


The overall I2S block diagram it shows below.

P6 I2S.jpg


Feel free to leave comments and ask questions, we appreciate the feedback!


PSoC 6 Watchdog

Posted by MarkA_91 May 24, 2017

Hello! Last week I described the PSoC 6 multi-counter watchdog (MCWDT) resource. Here I will describe the basic watchdog timer (WDT).


PSoC 6 actually has multiple watchdogs - a single basic watchdog timer (WDT) and one or more multi-counter watchdogs (MCWDT). In most cases you will use the WDT for the basic watchdog function, and the MCWDT counters for general counter/timer functions such as measuring time between events and generating periodic interrupts.

The WDT and MCWDT are similar in function, in that the counters generate periodic interrupts, with device reset on the third unhandled interrupt. There are some differences:

  • The WDT has a single 16-bit counter with a 16-bit match register.
  • The WDT is clocked by the internal low-speed oscillator; the MCWDT by ClkLf.
  • The WDT works in Active, Sleep, DeepSleep, and Hibernate modes. The MCWDT does not work in Hibernate mode.

PDL API support is provided for both resources. Remember, for an effective watchdog function, good practice is to never reset the watchdog from an interrupt handler. If you do, then if the CPU or background firmware crashes the watchdog may never trigger because it is still being reset in an interrupt handler. It is better to reset the watchdog somewhere in the main loop.



Here is an introduction to the PSoC 6 Timer Counter PWM (TCPWM) block.

PSoC 6 has two blocks TCPWM. One block contains eight 32-bit counters. The other contains twenty-four 16-bit counters. Each counter can be configured to run as a Timer, Counter, PWM or Quadrature decoder. Counters allow an external signal to capture the current count. Timers can have a programmable compare value which can be used to trigger another event in the system. All the counters in a TCPWM block can be synchronized together for applications such as motor control. Specifically the counters can be started and stopped at the same time.


Will be posting more on this feature. Feel free to leave comments or ask questions, we appreciate the feedback!



Thought I'd introduce the PSoC 6 Character LCD (CharLCD) feature.

PSoC 6 supports a Character LCD (CharLCD) which follows the Hitachi 44780 4-bit interface. The enhanced features of PSoC 6 have no limitation of pin assignment other than a group of seven sequential pins, and it supports the multiple "E" signals for the multiple CharLCDs, as shown in the figure below. The key difference of driver is that the PSoC 6 CharLCD is a part of Cypress' Peripheral Driver Library(PDL), so it can be used with other IDEs.




Some of the key features are the following:

  • Implements the industry-standard Hitachi HD44780 LCD display driver chip protocol
  • Support multiple "E" signals (Support multiple CharLCDs)
  • Requires seven I/O pins for one CharLCD and eight I/O pins for two CharLCDs
  • Displays text data using predefined character in CGROM
  • Displays eight custom characters
  • Displays horizontal or vertical bar graphs


Feel free to leave comments and ask questions, we appreciate the feedback!

Hello! Here's some information on the multi-counter watchdog (MCWDT) resource in the PSoC 6 architecture.


PSoC 6 actually has multiple watchdogs - a single basic watchdog timer (WDT) and one or more multi-counter watchdogs (MCWDT). Each MCWDT has three counters, two of which can generate a watchdog reset. However, if you use the WDT for the basic watchdog function, then all of the MCWDT counters are available for general counter/timer functions such as measuring time between events and generating periodic interrupts.



Note that the counters can be cascaded, allowing you to create combinations of 16-, 32-, 48-, and 64-bit counters.

All watchdog timers - WDT and MCWDT - are clocked by the 32.768-kHz ClkLf.


Feel free to leave comments and ask questions, we appreciate the feedback!



Thought I'd give an update on the Continuous Time Block mini (CTBm) resource in the PSoC 6 architecture.

The Continuous Time Block mini (CTBm) provides the core flexibility of the analog sub-system in PSoC 6. The CTBm interconnects with the analog sub-system supporting input and output connections to GPIO pins, CTDAC voltage source, and SAR ADC inputs. In the initial PSoC 6 release, the PSoC 63 Connectivity line, two configurable OpAmps with programmable routing are included that provide the following features:

  • Two OpAmps with programmable power, bandwidth, and output drive strength to optimize power and performance for your design. Can be optionally enabled in DeepSleep low power mode.
  • OpAmps can be used individually or together to make higher level functions like a differential amplifier.
  • Each OpAmp can be configured as a comparator with optional 10 mV hysteresis and generate interrupts on both rising and falling edges.
  • OpAmps can be configured as unity gain buffers using internal routing or as gain amplifiers with user supplied external gain resistors.


Feel free to leave comments and ask questions, we appreciate the feedback!


Here's an update on PSoC 6's Graphic LCD Controller and Interface (LCDCtrl & LCDIntf).


PSoC 6 provides similar functionality of PSoC 3 and PSoC 5LP graphical interfaces, but a key difference is that the PSoC 6 graphical interfaces will eventually be a part of Cypress' Peripheral Driver Library (PDL), so you will be free to use them in other IDEs.


GraphicLCDCtrl (Graphic LCD controller)

The GraphicLCDCtrl provides a parallel graphical interface which is called RGB display(LCD) Interface. This interface is for a display that doesn't have a display timing generator, so PSoC 6 GraphicLCDCtrl generates all the required display timing signals.


The GraphicLCDCtrl has the following features:

  • Fully programmable screen size
  • Generates timing signals without CPU intervention
  • Supports up to a 23-bit address and a 16-bit data async SRAM device for an external frame buffer
  • Supports i8080 type interface
  • Generates a selectable interrupt pulse at the start and end of Sync signals(Vsync, Hsync or both)
  • Interfaces with SEGGER emWin graphics library


GraphicLCDIntf (Graphic LCD Interface)

The GraphicLCDIntf provides a parallel graphical interface which is frequently called MCU Display Interface or CPU display Interface. This interface is for the display module which has a display timing generator and GRAM, so PSoC 6 provides the control commands and the display data using a MCU interface. (default Intel 8080)


The GraphicLCDIntf has the following features:

  • 8- or 16-bit interface to Graphic LCD Controller
  • Performs read and write transactions
  • Configurable read pulse width
  • Default i8080 interface and adaptable to M6800 interface by adding logic gates
  • Interfaces with SEGGER emWin graphics library


Feel free to leave comments and ask questions, we appreciate the feedback!


PSoC 6 Boot Sequence

Posted by MichiyukiY_91 May 4, 2017



Here's an introduction to PSoC 6's boot sequence.

There are two separate blocks of code that are executed before the user’s code is executed after a reset.  These blocks reside in ROM and in SFlash and are only executed by the ARM® Cortex®-M0+ CPU. The boot code in ROM cannot be changed and is programmed during the silicon manufacturing process.  The section of SFlash that is used during the boot sequence is programmed during the test and calibration process.  It is One Time Programmable (OTP) and remains valid even when the device is erased, just as ROM. 


After reset the Cortex-M0+ CPU starts execution in ROM.  It validates the trim data and boot code in SFlash with a Hash algorithm.  If the data and code are valid, the trim data is used to calibrate hardware for basic CPU operations as well as calibration of analog blocks functions, such as bandgap trim, opamp offsets, etc.  After the trim and calibration is complete, CPU execution jumps to the previously validated Flashboot code that is stored in SFlash.


Flashboot configures the debug port properly depending on the mode of operation such as normal or secure.  The user has the option to permanently (OTP) set the level of debug access or to totally disable the debug port for a full secure environment.  After the debug port has been configured (or disabled) the user’s program is optionally validated with a Hash function.  Depending on the level of security required, the user’s code signature (output from the hash function) may be encrypted to validate that only code from a secure source may be executed. 


After the user code has been validated, the Cortex-M0+CPU then starts to execute user code in main Flash.  The programmer than decides when to enable the Cortex-M4 CPU.  The timing of this is up to the developer.   Validation of the Cortex-M4 code was validated at the same time the Cortex-M0+ code was validated, so there is no need to re-validate it. At this point, both CPUs (Cortex-M0+ and Cortex-M4) will be executing code. Interactions between the two CPUs can be with shared memory or with the IPC (Inter-Processor Communication) block.  At least 8 IPC channels are provided for the developer to use as required.


Feel free to leave comments and ask questions, we appreciate the feedback!



Thought I'd update everyone on PSoC 6's Low-Power Comparator (LPCmp) analog resource.

PSoC 6's LPCmp can be used for not only for general voltage comparisons, but also a wakeup source to system resources when in Hibernate mode and deep-sleep mode.

Some of the key features are the following:

  • Programmable power modes (Normal Power, Low-Power, Ultra Low-Power)
  • Very low power consumption in ultra-low power-mode (typ. 200nA)
  • Short propagation delay (Normal Power max. 50ns, Low-Power max. 150ns, Ultra Low-Power max 3.5us)
  • Comparing a voltage from an external pin against the local voltage reference
  • Comparing a voltage source from the internal analog-mux buses
  • Configurable interrupt edge detection at the comparator output
  • Wakeup source from low-power modes


Feel free to leave comments and ask questions, we appreciate the feedback!

Hi everyone!


The first device in the PSoC 6 portfolio, the PSoC 63 Connectivity line has up to 1MB of internal flash memory and 288 kB of internal SRAM. These memory resources can be used for code and variable storage. But when there is a need for a design to expand beyond the limits of internal memory resources, the user can interface an external memory device to supplement the internal resources. This can be achieved by the use of Serial Memory InterFace (SMIF) block in PSoC6.

The SMIF block is designed to interface through a SPI based interface. The SMIF block supports the following interfaces

  • Simple SPI interface. This is the most common interface covering memories of different types.
  • Dual SPI interface. Similar to SPI but with two data lines carrying two data bits at a time thus achieving twice the data rate of SPI
  • Quad SPI interface: This is a popular interface for Flash memory vendors recently. There are many flash memory devices in the market that support this interface. This interface has four data lines and hence can achieve a data rate that is four times that of the simple SPI
  • Octal SPI interface: This is a fairly new standard and memory manufacturers are starting to create devices supporting this interface. This interface will achieve 8 times the data rate of the normal SPI.
  • Dual-Quad SPI: in this mode of operation there are two Quad SPI memories interfaced with the PSoC 6. The two Quad SPI memories implement the two nibbles in a byte thus contributing to the entire byte. This mode can achieve the bit rate similar to the Octal SPI using two Quad SPI devices. Note that the data in the two Quad SPI memories are in nibble format.


The SMIF block in PSoC can interface up to four memory devices at a time. These memories devices can be of different types (Flash, RAM, NVSRAM, FRAM etc) and supporting different interfaces (SPI, Dual SPI, Quad SPI, Octal SPI). In addition to the interface capability, the SMIF block also supports two modes of operation.

  • Command mode (aka MMIO mode) where the SMIF block is treated as raw communication hardware. In this mode the communication over the SMIF interface(s) is effected by sending commands to the SMIF hardware. These are commands to transmit, receive and create dummy cycles on the different slave interfaces. The SMIF driver will have API to assist the user to create the command format needed for a memory device.
  • Memory mapped mode (aka XIP mode) where the memory devices interfaced with SMIF can be mapped into an internal memory address. This mode will need the user to configure the memory read/write command formats during initialization. The user can map all four interfaced memory devices to internal memory addresses. Any access to the internal addresses is automatically converted to SPI transactions by the SMIF block. Since the memory mapped mode implements both read and write transactions, a user can interface an external RAM memory to the SMIF interface and seamlessly use it as a part of the System RAM.


Feel free to leave comments or ask questions, we appreciate the feedback!