Cypress PSoC® 6 BLE Pioneer Kit (CY8CKIT-062-BLE) - Review

Table of contents

RoadTest: Cypress PSoC® 6 BLE Pioneer Kit (CY8CKIT-062-BLE)

Author: hlipka

Creation date: 13 Feb 2018

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: The PSoC5 and 4 series

What were the biggest problems encountered?: Only having the PDL API makes code migration difficult, and I encountered some bugs.

Detailed Review:

Overview

I just looked it up - my journey with the Cyress PSoC chips started a little bit more than 7 years ago. Back then the PSoC5 series was just released and Cypress sponsored a design challenge where I participated. Since then, the family has grown quite a bit: the PSoC5LP was released, then the PSoC4 family started and got extended with BLE capabilities later on.

So I was very intrigued when the PSoC6 road test was started as I wanted to have a deeper look at it.

Introduction - whats a PSoC?

PSoC stands for 'Programmable System on a Chip'. That means that, in contrast to a microcontroller, it comes with additional components on board (this is the 'system' part). And these components can be programmed and combined quite freely to create whatever functionality is needed. And when you don't need them, they do not take valuable space in the chip.

Cypress illustrates this nicely with this graphics

and when you look at the internal routing schematic

you might get an idea how freely all these components can be combined. Add an IDE to that which allows you to do all of that with the simplicity of drawing a schematic, and you get the complete PSoC eco system.

I find PSoCs to be the perfect chip for prototyping. Because of their capabilities you can pack a whole lot of functionality in the chip instead of wiring it on a breadboard. And re-wiring in the schematic editor is much easier and faster.

PSoC6 capabilities and differences

The most striking difference between the PSoC6 and its siblings are its two cores. The PSoC6 comes with a Cortex-M4 core (running with up to 150MHz) and an additional Cortex-M0+ (up to 100MHz). Even when looking at the raw clock speed of a single core its much faster now - until now the fastest PSoC is a 80MHz Cortex-M3 (in the PSoC5LP series).

When looking at the available system components and peripherals, the PSoC6 looks like a mixture of the PSoC5LP (with its analog capabilites and the digital UDBs) and the PSoC4 BLE series. From the latter it has inherited the more capable fixed-function TCPWM and SCB blocks (and it increased the number to 32 and 9, respective). And from the PSoC5LP come the programmable analog blocks (OpAmps, Comparators, ADC+DAC, Muxes) and the 12 UDBs. The latter ones are used to provide additional functions as needed, such as logic elements (logic gates, flip-flops of all kinds, or multiplexers), PRS generators, lookup tables, or additional communication protocols (such as S/PDIF or LIN). Unfortunately not all UDB-based components that were available in the PSoC5LP series are available for the PSoC6 yet (e.g. the UDB-based counters).

But there are even more components available:

• the Quad-SPI interface to access external serial flash chips, which can be used to actually run code from external serial memory
• the capacitive sense block, with its extensive configuration dialog to set up all your interface elements in an easy way
• audio system with I2S interface and two PDM channels
• an energy profiler to measure current consumption of different peripherals and your code over time - unfortunately it must be configured in code at the moment
• multiple DMA channels, capable of running in different modes
• the BLE 5 sub-system

and probably some more that I just forgot to list here.

Development environment

As already said, the PSoC eco system comes with its own IDE, called PSoC Creator. To work with PSoC6, you need to use a beta version of Creator 4.2 (instead of the current 4.1 production release). A new version of that appeared early January, and my version from last year told me I should update. Its worth noting that different versions of PSoC Creator are installed in parallel, so you can still use the 4.1 release version for other PSoC chips if you want to.

The major difference between PSoC Creator and other IDEs for MCU development is that in a PSoC project you don't start with the code, but with a schematic. On this schematic you place the components you want to use, and connect them with the needed wires, creating glue logic if you need.

Take the above schematic, which is a frequency counter. It does not use the usual gate-driver counter, but instead works as a reciprocal counter. There are two counter: one counting a reference clock, the other one counting the input signal. Both are started at the same time (falling edge at the input), and are stopped at the same time too (first falling edge at the input signal after the reference counter has overflowed once).

For that circuit you need some D-FlipFlops, and you need to be able to start and stop counters on their signals. In PSoC, all of this can be done inside of the chip itself (because it has some macro cells with flip-flops), and PSoC Creator allows to easily define the needed wiring. On the right side you can see the component selector, which a selection of digital components to be used.

The drawback is that you actually need this tool to work effectively with a PSoC chip. Cypress has added export to other tool chains several version ago, so you can do the actual firmware development with other tool chains if you want to. But for the initial setup you still will PSoC Creator. With the introduction of the PDL (peripheral driver library) in Creator 4.2 this gets better, see my comments below.

One nice feature of Creator is its ability to search for code example projects. Not only can you search for examples for the chips you are using, but you also search for examples for certain features or components. So if you want to know how to use e.g. a TCPWM component, you find sample code and documentation within seconds. This helps especially when starting with new components or chips - and I made heavy use of that for this road test (e.g. for finding out how to communicate between the two cores).

Note: when you are looking for the default firmware - this is CE220167. The example project for the E-ink display is CE218133.

The kit

So lets have a look at the actual PSoC6-BLE kit.

You get the actual Pioneer board, the E-Paper display shield, a BLE 4.2 debug dongle (so you can debug the BLE services on your PC) and a USB-C cable.

Since the introduction of the original PSoC4 pioneer board Cypress has standardized on a common form factor, and is also using a common packaging for all development kits. I like that - the boards all work similar, they store in the same boxes, and you generally find your way around with them easily. So there are no big surprises here, although the board is a little bit larger than the other Pioneer boards, due to the CapSense area:

The PSoC6 Pioneer kit is the largest of the Pioneer kits, because it has a larger area for the capacitive sensors. More interesting is the comparison with the original PSoC5 kit: the -050 kit is not that much larger, but provides quite a number of additional feature (it breaks out even more signals, has a bread board area and a real serial port). On the other hand the Pioneer kits take up less space on the work bench, so it would be nice to a PSoC5LP Pioneer kit in the future...

The board

A big plus is that the Cypress boards always come with rubber feet, so you can use them on your workbench without fear that some might short out on the bottom.

What I like on the board is that the silk screen on the top labels all important components with their functionality, and to which port of the PSoC6 they are connected. This makes prototyping quite easy. The bottom silk screen provides additional references (e.g. about the connection between the PSoC6 and the on-board programmer). You don't need to look into a manual to see which component is connected to which port (with the exception of the on-board memory NOR flash memory chip, for which you need to look into the schematic).

The manual also list all the PSoC6 ports with their functionality, and especially shows which ports have a special use on the board (e.g. P6.0 and P6.1 on the Arduino headers are used for the I2C bridge connection to the on-board KitProg programmer). It would be really nice if these ports could get a marking on the silk-screen too. The leaflet that comes in the box also has a page outlining all components and the connectors, so you can use that as a small reference sheet.

When you use the board with the E-ink shield, be aware that some components (e.g. the KitProg LEDs and the user button) are hidden underneath the shield, so they are not easily accessible.

Speaking of shields: all of the Pioneer kits are compatible with Arduino shields, so you can choose from a wide range of shields to use. For the PSoC6 board you need to be careful though since it does run with 3.3V only (down to 1.8V in fact), so it cannot be used with 5V shields.

The shield

The kit comes with an E-paper shield (part number is CY8CKIT-028). Nice touch: its already pre-loaded with instructions on it when you open up the box. The display itself is a Pervasive: E-ink 2.71 inch epaper display, presumable the version with normal temperature range. There is no component for this display in Creator, but a sample project is available (CE218133) from which you can copy the needed code.

There is also a motion sensor (a BMI160 6DOF sensor for acceleration and rotation) and a PDM microphone (for which I could not find a part number, as the schematic for that shield seems not to be available for now). It might have been better to place these on the main PCB instead of the shield. That way the can be used independently from the shield, and the E-Paper display is not fast enough to show any real-time data from these devices.

The sample project shows how to use the display, and the CapSense slider and buttons. The display is used to show information and documentation about the PSoC6 and the kit. Its nice to use, but since the refresh rate on these kind of displays is quite slow it feels a little bit sluggish to use. Instinctively I expect to use the CapSense slider to slide through the different pages of information, but its used as a gesture. So each swipe on the slider moves one page forward or backwards, instead of cycling through the different pages.

The demo app thats preloaded on the board is used to demo the Bluetooth Low Energy functionality. Once you connect your phone to the PSoC6 board from the CySmart demo app (which took several tries on my Nexus 5) you can look at the state of the CapSense slider and buttons, and you can control the RGB LED on the board.

When you use the Windows CySmart application, you can look up the definition of the actual BLE services and their attributes. Its possible to set values for the attributes (so you can control the RGB LED by writing hex values into the correct places), or see the values for the slider service change when touching it. This tool is a great help for debugging, and I have used it extensively in the past when working with the PSoC4BLE.

Programming a PSoC6

As already mentioned, development in a PSoC project does not start with a main() method, but with a schematic. As my test project I used a frequency counter. This is a project which I already implemented in a Xilinx CPLD , and used in a small PSoC introduction series. In the PSoC series I implemented a simple gate-time-driven frequency counter, but in the CPLD it was designed as a reciprocal frequency counter. Compared with the traditional design it has the advantage that the resolution is always constant, and is not reduced with lower frequencies. I thought it might be interesting to implement this in a PSoC since it has all the needed functionality integrated: several counters up to 32 bit, logic gates, D-flip-flops, and comparators.

The schematic

So this is the schematic I implemented:

It consists of three sheets:

• the actual frequency counter core
• an input comparator with trigger level (and source selection)
• display (a SPI master used for a Nokia 5110 display)

Since I had no 3.3V character LCD at hand, I used the Nokia display. I used a Nokia 5110 PSoC library from Github, but stripped it down to what I actually needed (e.g. no background image) and made it work on the SPI component from the PSoC6 (which has a different API, see below).

The input circuit is simple: for the analog path, a comparator is used whose threshold level is set by a DAC. Alternatively the digital multiplexer can be set to use a digital input which is using LVTTL threshold (set in the pin configuration). This allows higher frequency, at the loss of choosing the trigger level.

When you have pin components in your schematic (e.g. the input pins) they can be routed freely to any available pin on the chip. Some restrictions might apply, though (e.g. OpAmps have dedicated pins so they have minimal resistance), but normally one can define the pins so they are suited best for the PCB (or they can be easily re-routed when needed).

But the heart is the counter circuit. Its basic principle of operation is:

1. Control_Reg_Start is a software-controllable output (inside of the PSoC, not routed to any pin). A '1' pulse on its output resets all DFFs (the on the bottom left indirectly from the others) and reloads the counters.
2. After that, the output of the AND gate in the middle is still '0' because of the top-left DFF, and the counters are stopped
3. When Control_Reg_Start gets set '0' again, the first falling edge on the input signal triggers the top-left DFF, whose output goes to '1', and then the AND also goes to '1' and both counters start (they are configured to treat a rising edge on start as start signal)
4. InputCounter counts rising edges of the input signal, RefCounter counts rising edges of the reference frequency
5. When RefCounter overflows, the first DFF at its output goes to a '1', which enables the bottom left DFF
6. With the next falling edge of the input signal, this DFF goes now to '1', the AND goes to '0' again and the counters are stopped (since they are configured to treat a falling edge on their stop input as stop signal)
7. We can now calculate the input frequency as f=f_ref*count_input/(count_ref+period_ref) (we need to add the counter period to the reference counter since it overflowed once)
8. But when RefCounter overflows a second time before this falling edge at the input occurs, the input frequency is too low to be measured
9. And when InputCounter overflows before the RefCount, the input frequency is too high (higher than the reference frequency)

To react to these events I added the three ISR components which are connected to the respective signals from the DFFs. Since the counter components are not really free-running, they need a clock signal which is used to synchronize them into the rest of the system. This is the SyncClock component, which is 50MHz here (they are derived from the peripheral clock which in turn is the same as the clock speed of the M0+ core, which I set to its maximum of 100MHz).

