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


36 posts




Software/IDE PSoC Creator 4.3 and PDL 3.1.1




DHT-11 is a popular sensor to measure temperature and humidity. The sensor is manufactured by many companies one of which is Adafruit and the Adafruit sensor can be found here. This blog provides 2 ways to interface DHT-11 with PSoC 6 one using the interrupts and the other without. The PSoC Creator projects for the two applications are attached as part of this blog.


Working of DHT-11 Sensor:


DHT-11 is a single wire digital humidity and temperature sensor, which provides humidity and temperature values serially with one-wire protocol. DHT11 sensor provides relative humidity value in percentage (20 to 90% RH) and temperature values in degree Celsius (0 to 50 °C). DHT11 sensor uses a resistive humidity measurement component and NTC temperature measurement component.


The sensor has 3 pins – Vcc, Data, Gnd. The operating voltage of the sensor is 3.3V to 5V and thus Vcc is connected to 3.3V and Gnd to Ground of the kit. Data pin acts as the asynchronous interface between the sensor and the PSoC device. The Data pin should be configured as a bidirectional pin with drive mode set as Resistive Pull Up. The communication protocol followed by the sensor is asynchronous with a START condition, ACKNOWLEDGEMENT and 5 bytes of Data.

The 5 bytes contain the following data –


Byte 1 - Humidity (whole number part)

Byte 2 - Humidity (fractional part)

Byte 3 - Temperature (whole number part)

Byte 4 - Temperature (fractional part)

Byte 5 - Checksum


1. START – Start condition is sent by the PSoC 6 device. An 18 ms low pulse is sent to the sensor.


Figure 1: Communication protocol of sensor



2. ACKNOWLEDGMENT – The sensor detects the low pulse from the MCU and sends an acknowledgment signal by pulling the Data line low for approximately 54 us. The sensor then sends a logic high for about 80 us and then starts sending Data to the PSoC MCU.


3. DATA – Data is sent serially in terms of bits. Bit-level logic is represented as follows,

  • Logic 0 – 54 us low and 24 us high signal
  • Logic 1 – 54 us low and 70 us high signal

40 bits are sent in a similar way after which the communication terminates. The last byte contains the checksum and needs to be verified to ensure that the data received is valid. The checksum is obtained by simply adding the first 4 bytes.


Figure 2: Bit 0


Figure 3: Bit 1




Application 1:


  • The first approach puts the CPU to sleep when not in use and makes use of the interrupt. The interrupt is triggered at the rising edge of the Data pin which wakes the CPU.
  • The START condition is sent first and the ACK is checked. The interrupt is now enabled, and the CPU is put to sleep.
  • To transmit a ‘0’ (Logic LOW), the sensor sends a 54 us low signal followed by a high signal. This LOW to HIGH transition wakes up the CPU.
  • If the sensor is transmitting a ‘0’ then it sends a 24 us high signal followed by the 54 us low signal of the next bit. If the sensor is transmitting a ‘1’ then it sends a 70 us high signal followed by the 54 us low signal of the next bit.
  • Therefore, the value of Data pin is read after a delay, greater than 24 us, which gives the value of the bit. So, if the bit is ‘0’ then after 24 us the Data pin is low and if the bit is ‘1’ then after 24 us the Data pin is high. Hence, reading the data pin after the will directly provide the bit that was sent by the sensor.
  • This is repeated for 40 times (for 5 bytes) and the bit values are stored in a separate variable for each byte. The interrupt is then disabled.
  • The checksum is verified by summing the first four bytes and checking with the fifth byte, and the temperature and humidity values are calculated. The firmware can then run the application to process these values (in this case report to the user via UART protocol).
  • All the variables are cleared for the next iteration and the process is repeated.


