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.
Table of contents
- 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 (this article)
- Review of Onboard Programmer and Debugger
- Review of Development Software
- Review of Documentation
- Project 1 - Serial Interfaces
- Project 2 - Simple Cloud Application
- Project 3 - FRAM
- Project 4 - CapSense and Bluetooth
- Project 5 - Dual Core Application
- Project 6 - Profiler
- Summary and Score
Review of Onboard Peripherals
This part of review is designed to review other onboard peripherals. Because most of them (like LEDs, buttons and expansion header) was also reviewed in chapter “Review of development board” I will describe only advanced onboard peripherals here. They are serial memories and capacitive touch control.
FRAM and FLASH
Development board contains two memories connected to MCU using shared bus. It is FLASH and FRAM. They have similar interface but have different properties which makes them usable in different use cases. Both are persistent which means that if write operation was successful They will store written data even if power loss occurs. Both memories should be used to store application data (for example data like logs, measured data and much more) or executable code. Mostly I will mention FRAM because it is more interesting. FLASH is also more known so I will describe it less. All mentioned sizes are in Byte units. This may be confusing because sometimes vendor uses bits instead. One Byte is 8 bits. This means that memory with capacity of 64 Mib (1 mebi-bit is 1024*1024 bits) is the same as 8 MiB (1 mebi-byte = is 1024*1024 bytes) but in marketing prospects 64 looks (eight time) better than 8.
FRAM is persistent memory but have some better properties than other persistent memories like FLASH or EEPROM. You probably know that one disadvantage of FLASHes and EEPROMs is that you cannot overwrite them as many as you want. Their lifespan is usually limited to about between 100 000 and 1 000 000 writes. For example, if you overwrite whole 8MiB Flash every minute in your embedded application, you must not expect that your flash survives for more than approximately 2 years when running 24 hours every day. In opposition RAM you can overwrite as much as you want but it has different disadvantage – it is not persistent. FRAM is quit new type of memory and it combines benefits of FLASHes and SRAMs. You can overwrite it as much as you want, and it is persistent. Writes count is theoretically limited but it is very hard to exhaust it. For example, If you overwrite whole 8MiB FRAM every second (not a minute as in previous example with FLASH) you can run this application safely for 3 million years (ok, at least theoretically). For now FRAM looks like that everyone can replace all RAMs and FLASHes with FRAM but there are few disadvantages. First one is price and second one is capacity. The FRAMs are more expensive than FLASHs and SRAMs and are offered only with low capacities. For example, 64MiB FLASH which is used on reviewed development board (S25FL512SAGMFI010) is at Cypress webpage priced as $9.02 and 0.5MiB FRAM (128x lower capacity) is at Cypress webpage priced as $27.38 (3x higher price). But it has beautiful properties, is faster and could be overwritten as much as you need.
Both FLASH and FRAM is connected to MCU using SPI in a little upgraded variant of SPI. It uses 4 bidirectional data lines instead of 2 unidirectional data lines but can be configured to work in standard SPI mode. This upgraded SPI is referred as Quad SPI or QSPI even if the S (serial) in name does not make sense because QSPI is not serial (it is partially parallel) in opposition to standard SPI. PSoC 6 has dedicated QSPI interface which can drive up to 4 slave selects so you can connect up to 4 memories (they can differ in either type or capacity). Reviewed development board has two memories connected to it. The peripheral for driving QSPI is named SMIF (Serial Memory InterFace) and while it could by theoretically used (hacked) to drive normal SPI devices It is designed to drive memories. It can operate in mode when you are designing transfers manually and the second mode of operation is that peripheral maps the content of the external memory (like FRAM) to the normal address space of ARM core. In this mode you can read content of external memory in the same way as you work with normal variable stored in RAM in your C program. Usage of peripheral and memory is shown in my project 3.
Both memories currently come from Cypress. Flash is originally from Spansion but Spansion was merged into Cypress. FRAM is also from Cypress. Control interface and instruction codes matches the commands of most currently used memories. You can migrate between non-Cypress and Cypress without any further issues. The Cypress Flash have some advanced features like support for automatic correction of bit errors which may improve overall lifespan of device.
Flash can run at 133 MHz rate under some circumstances. If you run at 50 MHz, you do not need worry about anything. At 50 MHz you can do whatever operation you want on whatever power voltage you want. If you want to run faster, you need to consider some limitations mentioned in datasheet. MCU itself supports only frequencies up to 80 MHz for QSPI interface.
Fram have less limitations on clock frequency because technology enables it, but you have to setup some wait states when you want run at higher speeds. Interesting is that wait states apply only for reads, not a write. Writes are probably internally easier than reads. If you are running at 50 MHz in QPI mode you need to setup 3 dummy cycles.
Because of support for lot of SPI/DPI/QPI modes, reading datasheet is quite complicated. Except SPI mode there are DPI (which transmits 2bits in the same direction in one clock), QPI (which transmits 4bits in the same direction in one clock) and DDR variant of these modes that samples and emits data at both edges of clock (normally sampling is done only on rising edge). Another thing to consider in case when you want to integrate memory manually is that some commands expect that command, address or data are transferred in different mode. For example, command code of QIOR (Quad I/O Read) is emitted using only one line, but address, mode and data are emitted using all 4 lines.
XIP
PSoC support XIP mode. It has two meanings. The first meaning is that content of external memory is memory mapped into ARM address space. If you declare pointer with address pointing to that space and attempts to dereference that pointer, processor will internally issue a transaction with configured read command against the external memory and returns the data received from the external memory. You may think that for writes it works in the same way, but this is not true. I have checked what about competitors (I checked some STM32s, NXP KL8x and some SAM from Microchip) and anyone does not support writes to external memory. Cypress have implemented the writes only partially. Write does not cause a bus error in ARM core (as for example STM32 does) and it will issue correct write command to the memory but there is some little detail which make it unusable. Probably all current serial memories (not matter If it is FLASH or FRAM) require issue write enable command before write operation and optionally it is recommended to check status after write to check that all data was successfully written. SMIF cannot issue that write enable command before. Cypress sadly stated that writes are unusable in TRM.
I think Cypress is on the good way to implement it with support for writes because peripheral theoretically supports it now. Their design requires enabling user to define more complex command sequences. Currently you can configure only one command which is issued at read (and it is sufficient for read) and only one command for write operation (it is not sufficient, because you need multiple commands to write data). Other vendors usually designed they peripheral to do not support writes at all. From some perspective of view, it makes sense. If you consider only FLASHes (no FRAMs) the enabling write operation may cause that lot of users destroy their flashes when they do not realize how quicky they overwrite memory and exhaust whole amount of available write cycles. Second good reason to do not implementing support of write is that FLASHes needs to erase memory before write. They cannot erase every single byte but when erase is issued, they erase whole row (or bigger block of memory) so If user needs to overwrite one byte it must backup block of memory, update one target byte, erase whole block and then write block with updated byte. This are reasons why anyone do not support memory mapped write to the external memory – because it does not make sense for flashes. But If you think about FRAM situation is completely different. Fram does not need to erase memory before write, you can overwrite every single byte without affecting sibling bytes, you do not need to check any flag after write because write is immediate, and you do not need to worry about write cycles decreasing lifespan of memory. I am little bit sad that engineers in Cypress did not realized that in time when they were designing SMIF peripheral. I think that for Cypress it completely makes sense support writes in XIP because they also offers FRAMs.
XIP is not used only for reading content from external memory directly using memory mapping. CPU core can also execute instructions stored in this memory. In this mode limitation for read access does not take effects because you usually do not modify program executable in runtime. It is good in situation when internal Flash is not large enough to hold your program. I am not sure how often engineers are affected by insufficient memory for storing their program because I have never reached this boundary. Usually when you realize this boundary It is when you use some heavy load library. The development board is used for evaluating IoT application. So, for example I can image scenario when someone need to integrate full heavy-load OpenSSL for some security reason (please note that Cypress have implemented their secure-sockets library, so you do not need to integrate OpenSSL for HTTPS or other SSL based protocol, but OpenSSL offers much more features than TLS/SSL which may want to use). In that case using XIP for executing code make totally sense. Let’s compare it from the memory size availability. MCU used on the board has 2 MiB of Flash memory available for storing code. It is one of the most advanced MCU in PSoC family and subfamily. So, you should not expect that you will easily find a model with higher capacity. In opposition external flash used on board has capacity of 64 MiB of capacity which is 32x more and you can easily find 128 MiB model (also from Cypress) which would be 64x more than internal flash and 128 MiB is enough to store almost anything nowadays.
The second meaning of XIP is that normally every operation requires issuing command code, but repeatedly issuing the same command code is waste of time. So, memories implemented XIP mode which enables skipping issuing the same command multiple time when XIP mode is enabled. It expect that the command is the same as the previous one when XIP mode is enables. Memory mapped (XIP) mode of SMIF block implemented in PSoC 6 can do that.
Development tools
Cypress has developed beautiful environment to generate configuration files for serial-flash library as part of ModusToolbox. In the tool you choose what memory is connected to the main MCU and it will create file with structures that are used by serial-flash and PDL library to create transactions using SMIF module of PSoC against the connected memory. The main information stored in generated structure is operation codes for commands. It is very easy to use this tool. Tool contains lot of predefined memories including memories which does not come from Cypress but are commonly used in industry (like flashes from Winbond for example). There is additional library to use external memories. It is named serial-flash. So, you can control external memory (SMIF block of PSoC) using 3 libraries – PDL, HAL a serial-flash. In this case of driving SMIF block directly by PDL, you will use it at very low-level but you are able to use all of his features. Structures generated by GUI utility matches the structures required by PDL. Second option is to use HAL but, in this case, you will need to redefine lots of things because HAL functions expect information about commands in its own structures. Except defining structures manually usage of HAL library is easy. The third option is to use serial-flash library. This library has limited number of options and is designed to match architecture of flash memories and accepts structures generated by tool. It is very easy and straightforward to use it. As part of review there are project 3 which shows how to use FRAM using all HAL and serial-flash.
Capacitive buttons and slider
The other onboard peripheral which requires more detailed look is capacitive touch control. There are two capacitive buttons and one horizontal slider. I have no previous experiences with any capacitive sensing technologies so my review of that will be only very brief. I have done one project (project 4) which shows how to use capacitive slider. The technology is very complex and contains a lot of configurable parameters. Some parameters must be tuned. Because of provided libraries and examples it is quite easy to integrate capsense into your application. I was surprised how accurate it is. First time I thought that when slider is constructed by 5 cells, I can determine only 5 logic values and decode gesture from it. But it was not a correct thought. When you touch one slider cell it does make capacitance difference only at that one cell, but it also makes some capacitance on siblings. If you touch place between two cells it makes similar measurable capacitance change on both cells. Then you can determine finger location from ration of values measured at sibling cells. Efficiently you get much advanced resolution than 5 logic values (as I expected when I was not experienced enough). Measurement of capacitance, calibration and calculation of finger location is hidden to you by very advanced library provided by Cypress.
As I mentioned before some parameters should be tuned. As part of ModusToolbox there are two utilities. One of them is using to tuning. It shows values measured by capsense in realtime at charts and shows overall view of touchable widgets, which buttons are pressed and where is finger placed at slider. Internally it works using USB-to-I2C bridge mentioned in chapter “Review of programmer and debugger”. It is also example of usage of EZ mode of Serial Communication Block for I2C.
Capsense is documented very well. They are dedicated document to that technology because Cypress uses it in multiple PSoC MCU series, and it is also used in dedicated capsense controllers. These documents describe with great illustrative images all details how that technology works and mention lot of good practices how to design custom PCB featuring these sensitive widgets.
Overall, I like it. It is more accurate than I expected. Works seamlessly. And it is easy to use with presented software.
Please note that I am not very experienced in this area, so there may be some weaknesses, but I did not find any of them.