To make it more interesting, I did split up the functionality between the two cores:

• the Cortex-M0+ controls all the hardware, handles the interrupts and reads the values from the counters
• the Cortex-M4 takes the counter values, calculates the measured frequency and updates the display

That way the counter is re-triggered as fast as possible. Also, the M4 core should be better suited to do floating-point math. But mainly my interest was in seeing how easy the two cores can communicate with each other.

The firmware

Defining the hardware worked us usual. The components looked a bit different from the PSoC5LP I mostly used before, but that was to be expected (each PSoC generation has its own capabilities). But writing the code was the moment where the real differences came into light.

Before, PSoC Creator would generate code for each of the components placed. This code consists of a set of functions, each prefixed with the component name. So for the schematic above, there would be functions RefCounter_GetCaptureValue() and InputCounter_GetCaptureValue(). These functions usually are quite high-level and allow to get required functionality quite easily.

But with Creator 4.2 and PSoC6 this changes. Only a _Start() function is generated, and for anything else generic functions from the PDL (Peripheral Driver Library) are provided. Each of these functions now take two references to the actual hardware as a parameter (one is a data structure holding all the runtime data, the other one identifies the actual hardware block). So the calls from above now look like Cy_TCPWM_Counter_GetCounter(RefCounter_HW, RefCounter_CNT_NUM).

So migrating any old project over to PSoC6 is, right now, a major project. I have read that there will be non-PDL components in the future for PSoC6, but until then all code needs to be re-written. In addition, I personally find this new code style more difficult to read (since it is much more verbose and more 'noisy').

On the other hand this makes it much easier for library writers, since they now can the the component as a parameter, instead of specifying hard-coded component names (inside of the called method names). The PDL also allows software-based configuration of the components. I think that this could make it easier to work on other operating systems, since its now possible to do less configuration in the schematic editor, replacing this with source code.

Programming and debugging

So after I got used to this new API style, and migrating my code to it its about time to program the PSoC. The Pioneer kits (as nearly all the new development boards from Cypress) comes with the KitProg2 onboard programmer and debugger. This works very well, and is also reasonable fast (at least I never noticed any slowdown when compared to using the MiniProg3. One functionality that can be very useful is that it can present itself as mass storage device. In that mode it programs *.hex files stored on it into the PSoC6 - this is useful when you use another operating system (other than Windows) for development.

What was new to me is that I needed to select one of the two cores when connecting PSoC Creator to the debugger (or before programming). This does not affect the programming itself - Creator will always upload the firmware for both cores. This selection is made for the debugging - its only possible to debug one core at a time (setting breakpoints and so on). I have not found this limiting, but it might be in future projects. OTOH one cannot set breakpoints for the hardware anyway, which means there are already parts of the solution that cannot be debugged easily (in a step-by-step manner).

When I tried to upload code for the first time, Creator warned me that I would need to update the firmware on the KitProg2. Interestingly it worked even without doing so, but I did the update nonetheless afterwards.

For debugging purposes, I added a 1kHz clock output, so I can test without needing to use the external signal generator. In this photo, this is the green wire on the bottom of the board:

Each of the digits for the frequency is significant - the resolution (in terms of digit) is constant, and depends only of the bit width of the counters. Below the frequency I show the values for both counter, and a running count of the measurements (which was helpful to see whether the cores actually communicate properly or not).

Multi-core programming

Having multiple core in one chips makes developing software for it a little bit different. For one, handling the source code needs to be different because it needs to be separated. PSoC Creator solves this by introducing virtual folders into the project structure - one for each core, and one for shared files (so its three overall). Even though the source and header files can be in one folder in the file system they can then be sorted into their respective folders.

For my project I had the code for inter-core-communication in two shared files, the Nokia display driver library added to the M4 core, and then one main file per core:

The code itself is quite small - it needs to start up the components, then the M0 core activates the M4 core, and then both run in their main loop doing their respective tasks. All the main work is done in hardware, and the cores could actually go to sleep during the measurements.

For inter-core communication there are some basic primitives available:

• its possible to define shared memory regions (or variables) - actually all memory can be shared, but the compiler normally reserves each core its own regions
• addresses of such shared variables can be send from one core to the other (so both look at the same place)
• semaphores are available to achieve locking

Using these the sample project (CE216795) builds a simple 'WriteSharedVar' - 'ReadSharedVar' function pair. I added this to my project, and used a common C struct to send the counter values from one core to the other (its easier to have just one shared variable containing both counter values, since they can be transferred atomically). This worked quite well, but I hope that such functions (and maybe some more advanced ones) are added to the standard library in the future.

Anything else

The board comes with so many features that I had not enough time to try them all. Main selling point for the PSoC6 is the integration of BLE in the chip. From my experiences with the Sudden Impact Design Challenge I already knew that this works quite well. The BLE component comes with a configuration dialog that allows to configure nearly all aspects of the BLE setup without touching any code. The CySmart PC application greatly helps in debugging since it allows direct interaction with the BLE device. And the documentation was, even back then, quite good (although BLE is a complex subject and it takes quite a while to fully understand it). Since then newer standards are supported, and the BLE API supports more profiles and services which makes development even easier.

Another major part of the board is the charging support for both USB-C devices and an external LiPo battery. For the former one needs a separate power supply to deliver enough power. For the battery this is not so clear, but from the schematic it seems as if it could be charged also from the regular USB connection. This is something I need to test further, since it can be quite helpful.

User interfaces are always an important topic, and Cypress as, for quite a while now, an answer in the form of their CapSense capacitive interface elements. I cannot really compare them to other manufactures implementation of this concept, but from my experience they work quite well. And as you should know by now, configuration of them is a breeze.

Probably I have now forgotten to mention several nifty features and functionalities, but you can see that this board is quite versatile.

About the scoring

I made the scoring with the assumptions that a 5 means 'meets expectations'. Anything lower means I'm missing something.

The board itself earned a 5 because I think the board have been layed out better so that can access the buttons and LEDs for the KitProg even with a shield on top. I also don't see the point in mixing male and female headers. But I like all the information provided by the silk screen, so lets call it on par.

The specifications also get a 5 - the user guide contains anything thats needed, the schematics for the Pioneer kit are available, but the ones for the shield are a little bit hidden.

The demo software gets a 7 - I found examples for all areas I wanted to explore, and they are all well explained. Even though I know that Cypress produces very good documentation I was positively surprised given that the PSoC6 is still quite new (and Creator 4.2 is still beta).

Ease of use also gets a 7 - programming multiple cores was easier than I was expecting it to be (although there is room for improvement).

Support gets an 8 - I had several questions when working on my project, and they were answered in less than a day (and were actually already explained in the documentation...). Thats really nice.

Price-to-performance is a difficult question, since we don't pay for the road test items. But I think that 75$ is very reasonable - E-paper displays are still not cheap, and the Pioneer kit comes with quite a bunch of functionality on it. With about $6.5 the bare chip is not exactly cheap, but since it can replace quite a number of other chips as well on a much smaller area this also seems reasonable.

So in total that's a 38 out of 60 points - meaning it performed above my expectations. And since I know the PSoC chips for several years now my expectations are high to begin with.

Conclusion

So did I like the kit? Sure I do! I think it does a good job of showing the capabilities of the PSoC6, and the demo application installed by default works nicely for that. The provided peripherals look like a good choice - they are what gets probably used on a portable BLE device (maybe with the exception of the NOR flash - a F-RAM would be better here I think). The integrated power monitoring capability looks very promising to find out which peripherals take up the valuable battery power.

When I appear too critical that most likely it is because I hold Cypress to a high standard - from my experiences they usually deliver really good developer boards, and also provide anything you need to be successful with them. And with such high expectations its difficult to be positively surprised, but easy to find something to criticize.

My only gripe is that with the move to the PDL components the programming model changes quite a bit from earlier PSoC and Creator versions, and this makes migrating existing projects quite a big effort. I for myself hope that, with the final release of Creator 4.2, all the missing APIs and the UDB-based components are provided.

But when you want to experiment with BLE, the PSoC6 BLE Pioneer kit is a great way to start. I can only encourage you to try it.