Application 2:


  • The second approach is simpler and more direct without the use of any interrupts.
  • START condition is sent as usual. A counter variable is incremented continuously from the START condition until the next rising edge.
  • The entire duration will be a little over 54 us which is the ACKNOWLEDGEMENT and the counter variable value is stored. If the counter value is more than the maximum allowed value (user-defined), it means there is a communication error. So, communication is terminated and needs to be restarted.
  • The counter variable is reset, and the CPU waits till the signal is low – for the 54 us low signal of the first bit. The counter variable is again incremented for as long as the Data line is high. If the counter value is greater than half of the previously stored value (half of 54 us ~ 27 us) i.e., if the data signal is high for more than 24 us, then the bit value is 1 or else, it is 0.
  • This is repeated 40 times and the bit values are stored in a separate variable for each byte.
  • The checksum is verified, and the temperature and humidity values are calculated. The firmware can then run the application to process these values (in this case report to the user via UART protocol).
  • All the variables are cleared for the next iteration and the process is repeated.


Comparison of the two approaches:


  • The first approach is to be used when power efficiency is crucial. The CPU remains in Sleep state for almost half the time during communication and wakes up only to read the bit value thereby increasing power efficiency. Please refer to the respective device datasheet for information regarding the current consumption of the device in Active and Sleep mode.
  • The second approach is more reliable comparatively and the user need not worry about interrupt latency, interrupts not getting triggered or false interrupts. The program can easily be ported. The only disadvantage being that this method polls for bit value, wasting the CPU processing time.
  • Also, for the second application to work as expected, there should not be any interrupts disturbing normal code execution flow during the communication. If that happens the communication fails. To avoid this the communication logic in the code is put in a critical section.




  • The projects have been tested on CY8CKIT-062-WIFI-BT using PSoC Creator 4.3 and PDL 3.1.1.
  • DHT-22 also follows the same communication protocol and the same projects can be used to interface the DHT-22 sensor.

Alexa Skills Demo on PSoC 6 Wi-Fi BT Prototyping Kit

1. Objective

The objective of this blog is to explain how to use Alexa Skills to control ‘things’ using PSoC 6 Wi-Fi BT Prototyping kit. We will control the speed of a fan on PSoC thermal management expansion board by instructing an Alexa device.


2. Requirements


      1. CY8CPROTO-062-4343W PSoC 6 Wi-Fi BT Prototyping kit
      2. CY8CKIT-036 PSoC thermal management expansion board kit
      3. Amazon Echo device (use Alexa simulator in the Alexa Skill Developer console if echo device is not available)


      1. Amazon developer account to use Alexa Skill developer console
      2. AWS account to use
        1. Compute service - Lambda
        2. Security, Identity, & Compliance service – IAM
        3. Internet of Things service – IoT core
      3. Mbed CLI to run subscriber application on PSoC 6 using Mbed OS ecosystem
      4. Serial terminal (Eg. Tera term) to view output and debug messages.

3.   Summary

Figure 1. Data flow from Amazon Echo to the fan

Amazon Echo is tuned to our use case of controlling the speed of a fan by building a custom skill using Alexa Skills Kit.

The developed custom skill is hosted on AWS Lambda service. Lambda function is triggered from Alexa Skills and the function is coded to publish messages to a topic in AWS IoT based on the input from the developed custom Alexa skill.

The physical device (PSoC6 + 4343W) subscribes to this topic in AWS IoT and generates appropriate PWM signal to control the speed of the fan. In this project, we will operate the fan at three different speeds namely low speed, mid speed and high speed.


Low speed

20% duty cycle (0 to 20% duty cycle will operate the fan in the kit at   its minimum speed).

Mid speed

50% duty cycle

High Speed100% duty cycle

However, in case of general instructions to Turn On/Off or increase/decrease of the speed, following will be the behavior.The user is expected to control the fan by asking Alexa to set or run at one of these speeds.

However, in case of general instructions to Turn On/Off or increase/decrease of the speed, following will be the behavior.


  Turn On

  Fan will run at mid speed
  Turn Off  Fan will run at low speed
  Increase the speed  Fan will run at high speed
  Decrease the speed  Fan will run at low speed

4. Setting up the project


     4.1.  Building Custom Skill

    1. Login Amazon developer account and navigate to Alexa developer console.
    2. Choose Create skill.
    3. Enter name of the skill and leave the rest at default as shown in Figure 2.

               (Ensure default language is English (US).

               Default settings allows us to create a custom skill and use our own AWS lambda endpoint)


Figure 2. Alexa Custom Skill Creation

ASK create skill.png

            4.  Choose template as Start from scratch.

            5.  Start building the custom skill by

                     a. Entering an invocation name – ‘fan controller’ is used in this project. This name is required for launching our custom skill.

                     b. Adding custom intents and utterances –

                         We will add an intent for each of the three speeds that we intend our fan to operate at,

                         namely LOW_SPEED, MID_SPEED and HIGH_SPEED.

                         Add all those phrases the user might utter to achieve the intent’s functionality as its sample utterances.

                         Either create the intents from the GUI in the developer console or use the provided JSON file (intents.json) and copy paste

                         the contents in the JSON editor tab.

                     c. ‘Save model’ followed by ‘Build Model’ and ensure error free build.

                     d. Test your model by using ‘Evaluate model’. Entering a sample utterance should invoke the correct intent.

                     e. Go to Endpoints -> Choose AWS Lambda ARN. Copy the skill Id. This is required in the AWS Lambda services.

                         We will return to the Alexa developer console and add the ARN of the lambda function we create in Section 4.2.

     Refer to Alexa documentation for developing custom skill for more detailed explanation of creating custom skills.

4.2.  Set up AWS IoT core

AWS IoT core requires the following to be set up

1.       Things - Things refer to a representation of the physical device.

2.       Certificates - Certificates should be created to ensure secure communication between AWS and the device.

3.       Policies - you must create and attach an AWS IoT policy that will determine what AWS IoT operations the thing may perform.


Follow the instructions in the amazon documentation to create things, certificates, policies and attach the policies to certificates.

Ensure to have same region selected for AWS lambda and AWS IoT core.

Regions can be selected at the top right corner in both the consoles. N.Virginia (US EAST region was selected in this project).

4.3.  Creating Lambda function

    1. From AWS home page, open lambda services by navigating through Services -> Compute -> Lambda
    2. Choose to create function -> Author from scratch
      1. Enter a function name.
      2. Choose Node.js 12.x
      3. Leave ‘choose/create execution role’ at default (i.e create a new role with basic lambda permissions).
    3. Once the function is created, add a trigger from Alexa Skills Kit. Enable skill id verification and paste the copied skill id from the Alexa skills endpoint section.
    4. Scroll down to the code function area and copy the code provided as index.js to the console.

                Leave the rest at default.

            5. Modify the lambda function to interact with the ‘thing’ related data in AWS IoT.

                    a. Insert Endpoint of your ‘thing’ from the IoT AWS core.

                        Navigate to Things -> Interact and choose the REST API endpoint in the IoT AWS core.

Figure 3. Thing Endpoint in lambda function

                    b. Change the ‘thing’ name in the lambda function per the thing created in AWS IoT as shown below.

Figure 4. Thing name in lambda function


          6. Copy the ARN of your lambda function. Add this to the default region of AWS Lambda ARN in the Alexa Skills Endpoint.

              This is required for invoking this lambda function when the user interacts with ASK.

4.4.  IAM set up

We need to create an IAM policy that provides the minimum required permissions for Alexa Skills to invoke an AWS Lambda function.

      1. Open IAM from AWS home by navigating to Services à IAM (under Security, Identity, & Compliance)
      2. Select Roles and click on the role corresponding to the lambda function created as shown in figure below.

Figure 5. IAM Roles

(*Exact screenshots may differ)

                    3. Click the policy name under permissions tab. Choose Edit policy.

                        Go to JSON tab and copy the content from the attached policy (IAM policy.json).

                        Click on review policy -> save policy.

4.5.  Creating Subscriber Application

                    1.    Install Mbed CLI and Mbed Serial Port driver. Refer to Mbed documentation for more details.

                    2.   Use the PSoC 6 +4343W Prototyping kit in DAPLink mode. Hold SW3 switch for >2 seconds and release.

                          The status LED (LED2) should ramp up an amber light at 2Hz.

                          If you face any issues in entering DAPLink, ensure the kit has latest KitProg3 firmware.

                          Refer to KitProg3 user guide for more details.

                    3. Clone the Code example ‘mbed-os-example-aws-iot-client’.

                         This example connects to a WiFi network and can subscribe to messages from the AWS cloud using the

                         Mbed OS ecosystem from github.

                    4. Enter the subscriber directory and follow the Instructions below to build AWS IoT subscriber code example.

        a.   Change to the application folder (subscriber)

        b.    Prepare the cloned working directory for mbed by entering the following command in command prompt.

   mbed config root .

        c.     Pull the necessary libraries and its dependencies.

                  This will pull mbed-os, AWS_Iot_Client library and its internal 3rd party dependencies

     mbed deploy

        d.     Configure the SSID and password of the desired network in the mbed_app.json file.

                  Replace the word ‘SSID’ with name of the network and similarly for the password.

        e.    Configure the AWS parameters such as Thing name, certificates, private key per the user's AWS account.

            Use the attached sample_aws_config.h for reference.

        f.      Also, configure the AWS topic to be subscribed to receive the messages.

              The lambda code provided in the example updates to shadow of the ‘thing’.

              We will subscribe to the ‘shadow delta’ to receive the messages.

              Refer to Amazon Documentation on shadows for more details.

        g.   We receive messages from AWS thing shadow in JSON format.

              We will use a JSON library to extract the desired state from the JSON formatted message.

        Download the zip JSON parser and extract the contents.

       Create a folder, say mbed-json-parser inside the subscriber folder and place the extracted .cpp and .h files in that folder.

        h.    Replace the subscriber.cpp file in the subscriber folder with the subscriber.cpp file provided.

        i.     Modify the default AWS packet size to high value.

             This is needed to receive the entire message from the shadow and then extract the required state in our subscriber application.

                This macro is available in

                …\mbed-os-example-aws-iot-client-master\subscriber\aws-iot\aws_client.h file.

                Modify AWS_MAX_PACKET_SIZE to 1000 as shown.

                By default, it is set to 100.

Figure 6. Increasing AWS Packet Size


                             j. Build the project using mbed compile --target CY8CPROTO_062_4343W --toolchain GCC_ARM

                             k. Hex file generated can be found in


        Program the hex file using Cypress Programmer or drag and drop the hex file to the DAPLINK drive.

        Alternately, use mbed compile --target CY8CPROTO_062_4343W --toolchain GCC_ARM -f to compile and program.

5. Testing the project

5.1.  Hardware connections:

CY8CPROTO-062-4343W kit is connected to CY8CKIT-036 as shown.

DGND of both the kits are connected. PWM signal for fan 1(PWM1) is connected to P8.7 in this example.


Figure 7. Hardware set up

5.2.  Test Execution

    1. Set up serial Terminal. Connect to the Mbed serial port with a baud rate of 115200.
    2. Speak out the commands to the Echo device/Alexa simulator. Alternatively, you can type the utterances in the simulator. Alexa simulator is available in the ‘test’ tab of your developed custom skill.

   Ensure to select the same language as in Amazon developer account is selected in Alexa Mobile App while setting up the  Amazon Echo device.

   Refer to the Amazon documentation for more details on testing the custom the skill.

   Eg utterances:

        1. Alexa, ask fan controller to set high speed
        2. Alexa, Set low speed from fan controller
        3. Alexa, ask fan controller to run the fan at medium speed

               In these examples, fan controller is the invocation name.

               This must be used in the sentence to launch the custom skill along with connection words such as ask,tell, from etc.

               Refer to Alexa Documentation for more details on how to invoke custom skills.

5.3.  Expected Outputs:

    1. Fan should run at the desired speed.

            2. Echo device/simulator should respond back with the speed at which the fan is running.

                Note: If expected behavior is not observed when using the Echo device,

                please check if Alexa was able to process your speech correctly.

                In the Alexa App, Navigate to Settings -> Alexa Privacy -> Review Voice History to check your interactions with Alexa.

            3. Alexa Simulator Output

                Enter test tab and type the utterance. Alexa skills responds with the output as shown in figure below.

Figure 8. Alexa test (Simulator)


          4. AWS IoT Output

              Enter the activity tab and observe the shadow state being updated as shown.

Figure 9. AWS IoT shadow

        5. Serial Terminal Output

Figure 10. Tera Term Output


Thank you! Enjoy controlling physical devices using PSoC 6 + 4343W through Alexa!

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 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!

Filter Blog

By date:
By tag: