Skip navigation
Home > All Places > PSoC 6 MCU Community > Blog

Hello! Here's some information on how we handle product firmware upgrades in the field, also known as bootloading, with PSoC 6.


First, some background:

With PSoC 3, 4, and 5LP, we designed Bootloader and Bootloadable Components for Cypress's PSoC Creator IDE. These Components have several features. The most notable feature is that they enable bootloading that is agnostic to the host communication channel; that is, you can easily make a bootloader that downloads a new application from the host via UART, I2C, SPI, USB, BLE, and other common communication channels. You can even use a custom communication channel.


Furthermore, the complexities of bootloader and application image placement in target device flash are largely handled for you, making it very fast and easy to get simple bootloaders up and running. Advanced features such as dual images, golden image, host command timing, validation, and security are also available. For more information, see AN73854, PSoC Introduction to Bootloaders.


With PSoC 6, we took a different approach that enables more custom bootloader solutions. To do that, we replaced the PSoC Creator Components with a software development kit (SDK). We made the Bootloader SDK available as part of the Cypress Peripheral Driver Library (PDL) so that it can be used with other IDEs as well as PSoC Creator. You can use the Bootloader SDK to design bootloading solutions of arbitrary flexibility and complexity, while maintaining support for rapid development for common use cases. The Bootloader SDK has the following features:

  • Downloads application images from a host through a number of transport interfaces, e.g. BLE, USB, UART, I2C, SPI.
  • Programs application images to specified addresses in internal flash, SMIF, or external memory.
  • Supports up to 28 application images. Any application can have bootloader capabilities, and can bootload any other image.
  • Supports customization.
  • Enables validating applications.
  • Supports encrypted bootloader image files. Writes encrypted images to firmware without intermediate decryption.
  • Safe Bootloading: save an image at a temporary location, validate it and, if valid, overwrite the working image.
  • Allows copying applications.
  • Switch between applications. Allows passing parameters in RAM.


More details, as well as an application note guide and code examples, will be published soon.



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!


IDEs for PSoC 6 Development

Posted by JimT_21 Apr 18, 2017

Here’s the good news. You can use just about any IDE to create firmware for PSoC 6 devices. How easy or hard it will be may vary, but the choice is yours. Read Software Development Models for PSoC 6 to learn more. I discuss PSoC Creator relative to PSoC 6 and the Peripheral Driver Library (PDL) in that article. The PDL is designed to be used with any IDE.


Let me group third-party IDEs into two categories: those that are “supported” and those that aren’t. You can use any IDE effectively, even "unsupported" IDEs.


Supported IDEs

The list of supported IDEs is subject to change, but as I write this the plans include:

  • IAR Embedded Workbench
  • Keil µVision
  • Atollic TrueStudio
  • iSystem WinIDEA
  • Command-line tools (make file)


For a supported IDE, you get some extra goodies to make life easier. These include

  • A template project for each core
  • Project build settings set for the particular device
  • IDE-specific files like startup code, linker files, or a flash loader
  • A defined export/import process for generated files


The export/import process varies significantly per IDE, so once you get the PSoC 6 platform you’ll want to read the PSoC Creator help files on how to import the code. You are not required to use the export/import process, you can always just add files from the Generated_Sources folder to your IDE’s project file. And that takes us to the "other" IDEs.


Other IDEs

So what if your preferred IDE isn’t on the “supported” list? Well, there is no formal export/import process. You manually add the PSoC Creator generated files to your IDE's project. You don’t have a template project, so you have to set up your own project completely. But it's your IDE, and you're familiar with what options are required and how to set them. You may need to develop some IDE-specific code, like a linker command file. However, you can examine those provided with the PDL to see how it’s done.


In all cases, whether it is a “supported” IDE or not, you can use PSoC Creator generated code if you want, or develop entirely without PSoC Creator. PSoC 6 Components and PDL Drivers talks a little bit about the trade-offs. I am personally very much a believer in code generation tools. Your mileage may vary.


