MikroElektronika Development Boards

Clicker 2 for PSoC 6

Overview

The Clicker 2 for PSoC 6 from MikroE is a two-seater Click board featuring a PSoC 6 MCU that retails for $129 (~£102) that I got from eBay for just £10.98 and is my first MikroE product. Note that there are other Clicker boards that use a different microcontroller board with one or two mikroBUS sockets for click boards, and so, there are other 'Clicker 2' boards.

The product page can be found at:

www.mikroe.com/clicker-2-psoc6

At the bottom of the page you will find links for example projects, schematic, manual, IDE and programming downloads.

When I received the Clicker 2 it came in a box (apparently unused, none of the 3 headers were soldered), the board is a bit bigger than an Arduino Uno. A nice touch is that as you open up the box you are greeted with various photos of the board with information, and a getting started guide.

The click boards are standardised add-ons (like Arduino shields) -buzzer, relay, Wi-Fi, etc. - that can be plugged into the Clicker 2's mikroBUS socket (two sockets on the Clicker 2 board). The list of Click boards can be found at:

www.mikroe.com/click

The board features an on/off switch, reset button, two mikroBUS host sockets (each mikroBUS socket consists of x2 8-way female headers with their pinout labelled on the board), two push buttons T2 and T3 (connected to I/O P1.5 and P0.4 respectively), two user LEDs LD1 and LD2 (P5.5 and P5.2 respectively), power and charge LEDs, micro USB-B connector, and programmable status LED. Additionally, the board has a KitProg2 compatible programmer chip, battery connector, external programmer connector (male 5-way header provided that can be soldered to the board), LTC3586 power management IC, x2 26-way unpopulated GPIO and power connections on the board long edges (male headers provided) for additional shields and general use. On the back of the board bottom right it says the hardware version (REV 1.02 on mine), and there's a sticker with '2018' written, so the board seems to be from that year.

Going into more detail the board spec. is as follows:

PSoC 6 MCU CY8C6347BZI-BLD53 max frequency 150MHz, ARM Cortex M4/M0 microcontroller dual core

1MB Flash / 32KB EEPROM / 32KB Secure Flash

288KB SRAM

Clock Speed 150MHz/100MHz

Dual core ARM Cortex-M4 architecture

32 timer/counter/pwm

x1 12-bit SAR & x1 10-bit CSD ADCs

x2 DACs

Digital voltage range: 1.7 - 3.6V

Analog voltage range: 1.7 - 3.6V

76 programmable GPIOs

Bluetooth 5 LE

32MHz crystal used to generate MCU's clock and 32.768KHz crystal oscillator for watchdog timer

30g weight

The advantage of a dual core system is that you can have one core doing something time critical and the other less time sensitive tasks.

Programming

For testing the board I downloaded the examples and the PSoC Creator IDE (I installed PSoC Creator 4.4), the latter only supports Windows with no mention of which versions other than 32-bit and 64-bit are supported - you will need an Infineon login (which is free) to download. After downloading I ran through the installation to install PSoC Creator IDE, note that at the end you will have to enter your name and email unless you check 'Continue Without Contact Information' before clicking 'Finish'. However, even so it will still ask you to register although you can click 'Register Later'.

I plugged the board into my Surface (running Windows 10) and Windows detected it as 'Cypress KitProg2' and it showed up as an USB-UART board in Device manager. On the board, the green PWR LED and yellow programmer status LEDs were illuminated. The two user LEDs flashed on and off, LD2 first then LD1, then both switching off together, likely a built-in demo.

Shortly I'll go over the example projects but first let's look at using the Clicker 2 IDE, PSoC Creator, V4.4 in my case - below you can see the start screen when you open the program:

The warning in the Output section of the window occurred because the Clicker 2 wasn't connected when I opened the software. You can also see that it advises to update the board's firmware - recall that KitProg2 is the on board programmer, which is what Windows detected. So I opened the programmer, PSoC Programmer (my version 3.29.0), which can be seen in the image that follows:

I had to set the 'Device Family' drop-down to CY8C63x and 'Device' to 'CY8C6347BZI-BLD53'.

I found the programmer software when launched didn't detect my board so I unplugged and replugged and it detected it and a pop-up appeared advising to update the firmware by clicking on the 'Utilities' tab and clicking 'Update Firmware'. I did so and it took almost 50 secs, during which the board's programmer status LED flashed slowly. What's nice about the programmer software is that it has progress bar and status indicators at the bottom of the window so it's clear what it's doing. The two user LEDs on the board continued to flash slowly as before, which was a good sign. The board now shows up as 'KitProg3 USB-UART'.

Examples

I then closed and reopened PSoC Creator and opened the BUTTON example project opened in PSoC Creator, see below:

Note that in the Output window it has made a backup of the original project since the project was created in an earlier version of the PSoC Creator software. The software has some nice features, such as schematic support (schematic editor), and pin planner (Pins), much like an FPGA:

The Pins option was double-clicked in the Source pane to bring up the 'Pins' window. You can also click on the various tabs in the Design area running along the bottom for Analog, DMA, etc, which nicely separates complicated projects.

We can see that two buttons and two LEDs are used, notice the pin numbering, for example, BTN1 is port P1[5] but on the board is labelled P1.5. Pin numbers can be typed in or selected from the drop-down, the latter has the advantage that it lists the various features available for each pin.

Along the left side in the Workspace Explorer we can see a lot of files but many of them appear to be boilerplate. Of interest is main_cm0p.c (double-click to open), which is the actual BUTTON code, which looks to be a C file:

As you can see, the example code is very simple, using the GPIO function Cy_GPIO_Inv(), which inverts the state of the LED pins.

In the schematic each button is wired to an LED, BTN1 (P1.5) to LED1 (P5.5), and BTN2 (P0.4) to LED2 (P5.2). The reason why pressing a switch turns the corresponding LED off is because the LEDs require a logic 1 to switch on but pressing a button produces a logic 0.

But when I built the project (Build->Build Design01) I got these errors:

Error: fit.M0051: The given PDL path '' is invalid. Unable to find required PDSC file.

Error: fit.M0050: The fitter aborted due to errors, please address all errors and rebuild. (App=cydsfit)

I found a solution to the first error:

https://community.infineon.com/t5/PSoC-Creator-Designer/Error-generating-while-generate-application/td-p/86680

The only difference was the PDL subfolder was 3.1.3 instead of 3.1.2. I then did the build again and it was successful although I did get a pop-up about removing unneeded configuration files and then another window asking whether to replace or cancel - I clicked the Replace button.

It took about four minutes to do the build and while the first build will usually take a lot longer than additional builds after making minor changes, the slowness compared to (for example) an Arduino can make development a lot longer.

After a successful build you can program the Clicker 2 by either clicking the Program icon or going to Debug->Program. For me it reported 'Can't Open CMSIS-DAP Port' in the Select Debug Target window:

