PSoC 6 Pioneer Kit Roadtest - Review of Development Software

23 Dec 2020

This post is part of my Roadtest Review of Cypress PSoC 62S2 Wi-Fi & BT5.0 Pioneer Dev Kit - Review. My review is splitted into multiple reviews and tutorials. Main page of review contains brief description of every chapter. Some projects are implemented in multiple variants. Main page of review contains brief description about every chapter, project and variants and contains some reccomendations for reading.

Intruction, Table of Contents, Overview of Table of Contets
Review of Development Board
Review of Microcontroller
Review of Wi-FI and BT Module
Review of Onboard Peripherals
Review of Onboard Programmer and Debugger
Review of Development Software (this article)
Review of Documentation
Project 1 - Serial Interfaces

Project 2 - Simple Cloud Application
- Project done using AWS Service
- Project done using Azure services

Review of Development Software

Development environment

At the beginning I started by researching which development environment can I use for developing. Very quickly I found on Cypress website that there are two development environments – ModusToolbox and PSoC Creator. For new PSoC 6 applications it is recommended to use ModusToolbox. At the beginning of roadtesting ModusToolbox supported only PSoC6. Later Cypress released support for PSoC 4. Other PSoC families (1, 3, 5LP) are not supported. ModusToolbox is set of utilities and eclipse-based IDE. Some of utilities you can find at screenshots in project tutorials.

ModusToolbox IDE

IDE is eclipse based but most of eclipse features are unused. Cypress do not exhaust features provided by eclipse. Most of features are implemented in way that eclipse support some autodetection or support that feature naturally. Good examples is code completion. When you create any project the code completion does not work. You must compile your project. Makefile script emits executed compiler commands to console output and eclipse environment parses them. Based on that output eclipse get information what are included directories and starts completing code correctly. This is standard feature of eclipse for some specific cases and lazy integrators. It sounds good but it is completely unreliable. In single core application It is not a big problem but when you are developing dual core app, code completions will work very randomly because of compilation chain of multiple projects. Eclipse needs to know include directories for reliable code completion. Almost all eclipse-based IDEs preconfigure that directories inside some internal eclipse configuration and do not rely on autodetection like Cypress does. Cypress also do not integrate any features you may know from other eclipse-based IDEs like STM32CubeIDE. For example, I often use SFR window when debugging. It shows registers grouped by peripherals and enables you to simply debug and troubleshoot state of peripheral. Cypress of course do not provide any registers definition, so this window shows nothing. Also forget to some advanced plugins like hard fault analyzer. When you get hard fault, environment is configured to store content of related registers to variables and you need to determine cause manually by analyzing that values. This document will help you: https://developer.arm.com/documentation/dui0552/a/cortex-m3-peripherals/system-control-block/configurable-fault-status-register. IDE don’t help you. Similarly, if you want to migrate to another MCU, you cannot just switch MCU in project settings. You must do that by external utility. Cypress did not provide any list of MCUs to eclipse, so dropdown is empty.

