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

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!

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.

Filter Blog

By date:
By tag: