PSoC6 devices have multiple types of protection units to control erroneous or unauthorized access to memory and peripheral registers.
We will be learning mostly about SMPU in this blog, but most of the things apply to the PPU as well. Irrespective of the type of protection unit you intend to use, they are defined by the same fundamental structure:
The address region is defined by:
Whenever you define any address region, you need to take care that the base address is aligned with the region size. For example, if you define the base address as 0x1002_0000 it is 128KB aligned, but not 256KB or higher byte aligned. This means that you can use 0x1002_0000 as the base address only if the region size you define is 128KB or lesser to be protected.
To calculate if a memory address is aligned with the region size, find out where the first bit is 1 from the LSB. For example, for base address 0x1002_0000 the binary value is:
0001 0000 0000 0010 0000 0000 0000 0000
The position of 1 here is at index 17 counting from 0 and the value of 2^17 is 128KB. So, it is 128KB aligned at max. It is also 64KB, 32KB, …. 2B aligned but max 128KB.
Specifying a value that is invalid causes the base address to automatically change according to the region size specified. For any device, the flash usually starts from 0x1000_0000. Check the Architecture TRM of the particular device for more information on the memory organization.
If the base address is defined as 0x1002_0000 (128KB aligned) and the region size is set as 512KB, then since the base address is not aligned, all the bits [0:18] will be ignored and only bits [19:31] will be taken into consideration. This means that the invalid region size causes the base address to be set as 0x1000_0000. Note that 0x1000_0000 is aligned with all region sizes max being 2^28 = 256MB aligned.
The region to protect is always a power of 2 in the range of [256B to 4GB]. Check Architecture TRM of your device for these range values.
Let’s say you want to protect the memory region between 0x1002_0000 to 0x1006_0000. How do you do it?
First, find out the memory alignment of the starting address.
0x1002_0000 is 128KB aligned. The region size between 0x1002_0000 to 0x1006_0000 is 0x40000 (256KB). Even though the region size to be protected is 256KB, you can only set the region size for the SMPU to be 128KB max to adhere to the alignment with the base address. So, you cannot use this address as the base address.
You need to select another base address such that:
This leaves us with one option. Using 0x1000_0000 as the base address and setting the region size as 512KB.
So, configure an SMPU with the base address as 0x1000_0000 and region size as 512KB. Now how do you protect just the region between 0x1002_0000 and 0x1006_0000?
The region size you define for an SMPU is divided into 8 equal sub-regions. In this case, 512/8 = 64KB sub-region. So, the 8 sub-regions will have the address mapping as shown:
The sub-regions 2 to 5 cover the regions that we intend to protect. So the sub-regions value 0xC3 (1100 0011) is chosen below where the value 1 in the bit means the region to be disabled or unprotected.
The SMPU structure cy_stc_smpu_cfg_t is used to configure the SMPU parameters. It will be defined as follows:
static const cy_stc_smpu_cfg_t flash_protect = {
.address = (uint32_t *) 0x10000000,
.regionSize = CY_PROT_SIZE_512KB,
.subregions = 0xC3,
.userPermission = CY_PROT_PERM_RX,
.privPermission = CY_PROT_PERM_RX,
.secure = false,
.pcMatch = false,
.pcMask = CY_PROT_PCMASK1
};
The .userpermission and .privpermission protection attributes implement a protection scheme to distinguish between read/write or execute access to a specified memory region by a user code or privileged code. The privilege code is typically the kernel code in an RTOS environment.
The .secure protection attribute distinguishes if accesses by a secure processor are enabled or not.
The same logic applies for PPU and MPU, it all depends on where the memory region belongs, and which protection unit will be the most suitable. You can use SMPU to protect peripheral memory spaces, it is not a problem, but PPU is available only for the protection of peripherals and could have been used instead.
Once the structure is defined you need to call the following PDL APIs:
Cy_Prot_ConfigSmpuSlaveStruct(PROT_SMPU_SMPU_STRUCT2, &flash_protect);
Cy_Prot_EnableSmpuSlaveStruct(PROT_SMPU_SMPU_STRUCT2);
The index of the structure highlighted above is used to define the priority of the SMPU. Here the priority is 2.
There are 15 SMPUs that you can use in PSoC6 to protect a memory region. In cases where you have two SMPUs protecting the same region, the priority is for the SMPU structure with the highest number. The highest SMPU priority is 15 and the lowest is 0.
Next, we need to configure the Protection Units and the Bus Masters. A protection unit is a hardware block that implements the protection scheme. Each protection unit has one or more protection structures associated with them. A protection structure is a group of registers which define a memory region (address and size) and a set of protection attributes that are to be applied to it.
Protection Context (PC) provides a more precise way of applying memory restrictions. A bus master with a Protection Context 0 can access any memory or register region no matter how the protection units are configured. PC=0 is a special case that allows any bus master to have full access to the entire memory space including registers.
The PC state works together with protection units (SMPU, PPU). Each of the protection units has a field called .pcMask which is used to specify which protection context can have access to the memory region.
There are six bus masters in PSoC6:
Their macros are available through the enum en_prot_master_t.
typedef enum
{
CPUSS_MS_ID_CM0 = 0,
CPUSS_MS_ID_CRYPTO = 1,
CPUSS_MS_ID_DW0 = 2,
CPUSS_MS_ID_DW1 = 3,
CPUSS_MS_ID_CM4 = 14,
CPUSS_MS_ID_TC = 15
} en_prot_master_t;
You can assign a particular PC using the API shown below where the CM0+ is assigned the PC 1.
Cy_Prot_ConfigBusMaster(CPUSS_MS_ID_CM0, false, false, CY_PROT_PCMASK1);
To activate the PC, you will need to call:
Cy_Prot_SetActivePC(CPUSS_MS_ID_CM0, CY_PROT_PC1);
Let’s say you have defined an SMPU memory region as follows:
static const cy_stc_smpu_cfg_t main_flash_prot_cfg_s = {
.address = (uint32_t *) 0x10000000,
.regionSize = CY_PROT_SIZE_512KB,
.subregions = 1,
.userPermission = CY_PROT_PERM_RX,
.privPermission = CY_PROT_PERM_RX,
.secure = false,
.pcMatch = false,
.pcMask = CY_PROT_PCMASK1 | CY_PROT_PCMASK2
};
All the values in the above snippets like CY_PROT_PERM_RX, CY_PROT_SIZE_512KB, etc. are macros that are already defined internally. You don't need to define them.
This memory region protected by the SMPU as defined above provides access to only bus masters that have the PC value of 1, 2, and 0. To understand this better, find the project “PSoC6_Memory_Protection.zip” attached with this blog. The project demonstrates how you can protect a memory region in the CM0p memory space from being accessed by CM4. The project details can be found in the ReadMe PDF file in the project folder.
See if you can relate your understanding with the project implementation!
Now here’s something interesting to know and try. Although it seems like we have protected the memory regions of CM0p from being accessed by CM4 in the project, we have not protected the PC Mask registers themselves. Any of the bus masters can change this and set their current PC mask value to whatever they want and have access to the required memory regions.
So, usually, you would set up all the memory protections and also protect the PC Mask registers while CM0p is still PC=0 and then switch the bus master to something other than PC=0. That way you have locked the door and thrown away the key
Stay tuned for the next blog that reveals how you can do this! For clues, use the Protection Units section in the PSoC6 Architecture TRM.
Show LessHello! 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!
Show LessAlexa Skills Demo on PSoC 6 Wi-Fi BT Prototyping Kit
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.
Hardware:
Software:
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 Speed | 100% 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 |
(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
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.
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).
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.
We need to create an IAM policy that provides the minimum required permissions for Alexa Skills to invoke an AWS Lambda function.
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.
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
…\mbed-os-example-aws-iot-client\subscriber\BUILD\CY8CPROTO_062_4343W\GCC_ARM.
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.
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
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:
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.
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!
Prerequisites:
Hardware – CY8CKIT-062-WIFI-BT/CY8CKIT-062-BLE/CY8CPROTO-063-BLE
Software/IDE – PSoC Creator 4.3 and PDL 3.1.1
Introduction:
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,
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:
Application 2:
Comparison of the two approaches:
Note:
Hello!
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:
Feel free to leave comments and ask questions, we appreciate the feedback!
Show LessWe are pleased to announce that PSoC 6 MCUs are supporting AliOS Things, an embedded RTOS for the IoT market!
AliOS Things is Alibaba's IoT version of AliOS Family, and is an embedded RTOS for the IoT market.
AliOS Things targets designing turnkey solutions for IoT infrastructures, with high-performance, simplicity, security, cloud integration, and rich components . Furthermore, it natively supports the connection between smart devices and the Alibaba Cloud system; therefore it can be widely applied in smart home, smart city, and next-generation travel.
Cypress’ PSoC 6 MCUs is supporting AliOS Things RTOS now, and designers can use PSoC 6 MCUs to design wireless systems to connect to the Alibaba Cloud for their IoT devices.
To find out more and get started, view the “Getting Started” Guide attached to this post and also visit AliOS-Things/platform/mcu/cy8c6347 at master · alibaba/AliOS-Things · GitHub .
In addition, we have AliOS Things support for our PSoC 4 MCUs. To find out more, check out this blog post.
Lastly, feel free to leave your comments and feedback, we appreciate that!
Show LessFreeRTOS 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!
Show LessHello,
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.
Feel free to leave comments and ask questions, we appreciate the feedback!
Show Less