I had to click 'Port Acquire' and it successfully detected the board, if the option isn't there it may be because you have the Programmer app open so close it and then select 'Program' again in PSoC Creator. Next, click 'PSoC 63 CY8C6347BZI-BLD53 (CM0p)' or 'PSoC 63 CY8C6347BZI-BLD53 (CM4)', it doesn't matter which core you select when programming but it does matter when debuggin. If you don't select a core and just click the 'OK/Connect button' and then the 'Close' button, programming won't start. So make sure you click either core then the 'OK/Connect' button to start programming both cores (if a core isn't used it will be idle).

Note that it will also build if needed before programming. After programming both user LEDs came on and pressing either button caused the corresponding LED to turn off but only while the switch was held down. Note that in the Button example only the CM0p core is doing something useful.

I also followed a 'Hello World Blinky' tutorial found on page 11 of the PSoC Creator user guide, which can be accessed from PSoC Creator: Help->Documentation->PSoC Creator User Guide. I changed accordingly the target device when creating the new project: in 'Create Project' pop-up I clicked the 'Target Device' radio button, selected 'PSoC 6' from the first drop-down and in the second chose <Launch Device Selector...>:

I then selected the appropriate device. Notice that various information given for each chip. Then I clicked the OK button, and continued through the tutorial, which involves creating a schematic for the project and provides a way to make it easier to create projects and may be appealing to those more familiar with electronics than programming. When it came to creating the schematic (see screenshot below) I noticed that the PWM component in the user guide was different to the one in my PSoC Creator, likely because the tutorial uses a different device which has different features but it didn't prove to be a problem.

When it came to changing the PWM component's implementation to 'Fixed Function' I couldn't see that option. However, I had to set in the Configure window for the PWM component:

5000 for Period 0

2500 for Compare 0

To get the correct timing, which I found out from the downloaded PWM example, which is similar to the tutorial example but involves both of the on board LEDs so they alternate, by making use of the pwm and pwm_n outputs of the PWM component.

I set the clock component frequency to 5KHz rather than the 0.25KHz in the tutorial.

When it came to assigning the output pin in the Pin Editor, I set Pin_1 to P5.5 (user LED 1).

In the part where they add code to main.c, that wasn't available to me, there are actually 2 main.c files (main_cm0p.c & main_cm4.c) since it's a dual core system but the kits mentioned in the user guide have single core processors. So I added the code - PWM_1_Start(); - to main_cm0p.c (core 0) before the for loop within main().

I then plugged in the board and clicked Program and once finished, user LED 1 flashed at 1Hz. The reason it's 1Hz is because the timing is based on the period of 5000 divided by the clock input of 5000.

This is a good example of using PWM to flash an LED rather than for brightness control since the frequency isn't fast enough and the duty cycle is around 50%.

We will now continue to go through the other project examples that can be downloaded from mikroe.com.

LED BLINK

Turns the two on board LEDs on and off in different sequences demonstrating the use of various delay and GPIO functions using a single core. The following functions are used:

Cy_GPIO_Inv() inverts the LED state.

Cy_SysLib_Delay() generates a delay.

Cy_GPIO_Clr() turns an LED off.

Cy_GPIO_Set() turns an LED on.

The schematic just shows the two LEDs with their individual pin assignments.

BLUETOOTH

Unfortunately I had a lot of trouble getting the Bluetooth example working but was eventually successful. What is supposed to happen is that after programming you connect to the Clicker 2 using an app on your smartphone and then you can control an LED on the board.

While trying to troubleshoot I did find a PDF which, on page 17 walks through a BLE (Bluetooth Low Energy) design, which seems to be similar to the Clicker 2 BLUETOOTH example, although the pinning is different as its designed for a different PSoC 6 board and there are some differences in code:

https://www.eettaiwan.com/wp-content/uploads/sites/5/downloads/Cypress_WP_201805_01.pdf

Like with the Clicker 2 BLUETOOTH example, the LEDs are connected to VDD, thus logic 0 turns the led on, logic 1 off.

In the project schematic we can see three LEDs, Advertising_LED (P5.5), Disconnect_LED (P5.2), and Alert_LED (P10.6), all of which indicate the alert level, and there is a Hibernate_Wakeup_SW switch (P1.5), which is user switch 1 but called SW2 in the schematic. The schematic shows how to connect up the LEDs and switch but it's only the Alert_LED that needs connecting to the board. Additionally there are MCWDT (Multi-Counter WatchDog Timer), Bluetooth 5.0, and UART (for debugging, TX on P0.3) components.

Looking at main_cm0p.c we can see the code is quite simple, the main part of the code attempts to start the Bluetooth (BLE) module using Cy_BLE_Start(), returning value CY_BLE_SUCCESS if successful, which enables the Cortex M4 core by calling Cy_SysEnableCM4(), if unsuccessful the CPU is halted using CY_ASSERT() by passing a guaranteed false value. Otherwise, a loop begins in which the core enters deep sleep by calling Cy_SysPm_DeepSleep(), and Cy_BLE_ProcessEvents() is called to process the BLE stack.

In main_cm4.c, which has a lot of code to handle BLE, which I won't go into too much detail as there is a lot. Of interest we can see in main(), function BleFindMe_Init() is called, which sets SW2 as a hibernate source and then an attempt is made to initialise the BLE stack, failure of which results in the CPU halting. Note the use of UART_PutString(), a means to output debug information over UART. Also, from main(), function BleFindMe_Process() is called in a loop, to process Bluetooth events, and set alert level using the Alert_LED.

When it came to building the project, I noticed quite a few warnings but the build was successful. You will need to connect a blue LED with series 4.7K resistor, anode side to 3.3V, cathode to P10.6, which is on the long edge, so you will need to solder a header if haven't already. Alternatively, to use one of the mikroBUS pins you can change the Alert_LED to something else by opening up Pins and choosing a different GPIO from the Port drop-down, example P8.6, and then build.

The example requires the CY SMART app to connect to the Click 2, which I couldn't find on the Android Play Store. In the comments in main_cm0p.c links are provided for the app for both Android and iPhone, but the links are dead. Looking at the URL using Wayback Machine site the app was available in 2022, but while the app cannot be downloaded at least it's possible to read about the app.

I did find what looks to be an archived version of the Android app in APK form:

https://cysmart.en.aptoide.com/app

However I also found on the Google Play Store 'AIROC Bluetooth Connect App' and there's also a Windows version:

https://www.infineon.com/cms/en/design-support/tools/utilities/wireless-connectivity/cysmart-bluetooth-le-test-and-debug-tool/?utm_source=cypress&utm_medium=referral&utm_campaign=202110_globe_en_all_integration-software&redirId=SD1348

The previously mentioned PDF does reference the AIROC app, likely a successor to CY SMART.

After programming the Clicker 2 with the Bluetooth example, no LEDs were lit. In the AIROC app I saw 'Clicker 2 for PSoC 6' listed (to refresh the list, press the menu button and select 'Bluetooth LE Devices') but I couldn't pair to it no matter how many times I tried. 

So I decided to try Debugging the Bluetooth example, which allowed me a better understanding of how the program works and debugging the board in general. When debugging you can select 'Debug without Programming' instead of 'Debug' to avoid programming the board again. The Bluetooth example is supposed to output debug messages over UART so a UART to USB converter and appropriate software (example, PuTTY) can be used to view them. See the UART example discussed further down the page for how to connect up a UART to USB converter.

When debugging the Clicker 2 you need to select the core you want to debug as PSoC Creator only supports debugging one core at a time, if you try to set a breakpoint for the other core it won't trigger.

Oddly, I found that no debug information was outputted via the UART even though I stepped through the code and UART_PutString() was called several times. Note the UART example uses UART_1_PutString(), contained in UART_1.h, whereas the Bluetooth example uses UART.h. The only difference is that UART_1_PutString() passes UART_1_HW to Cy_SCB_UART_PutString() but UART_PutString() passes UART_HW. The difference between the function names, the header file names and parameters passed is based on what the UART component was named (UART vs UART_1).

It turns out the reason no debug text was outputted from the Bluetooth example was because UART_Start() was never called - perhaps this was intentional so debug text isn't outputted by default. To enable it, in main_cm4.c put at the start of main() before BleFindMe_Init():

UART_Start();

However, when viewing the debug text in Putty the characters appeared garbled. I had a look and found that in the UART component (double-click on the schematic to access its properties) the Bit Order was set to 'MSB First' when it should be set to 'LSB First' - in the previously mentioned PDF, on page 26 they also show 'LSB First', which is what is most commonly used. So in the schematic I changed the UART Bit Order to 'LSB First'. After programming, now text was appearing correctly in Putty. Note that I couldn't see a way to change bit order in Putty.

The debug text showed that the program was running but wasn't responding to the switch, which is supposed to wake it up. I got these messages multiple times:

Entering deep sleep mode.

Exiting deep sleep mode.

Another issue I found was that in the schematic they indicate that the LEDs should be connected to VDD via limiting resistors, which requires logic 0 to switch them on, but the two on board LEDs of the Clicker 2 (used for Advertising_LED and Disconnect_LED) are connected to GND, thus require logic 1 to switch on. In main_cm4.c they are using Cy_GPIO_Set() to turn the LEDs on, which sets the GPIO to a high state. Comparing the code in the PDF to the example they use some different functions, for example, Cy_GPIO_Write() instead of Cy_GPIO_Set() and Cy_GPIO_Clr().

Having failed to get the Bluetooth example working I decided to start the project from scratch following the PDF instructions, making sure the UART was working first. When setting configuration for the LED Digital Output Pin, I left the Initial drive state as the default of 'Low (0)'. When it came to adding files (BLEFindMe.h, etc.) they did not appear to be in the Clicker 2 example so I just copied main_cm0p.c and main_cm4.c to the project I had created. It looks like the code in the files mentioned in the PDF are contained in the two main core files in the Clicker 2 example.

I added UART_DEBUG_Start(); at the start of main() in main_cm4.c and changed all references to 'UART' to 'UART_DEBUG' to match the UART component name. After building and programming, I was still unable to connect to the Clicker 2 and the on board LEDs didn't come on at all, the debug messages were similar to before, however.

I did find a fault, and it explains why SW2 is mentioned as that is the actual switch that should be used to wakeup the board rather than SW1 so I changed on the Pins page 'Hibernate_Wakeup_SW' to P0.4, as that pin is capable of wakeup whereas P1.5 which SW1 is connected to isn't.

Debugging some more, in StackEventHandler() when dealing with case CY_BLE_EVT_STACK_ON, which happens quite early, both on board LEDs turn on by calling Cy_GPIO_Inv() for Advertising_LED() and Disconnect_LED() which is odd as Cy_GPIO_Inv() inverts the state of the pins. In the PDF, however, they don't detail the code for CY_BLE_EVT_STACK_ON.

When we get to case CY_BLE_EVT_STACK_ON and advertisement starts, both LEDs turn on, Cy_GPIO_Set() is used for both LEDs.

The reason debug keeps showing 'Entering deep sleep mode.' followed by 'Exiting deep sleep mode.' is because in EnterLowPowerMode() those strings are outputted and EnterLowPowerMode() gets called regularly. In EnterLowPowerMode(), Cy_SysPm_DeepSleep() is called and from my understanding will only enter deep sleep if there are no tasks to do. The last debug message is 'Entering deep sleep mode.' and in the PDF they say to press the board's reset button before trying to connect.

When I tried to pair with the app it will try and then fail and with the debug message CY_BLE_EVT_GATT_DISCONNECT_IND followed by CY_BLE_EVT_GAP_DEVICE_DISCONNECTED.

As previously mentioned there is a CySmart app for Windows, which can be found at:

https://cysmart.software.informer.com/

However, I couldn't try that as it requires a special Bluetooth dongle. This is because Clicker 2 uses Bluetooth LE, which isn't compatible with classic Bluetooth, thus a device is needed that supports Bluetooth LE. My phone, Xiaomi Mi 9T, does support Bluetooth LE, though and I did install an APK of the original CySmart app I found online on my phone but still couldn't connect to the Clicker 2.

What did work for me was using one of the examples built into PSoC Creator: CE217637_BLE_Find_Me01. The code is a lot simpler than the Clicker 2 Bluetooth example I had downloaded but it still makes use of both cores. After building and programming I saw a promising result: user LED 1 (advertising) was flashing, user LED 2 (disconnect) was on, and the external LED (alert) was also on. After three minutes, user LED 1 remained on and user LED 2 switched off, which is the correct LED behaviour. Pressing user switch 2 caused user LED 1 to start flashing again and user LED 2 came back on, unlike with the downloaded Bluetooth example.

However, at first I couldn't pair with the Clicker 2 but I eventually realised that you have to tap on the 'Find Me Target' name in the app to pair rather than the 'NOT PAIRED' part of the graphic. After pairing using the app, user LED 1 remined on, selecting 'Find Me' and choosing an alert level from the Immediate Alert drop-down to turn the alert LED off if 'No Alert' selected, blink for 'Mild Alert', and on solid for 'High Alert'. Note that if you go back to the 'BLE Devices' page it will disconnect from the board. Oddly, user LED 2 (disconnect) always stays on except in deep sleep mode. This may be because the LED behaviour is inverted due to being connected to GND instead of VDD.

Going back to the downloaded Bluetooth example and the one I started from scratch I still couldn't connect using the app so while there was a case of user error (tapping on the wrong part in the app) there was indeed a fault with both of the other projects but I don't know what exactly.

UART

This is a transmit and receive UART example which works by receiving data via the UART RX pin (P0.2) and sending it back, using TX (P0.3), both available on mikroBUS 1 along with GND. The example assumes you are using a USB UART click board, such as this:

https://www.mikroe.com/usb-uart-click

However, it's easy to use any 3.3V compatible UART to USB converter (I used such a module that was included with a Waveshare FPGA board). To connect your own UART converter connect its GND to the Clicker 2 GND, Clicker 2 TX to UART board RX, Clicker 2 RX to UART board TX, this is assuming the converter runs off its USB port's power. You can then use PuTTY (or similar) by selecting your UART converter board's COM number and setting baud to 115200. After programming the Clicker 2 in the PuTTY window should see 'MikroE basic UART example!!!' ten times, followed by 'mikroE'. Anything you type in PuTTY will be displayed immediately, pressing return takes you back to the start of the line.

In main_cm0p.c in main(), UART is started with UART_1_Start() and after 100mS delay, a for loop is used to output test_string[] by passing the string to UART_1_PutString(), followed by 200mS delay. Another for loop follows but outputs in sequence each char of string test_string2[] using UART_1_Put(). Lastly, an endless for loop is entered in which UART_1_GetRxFifoStatus() is used to get the status of the UART RX FIFO so a test can be made for received chars. If there is data, the character is grabbed with UART_1_Get() and put in rxData. If rxData is non-zero then it's passed to UART_1_Put() to output the character and UART_1_ClearRxFifoStatus() clears the read buffer is.

ADC

This example uses a Scan_ADC component (Successive Approximation Register (SAR) ADC) connected with input INPUT_1 (P10.4), and two outputs, SCAN_COMPLETE (ADC eos) connected to user LED 1, and MEASURE_OK (ADC sdone) connected to user LED 2. In main_cm0p.c the ADC is initialised with ADC_1_Start(), then in the main loop the ADC conversion process is started with ADC_1_StartConvert(), a 50mS delay is invoked with Cy_SysLib_Delay(), and then it gets the ADC value from channel 0 using ADC_1_GetResult16() and stores in variable test. It then waits another 50mS, converts test to volts using ADC_1_CountsTo_Volts() and stores the result in test2. After another 50mS delay, then ADC_1_StopConvert() is called to halt ADC conversion, another 50mS wait, and then the process repeats. Although not used there are other useful functions, such as ADC_1_CountsTo_mVolts() which give you millivolts, and ADC_1_CountsTo_uVolts()  microvolts.

Although the value stored in test is converted to volts and stored in test2, it is not displayed in any way to the user. Unfortunately we can't output the test2 value to a debug console as that isn't supported by PSoC Creator, but we could output it over UART, or to an LCD, etc. Alternatively, we can look at the variable value using debug and optionally a breakpoint. There weren't detailed instructions with the example but what I did to test was connect a variable resistor (example, 100K) between 3.3V and GND, with the wiper connected to P10.4 (these pins are available on the mikroBUS 1 connector). The ADC component is actually set to 5.5V range but only a few GPIO pins support greater than 3.6V (port 1 pins), which is not used in the example, so best to keep to a limit of 3.3V. Also, connect a voltmeter between the wiper connection and GND so that the voltage readings can be confirmed.

To try out the example using debug, start debugging (Debug->Debug) and you will see an arrow indicating the current position in the program, start of main(), as below:

To move through the program you either select Debug->Step Over, F10, or click the shortcut, which will advance to the next line. You can hover your mouse over the test or test2 variables and the current value, address and type will be displayed - note that the variables get initialised to 0 even though the program doesn't explicitly do it. You can click on test (either occurrence), right-click and select 'Add Watch' and it will be added to the 'Watch 1' window, do the same for test2 variable also to watch them both (see image that follows). For both variables in 'Watch 1' change the Radix to decimal. Note that test2 is always a whole number.

Next, click on the last Cy_SysLib_Delay() in the for loop, right-click and select 'Insert Breakpoint', and then select Debug->Resume Execution (or F5 or click the shortcut icon). The program will then jump to the final Cy_SysLib_Delay(), and test and test2 variables will change in value, 780 and 1 in my case, with the volt reading at 1.172. Select 'Resume Execution' and likely test will change again (710 for me) even without the variable resistor being adjusted but the value should be close. Now adjust the variable resistor and do 'Resume Execution' again, noting test and test2 - in my case the volt meter reading was 2.021V, test=1257, test2=2. Turn the variable resistor to maximum to see the reading (don't forget 'Resume Execution'), which for me was 3.255V (as to be expected should be close to 3.3V), test=2049, test2=3. Turn the variable resistor to minimum and check the reading, I got volt meter reading of 0.1mV, and test=4, test2=0.

You may have noticed that the value of test2, being an integer, doesn't give us a precise voltage value since it's always a whole value, however, function ADC_1_CountsTo_Volts() returns float32_t so we can change test2 to be a float32_t and then we'll get the precision.

To continue execution uninterrupted, remove the breakpoint (Debug->Delete All Breakpoints or Ctrl+Shift+F9), and select 'Resume Execution'. Notice that neither user LED lights, it seems odd they were included. As you can see the test and test2 variables don't update in real time in the watch window, insert breakpoint as before and program will stop, allowing you to see the values again. To completely stop debugging select Debug->Stop Debugging or Shift+F5 or the shortcut icon.

I2C - EPROM CLICK

The example uses an EPROM CLICK board, such as this one:

https://www.mikroe.com/eeprom-click

But even if you don't have a suitable add-on board, which was the case for me, it wasn't difficult to connect up a different EPROM board, a Waveshare AT24/FM24 EEPROM board from an FPGA kit I own (the chip is an FM24CL16 FRAM, compatible with standard EEPROM). It was just a simple matter of connecting up as follows:

EEPROM pin Clicker 2 pin

VCC 3.3V

GND GND

SDA P10.1 (SDA)

SCL P10.0 (SCL)

The example uses two of the on board LEDs and a UART to USB can be connected using the Clicker 2's TX pin (P0.3) and GND. Using PuTTY or similar software you will see initially 'UART started.', followed by 'mikroE' one character at a time, which is what gets written to the EEPROM and then read back to check it's the same, and will repeat continually. If there are any problems reading back the data from the attached EEPROM, both of the Clicker 2 on board LEDs will flash and no further attempt will be made to access the EEPROM.

According to the schematic, LED2 is supposed to turn on if the data read back is same as what was written, however, function eeprom_write_read() in main_cm0p.c turns on user LED 2 if there is an I2C access error. The problem is, after the loop of reading and writing it checks if the data read back was different to what was written, which would mean cnt had been set to 1, and then blinks the LEDs if so. If there was an error talking to the EEPROM then likely the data would be different and so it seems reductant to turn on the LED when it's going to be flashed in a bit over a second (the loop has ten iterations, delay of 100mS).

Note that _EEPROM_ADDRESS, which has value of hex 50, is the I2C address, and may need changing for your particular EEPROM/FRAM chip.

I didn't try the 'SPI - SRAM CLICK' example since it require a click board I don't have nor a suitable board/chip I could attach.

As well as the examples that can be downloaded there are also a number of examples built into PSoC Creator, accessed by 'File->Code Example...'. You can filter by device family - for Clicker 2 select 'PSoC 63' from the the 'Device family' drop-down. You can then type in the 'Filter by:' box a project name or part of. Clicking on one of the results lets you view information about the project in the Documentation pane and you can click the 'Sample Code' tab for sample source code. I went with:

CE219521_PSoC_6_MCU_GPIO_Interrupt

This example demonstrates how to configure a GPIO to generate an interrupt using PSoC 6 MCU. The example also shows how the GPIO interrupt can be used to wake the CPU from the Deep Sleep low-power mode.

To install the project (or any others) click the earth icon to the left of the project name. Note that after a project's installed it no longer appears in the Code example window, the actual project appears to be placed in the Projects location folder, which you can view the location by going to 'Tools->Options...'.

Another way to load example is to start a new project (File->New->Project...), select Target device, click Next button, click 'Code example', filter and select the code example, click the Next button, Select target IDE(s) if necessary (I left the drop-downs as 'Disable'), Click the Next button, choose the Create Project options as necessary, and click the Finish button. 

A handy feature is that, as well as creating the project it will open up the documentation for the code example, which is also added to the project as a PDF. The PDF may be a different development board than yours so keep that in mind that there will be some differences even though the MCU is the same as what was selected.

Resources

PSoC 4 – Using GPIO Pins

https://www.sjsu.edu/people/burford.furman/docs/me190/Using%20GPIO%20Pins%20PSoC%204%20-%20AN86439.pdf

Tips

PSoC Creator, Pins: selecting the Lock option prevents the pin from being reassigned by PSoC Creator.

PSoC Creator: Build->Generate Application generates the necessary API functions for the components.

All content of this and related pages is copyright (c) James S. 2023