IDEs are highly variable. Some have compilers that do a better job optimizing code. Some support dual-core debugging, and some do not. It’s quite likely that you have your favorite. I learned long ago to not argue over matters of taste or preference, like which IDE is best. I have a suspicion that in my near future I'll be writing some formal detailed collateral on how to use PSoC Creator generated code in your IDE for PSoC 6 development.I'd like to hear from you on whether you think that's a worthwhile bit of information.


What really matters is: can you choose the IDE you want? The answer to that is simple. Yes.



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!

Hi everyone!


Thought I'd give an update on the PSoC 6 Inter-Processor Communication (IPC) feature for the dual-core ARM Cortex architecture.

The PSoC 6 is a multi-core architecture with two processors CM0+ and CM4 on the same die, with all the memory and peripherals available for use by both the cores. This adds a lot of value to the user who wants to set up a system where the processing load is shared by the two cores. To make such a design possible the two cores must communicate with each other. There are different ways that can happen.


At the instruction-set level, you can use the send event instruction (SEV). This generates an interrupt event for each core in a multi-core system. Using the SEV gives you one channel of communication with another core, through the event signal. This means all communication would need to be through this one event. You need to set up a higher layer of code to deal with data transfer and multiplexing of different events.


PSoC 6 hardware implements a more capable solution. In addition to the SEV instruction, PSoC 6 has 16 hardware Inter-Processor Communication (IPC) channels. Each channel can be configured to be an exclusive communication medium between the two cores. Each IPC channel implements a hardware semaphore or mutex. You can use this to ensure exclusive access to shared resources. Each channel also has an associated 32-bit shared data register. You can use the register to pass a 32-bit value, or use it for a pointer to any data of arbitrary complexity.


In addition to the 16 IPC channels, PSoC 6 also provides 16 IPC interrupts. Each IPC interrupt can be used as event triggers from one core to another. This mechanism can be used in conjunction with an IPC channel to set up a messaging scheme with a notification event and acknowledgement.


The Peripheral Drive Library (PDL) implements an API to give you high-level access to the IPC hardware. The PDL implements a semaphore system which can be used to ensure exclusive access to shared resources or single bit flag communication between the two cores. The PDL uses a single IPC channel, but gives you the ability to set up an arbitrary number of semaphores on that channel (limited by available SRAM).


In addition, the PDL also provides communication pipe implementations for messaging between cores. Each processor has at least one “end point” structure. Messages are transferred between endpoints. The end point (among other things) has an array of “clients”. Each client has a client ID (the index into the client array and an associated callback function. ”. The messages sent to a specific endpoint can be addressed to a specific client at the end point. Thus each client can be handled differently when a message is sent to it. 


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


PSoC 6 Flash

Posted by MichiyukiY_91 Apr 11, 2017



Thought I'd give an introduction on the flash in the PSoC 6 architecture.

Our first PSoC 6 device has up to 1MB of flash. A flash controller does 128-bit wide flash reads, to reduce power. PSoC 6 flash has read-while-write (RWW) capability, which allows updating the flash while executing from it. This is useful for applications that update flash, such as bootloaders and data loggers. The CPUs in PSoC 6 each have an 8KB 4-way set-associative flash cache. This reduces the number of flash accesses for CPU instructions, which in turn increases CPU execution speed and reduces power. The CPU subsystem architecture incorporates multiple bus masters – the two CPU cores as well as two DMA controllers and a cryptography block (Crypto). Generally, all memory and peripherals are shared by all of the bus masters. Shared resources are accessed through standard ARM multi-layer bus arbitration. Exclusive accesses are supported by an inter-processor communication (IPC) block, which implements hardware semaphores and mutual exclusion (mutexes).


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

In this article I want to go a bit deeper into the difference between using a PSoC Creator component, and using the PDL directly. I talked about development models for PSoC 6 here. (You can find out what the PDL is here; and how it is designed, here.)


Most PSoC 6 peripherals have a corresponding PSoC Creator Component. You drag the Component into your design and configure it inside PSoC Creator. Based on your design and configuration, PSoC Creator generates the code required to configure the peripheral. It generates an API for that specific component. All of this is unchanged for PSoC 6 and the PDL.

PDL Component.png

Here's what's new. The PSoC 6 Component is built on top of the PDL.


In the past, the Component API was the only option. For PSoC 6, the Component API uses the PDL. PDL 3.0 is a separate entity. That means you have a choice. You can use the Component API, or you can use the PDL API directly. The PDL is designed to work with, or without, PSoC Creator.


Here’s an example. Your PSoC Creator design might include a PWM component, which you could name “MyPWM.” You would at some point write code modify the compare value in the PWM to change the duty cycle. Here’s the Component API code that sets the compare value for that Component.



Notice that the generated Component API calls the PDL API. Let’s start with the PDL API call. This function has three parameters. The first is the base hardware address for the peripheral. (Read PDL 3.0 - Designed for Flexibility to learn about base hardware addresses.) Because the PWM actually has multiple counters, you also specify which counter to use. And of course there is the actual compare value.


By contrast, the Component API call has only one simple parameter: the value. That’s because PSoC Creator “knows” which base hardware address to use, and which counter, based on the system design and pin assignments you set up in the tool.


These two APIs, Component and PDL, are fully compatible. You can mix and match as you see fit. The Component API is often simpler, but adds a level of indirection (a function call to make a function call). In many cases the overhead is trivial or non-existent, and might even be optimized away. In other cases it might be more significant.


The table summarizes some of the key differences.



There is absolutely no requirement to use PSoC Creator. If you do not use PSoC Creator, then you make PDL API function calls directly, providing all parameters. You get the Component API whenever you use PSoC Creator to generate code. You can use it even if you import the code into your preferred IDE.


One neat thing about the Component API in the generated code is that it is often just a wrapper on top of the PDL API. Even if you don’t want to use PSoC Creator as a production tool, you can use it as a learning tool. You will be able to explore the generated code to see how it makes PDL function calls, and learn how to use the PDL effectively.



Posted by MichiyukiY_91 Apr 10, 2017



Thought I'd give an introduction for the ADC available on the PSoC 6 architecture. The ADC is a Successive Approximation (SAR) type with 12 bits of resolution. It is an updated and improved version of the SAR ADC found on PSoC 4 devices. The key features are:

  • Up to 1 million samples per second at a fixed 12 bits of resolution
  • The programmable analog features of PSoC 6 allow almost every pin to be used as an ADC input. The GPIO pin analog signals can be routed to the ADC through the AMUX busses under software control.
  • A built in 8 channel hardware sequencer can also automatically scan each channel and stores the results for later CPU processing. An upper and lower limit is also able to be compared with each scan and generate an interrupt if an out of range condition is detected.
  • Sequencer channels also support hardware averaging and accumulation of up to 256 samples for lower noise or higher resolution and the resulting 16-bit results.
  • Sequencer allows a software controlled 9th channel to be injected between scans for less frequent measurements. The 9th channel can connect to almost any pin through the AMUX busses. 
  • The ADC provides dedicated connections to the integrated CTBm OpAmps and DAC allowing advanced analog signal effects to be generated and scanned.
  • Supports single ended and differential conversions. The 8 channel sequencer supports up to 4 differential signals.
  • Analog reference is selectable to Vdd, Vdd/2, 1.024V, or an external reference provided to a GPIO pin.
  • Able to read the on chip temperature sensor and supply voltages to allow temperature and voltage based adjustments.
  • Supports one shot or continuous hardware scan triggering and a variety of conversion complete signals that can be used with interrupts, DMA, or custom logic.
  • The ADC control signals and data can be routed to the programmable digital logic (UDBs) to create custom scan functionality, and unique automatic processing of conversion data in hardware.


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


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!