Dual core development is designed by having separated project for CM0 (Cortex-M0) and CM4 (Cortex-M4). CM4 project depends on CM0 project. CM4 project takes compiled binary from CM0 project and include it as part of final image by linker script. If you run CM0 project, final binary uploaded to MCU does not contain any CM4 code. If you run CM4 project, it contains code for both CM0 and CM4 cores. IDE supports debugging of only one core at once. Due to bug in IDE you cannot debug CM0 when you deploy CM4 project (CM4 project contains code built for both cores, but only code for C4 is debugable). I created issue on github (https://github.com/cypresssemiconductorco/mtb-example-psoc6-dual-cpu-empty-app/issues/1) about it. Some Cypress developer confirm that this is bug and created ticket in their internal system. Issue was not efficiently resolved before roadtest deadline.

Except described strange parts, there are some good parts. Because Cypress fully support KitProg in OpenOCD, debugging (of one core) is easy and reliable. Their own external utility for creating project is also good.

ModusToolbox utilities

ModusToolbox is not just an eclipse-based IDE. It contains lot of tools significantly reducing amount of work by generating code. In my tutorials you can see GUI utilities for generating memory configuration, Bluetooth structures, integrating libraries to project, generating capsense configuration, tuning capsense or just configuring clock system and other parts of MCU system. As expected, utilities are not hardwired in eclipse-based IDE (nothing is hardwired to IDE) and you can use them as independent executables. Utilities usually store their configuration from GUI in XML files and exports generated source code. Generated source code can be used within libraries provided by Cypress. Generation of source code is also triggered in Makefile. These utilities in combination with libraries saved me a lot of time. Utilities are good, easy to use and I like them. I think the concept of multiple lightweight independent utilities is better than whopping wizard in STM32CubeIDE, that requires to download half of all internet before run. Even on the one of the most performant CPU on market it takes tens of seconds to load that tool. And finally when you accidently resize its window you must own two RTX 3090 Ti in SLI to rerender the screen. Cypress do it differently and much better, I think.

While IDE itself is pain, these utilities compensates that. I think the ModusToolbox is new and they will improve it later. For now, you can consider using different IDE. Because tools and Makefile are completely independent, you can easily configure Visual Studio Code or another environment for developing and debugging unless they improve their eclipse-based IDE. In fact, documentation for ModusToolbox admit that and provides information how to do it.

ModusToolbox environment

ModusToolbox is not designed to only develop application for PSoC MCU. It also consists of lots libraries which you can easily integrate into your project. For example, integrating Wi-Fi support is very easy. It takes only few clicks. It looks like ModusToolbox replace separated tools PSoC Creator and WICED framework (WICED is used for developing IoT application, but I did not tried it) into one uniform development environment. This approach is good, and I like it.

MBED Support

Development board is supported by MBED. If you are familiar with this environment, you can use that. Board name search as CY8CKIT-062S2-43012, there are also some boards with Pioneer and BLE in name, but they are different boards. Page https://os.mbed.com/platforms/CY8CKIT-062S2-43012/ says Access Denied but in fact I successfully added it to list of My Hardware at MBED portal. If MBED Studio do not detect your board check that you have switched KitProg3 mode to DAPLink using MODE button (Kitprog3 Status led must slowly flash). I tried several examples using this environment. It is very huge and slow. It requires 1GB on disk for that system (final compiled binary is smaller than 2 MiB after compilation to fit internal flash). First compilation is very slow. I was unable to deploy code on Windows, but I am also unable to deploy program to STM32 on Windows also. On Linux I was able to deploy code but was unable to debug.

Cypress made port for MBED backed on their PDL and HAL libraries. If you like that environment, you can use that with this board.

FreeRTOS, lwIP, MbedTLS support

In ModusToolbox there are lot of templates with FreeRTOS support. Cypress has their own library named rtos-abstraction supporting another RTOSes but I used only FreeRTOS. FreeRTOS is fully ported. You can use it out of box. Similarly, lwIP is fully ported with WiFI libraries. Wi-FI usually requires using FreeRTOS. When you integrate lwIP using Library Manager you can start using normal socket API. There are also integrated MbedTLS for enabling encrypted IoT SSL/TLS connections. For simplifying access to both lwIP sockets and Mbed TLS sockets, Cypress provided secure-sockets library with functions starting with cy_ prefix in name. You can use that library for getting uniform socket interface to both libraries.

PDL

PDL (Peripheral driver library) is library that can control peripherals of MCU in natural way. If you are familiar with STM32 you may know StdPeriph library. They are similar libraries with similar concepts. You can control almost every feature of every peripheral by this library. PDL is fully open source. It is available at github https://github.com/cypresssemiconductorco/psoc6pdl/ and Doxygen documentation is available online at https://cypresssemiconductorco.github.io/psoc6pdl/pdl_api_reference_manual/html/index.html. Cypress implemented PDL for all peripherals without exception. For example, ST omitted some advanced peripherals in StdPeriph (for example omitted peripherals are USB_OTG and Ethernet).

PDL is designed well and has fantastic documentation. PDL also follows MISRA rules to achieve some level of code quality. Library sometimes violate some rule but in documentation is description with reason why the rule is violated.

Most functions are designed to return cy_rslt_t type. It is typedef to some kind of int. 0 means success (it is CY_RSLT_SUCCESS macro). Other errors are composited values with bit meanings. Because IDE has no support for decoding cy_rslt_t it is hard to determine error cause. But otherwise, cy_rslt_t is fine. If you are familiar with HRESULT in Win32 API, cy_rslt_t is the same concept. Uniform cy_rslt_t concept across whole library is good and makes error handling very easy. For simplifying error handling there is often CY_ASSERT macro used. Often it is used in following form

if (result != CY_RSLT_SUCCESS) {  
    CY_ASSERT(0);  
}

But it should be better used in form

CY_ASSERT(result == CY_RSLT_SUCCESS);

Internally it is implemented as condition and software breakpoint instruction. This is good when debugging because it immediately triggers the debugger when some function fails. In opposition this is not a good in release code because it halts MCU core. After time It became my favorite error checking mechanism and saved me a lot of time.

To summarize: PDL is good library. If you have some experiences with MCU development and can imagine how MCU and peripherals works internally it is easy to understand and use it. But usually, it is easier to use HAL library.

HAL

HAL (Hardware abstraction layer) is library that is designed to be easily used without worrying much about peripheral internals. It significantly reduces amount of code written for achieving common tasks. It does not expose all features of all peripherals but most tasks you can easily resolve with this library. Its interface is also more user friendly. If you can use that library, use them. Library is also available at GitHub and has similarly great documentation as PDL. HAL is internally implemented using PDL.

There is one restriction about HAL. HAL cannot be used on CM0 core. I have no idea what the reason for that restriction is.

Other Libraries

Cypress also provide lot of libraries for peripherals presented on their development boards. For example, I showed serial-flash library in one of my projects. Similarly It is also library for controlling Wi-Fi + BLE module and library for capsense. There is also library for driving rgb led using PWM. Using that library, you do not need to know what PWM is.

All that libraries share similar concepts to PDL and HAL. All of them are open source. All of them are available at GitHub and finally, all of them have good documentation with good overview and getting started section at main page.

All this libraries results into very good environment. You can simply integrate all components for making low power IoT application just in clicks. Unless you need to use some obscure third-party (or own) library, you do not need to write any line of code for porting any common library.

To summarize: eclipse-based IDE is bad, bundled utilities are good, libraries are good, documentation for all of that is good.