Skip navigation
Home > All Places > Product Forums > MCU & PSoC > PSoC 6 MCU > Blog > Authors MichiyukiY_91
1 2 Previous Next


23 Posts authored by: MichiyukiY_91

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!

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!



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!



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!



Thought I've give an introduction to PSoC 6's Digital to Analog Converter.

As a key component of the programmable analog system the PSoC 6 includes a 12-bit Continuous Time Digital to Analog Converter (CTDAC) providing a precision voltage output. The CTDAC can be used in applications that require voltage references, bias, or waveform output. When optionally coupled with the CTBm block the CTDAC provides even greater flexibility. Some of the key features are:

  • Up to 500 kHz output settling and update rate that can be synchronized with a hardware trigger
  • Output voltage data may be provided by firmware or DMA with either immediate update or buffered synchronization. DMA based data provides an efficient method to generate arbitrary waveforms.
  • CTDAC output remains active in Deep Sleep power mode allowing external circuitry to remain biased or internal comparators to retain reference thresholds.
  • Output voltage is relative to the configured CTDAC reference voltage. Reference voltage sources include VDDA, internal chip references, or external references routed to a pin.
  • CTBm OpAmps may optionally be used to buffer the CTDAC output to drive low impedance external loads or to buffer a high impedance external reference voltage.


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

Hi everyone!


Thought I'd introduce PSoC 6's Direct Memory Access (DMA) feature. The PSoC 6 device has two DMA hardware blocks and each DMA block has to 16 DMA channels. Each DMA channel can be configured to transfer data from memory to memory, peripheral to memory, memory to peripheral or peripheral to peripheral, with no CPU involvement.


Each DMA channel’s transfer is configured by a DMA descriptor. The DMA channel only holds a pointer to the descriptor structure in memory (RAM or Flash). Thus the number of descriptors you can associated with a channel, is limited by the SRAM/FLASH memory available to hold them.


The DMA descriptor has a next descriptor field that lets the user chain descriptors. Thus each channel could associate with a descriptor in memory but that descriptor could be the first one in a chain of many descriptors which are also in memory. This is will let the user set up a series of distinct and dissimilar transfer operations.


Each descriptor is built to be configured to work in any of these modes

  • A single data transfer from a source address to a destination address.
  • 1D transfer: A loop of data transfers from source address to destination addresses. You can optionally have the source or the destination or both addresses incrementing with each transfer. The increment value itself can also be configured.
  • 2 D transfer: A nested loop of data transfers. Here the descriptor can be set up to do a loop of 1D transfer.

The input triggers are independently configured to trigger single data transfers or entire 1D loop transfer or an entire 2D loop transfer.


There is a very elaborate trigger routing matrix present in the PSoC 6 that allows for the different peripherals in the PSoC 6 device to generate trigger signal for the DMA channels. In addition the DMA channels themselves have trigger outputs that can be used to trigger other DMA channels.


Feel free to leave comments or ask questions!



Thought I'd introduce the Serial Communication Blocks (SCBs) in the PSoC 6 architecture. Our first PSoC 6 lineup, the PSoC 63 Connectivity lineup has nine SCBs. Each SCB can be configured for either I2C, SPI, or UART. The mode of operation of the SCB can be changed during run time. The PSoC 6 SCBs have two 128 byte deep FIFOs, one for transmit and one for receive. These FIFOs can be written/read by both the CPU and DMA. One of the SCBs out of the nine in PSoC 6 is designed to wake the device up from deep-sleep modes of operation, this SCB is called the deep-sleep SCB. This wakeup can occur on I2C address match, or SPI slave select assertion.


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

Filter Blog

By date:
By tag: