Skip navigation


1 2 3 Previous Next


722 posts

[reprinted from PSoC Creator News and Information, author Pushek Madaan]


In September, 2016, we released our ultra-low-cost CY8CKIT-145-40XX PSoC 4000S CapSense PrototypingKit that enables CapSense-based user interface designs with Bluetooth connectivity. You can now buy this kit from the Cypress website or one of our channel partners.


CY8CKIT-145-40XX CapSense Prototyping Kit with Bluetooth Connectivity


PSoC 4000S CapSense Prototyping Kit (a.k.a. the butterfly kit) includes a variety of features, such as:

  • PSoC 4000S device - PSoC 4 with an ARM Cortex-M0+ core and Cypress's fourth-generation CapSense solution
  • Three capacitive touch buttons and a five-segment capacitive slider
  • Onboard EZ-BLE PRoC Module
  • KitProg2, an onboard programmer and debugger that also supports industry standard programming interfaces like CMSIS-DAP and Drag-n-Drop programming
  • Access to all the I/Os in a breadboard-compatible form factor
  • Snap-away form factor, allowing you to snap-away the KitProg2 or the CapSense boards for independent usage


To get started with the PSoC 4000S CapSense Prototyping Kit:      


CY8CKIT-145 and PSoC Creator



  1. Buy the CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping Kit
  2. Download and install the CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping Kit Complete Setup software package
  3. Launch PSoC Creator and start a Code Example based project using CE201709 CapSense Linear Slider and Buttons.cywrk as the code example.

For more information, please visit

Ada Driver Library for ARM Cortex-M/R - Part 1


This is part 2/2 of a series presenting the advantages of Ada for embedded software and introducing the Ada_Drivers_Library project for ARM microcontrollers.


The main objective of the Ada_Drivers_Library is to encourage the use of Ada in embedded systems by providing support for popular ARM MCUs. In this article we are going to talk about the Ada_Drivers_Library itself, its architecture and some of the design choices regarding the Ada features described in part 1.

Generating hardware mapping (SVD2Ada)

SVD2Ada is a tool that uses the CMSIS-SVD hardware description files for Cortex-M MCUs and generates Ada bindings from them.


The tool benefits from the advanced representation clauses provided by the language (described in  Part1 ) that speed-up the drivers’ development and make them more robust (by statically type-checking the register fields assignments).


Below is an example of generated code (USART registers for the ATMEL SAMG55 MCU).


   --  USART Mode of Operation
   type USART_MODE_Field is
      --  Normal mode
      --  RS485 mode
      --  Hardware Handshaking
      --  IS07816 Protocol: T = 0
      --  IS07816 Protocol: T = 1
      --  LIN master mode
      --  LIN Slave mode
      --  SPI master mode
      --  SPI Slave mode
     with Size => 4;

   for USART_MODE_Field use
     (Normal => 0,
      Rs485 => 1,
      Hw_Handshaking => 2,
      Is07816_T_0 => 4,
      Is07816_T_1 => 6,
      Lin_Master => 10,
      Lin_Slave => 11,
      Spi_Master => 14,
      Spi_Slave => 15);

   --  USART Mode Register
   type USART5_MR_Register is record
      --  USART Mode of Operation
      USART_MODE     : USART_MODE_Field := Is07816_T_0;
      --  Clock Selection
      USCLKS         : USCLKS_Field := Mck;
      --  Character Length
      CHRL           : CHRL_Field := CHRL_Field_7_Bit;
      --  Synchronous Mode Select
      SYNC           : Boolean := True;
   end record
     with Volatile_Full_Access, Size => 32,
          Bit_Order => System.Low_Order_First;

   for USART5_MR_Register use record
      USART_MODE     at 0 range 0 .. 3;
      USCLKS         at 0 range 4 .. 5;
      CHRL           at 0 range 6 .. 7;
      SYNC           at 0 range 8 .. 8;
   end record;


This example shows the various representation clauses that are used to ensure that every field is properly described and that each field is independent (e.g. writing a value to a field will never overflow to the neighbour fields). The description of the meaning of those representation clauses can be found in Part1 of this article.


When defined in the SVD file, the use of enum types for fields is also very nice, as very often the enumerals do not cover all numerical values (some are reserved), so this ensures that the user never uses a value not allowed by the MCU peripheral.


Finally, we use those SVD-generated specs as a basis for the device drivers in the Ada Drivers Library. An advantage here is that different MCUs have similar devices, but sometimes they contain small changes from one MCU to another. These small changes are easily captured by the automated tool, and the strong typing - the checks on numerical value size - allows us to verify at compile-time that the driver still works on the new MCU.

Architecture of the Ada Drivers Library

MCU and device drivers

The SVD2Ada generated code is a low-level representation of a device’s hardware registers. As a result it is not very user friendly. Therefore, the MCU device driver layer provides a high level, functional view of each peripheral  that hides the complexity of the underlying register details. For instance, the configuration of an I2C port is quite complex. This layer hides that complexity behind a single function call.


Note that these device drivers are vendor-specific. For example, the I2C port provided by one vendor does not have precisely the same capabilities or interface as that of another vendor. The packages that provide the device drivers are, consequently, located in vendor-specific folders. However, for a given vendor, the drivers’ interfaces are largely independent of the specific MCU. That I2C port, with minor differences, is largely the same across a vendor’s entire MCU family, and so to that extent the software interface is the same.


Each hardware peripheral is presented as an abstract data type (a “class”) with procedures and functions that manipulate objects (via parameters) of the type. As a result, we get good separation between the way the device is represented/implemented and the clients’ usage. That usage includes the number and names of the objects (i.e., variables) of these types.  For example, a given MCU may have a certain number of GPIO ports and pins. Another MCU, also by that vendor, likely has a different number of such ports. The kind of variation appears for each peripheral type and MCU family. Some will have more I2C peripherals, timers, UARTs, and so on than another MCU.


To handle this difference we have a separate package representing each MCU, containing declarations for objects of the peripherals’ types. The number of these objects is determined by the MCU and specified in the corresponding datasheet. The STM32F407xx MCUs, for example, have three A/D converters and two D/A converters. Thus a package representing that MCU would contain three declarations for objects of the ADC peripheral type and two objects of the DAC type. Similarly, it would declare objects for two DMA controllers, twelve general-purpose 16-bit timers, two general-purpose 32-bit timers, and so forth, for every peripheral included within the MCU.


These abstract data types are typically concrete implementations of the interfaces defined in the HAL, as we will see in the next chapter.

Hardware Abstraction Layer

In the Ada_Drivers_Library, there is (or will be) a fair amount of code that can be used across many different MCUs. This includes drivers for external ICs like a gyroscope, and also software stacks like file systems or in the future network, USB, and Bluetooth.


To make sure that the code is portable and easily reusable, we created a Hardware Abstraction Layer (HAL). The HAL is composed of Ada interfaces types defining features common to many microcontrollers. Every microcontroller supported will then provide an implementation of that interface as part of the MCU layer.


Our HAL is partially inspired by the CMSIS HAL. At some point it would be interesting to work on a more complete and standardized Ada version of the CMSIS HAL.



Component drivers are device drivers for devices that are external to an MCU, and thus are connected to the MCU with a standard bus and/or protocols such as I2C, SPI, UART, CAN, and so on.


Example component devices include IO expanders, LED controllers, thermal printers, GPS transceivers, gyroscopes, sensors, and screens, among others.


Because they are connected through a standard bus, they can be used with any MCU from any vendor. Therefore it’s important to isolate them from the MCU-specific drivers. This separation is achieved via the Hardware Abstraction Layer (HAL).


With the HAL, these component drivers can even be used on a bigger system like a Raspberry Pi running Linux. The “only” thing to do is to implement the required HAL interfaces.


The service layer provides some of the hardware-independent facilities that are usually part of an OS but are close to the drivers and thus still useful on a bare-metal microcontroller application. For example, services could include a file system, network stack, USB stack, or a Bluetooth stack. The service layer is lightly populated at the moment.

Board support

Any given board contains an MCU and external peripherals (of the types in the Components layer), and potentially other hardware capabilities (e.g., kinds of memories). Access to the MCU and its peripherals is via the general MCU-oriented packages described above, whereas the Board packages provide interfaces to the external peripherals and other hardware specific to any given board.


The board-specific packages may contain, among other things, the following:

  • Renaming (aliasing) of the MCU’s GPIO to the naming of the board. For instance on an Arduino header these would be D0, D1, D2, and so on.
  • Functions to initialize the hardware devices and the features available on the board. To do so they may use the component drivers. Examples: a screen, a gyroscope.
  • Interfaces to specific hardware provided by the board, for example, the framebuffer interface of a screen.


Let’s go into more details with an example: the OpenMV board.


OpenMV is a computer vision platform based around the STM32F42X and an OV2640 camera module. The board is very small and features 2 headers with user accessible pins than can also be used to plug extension boards or shields (screen, Bluetooth, WiFi, etc.).


The root board package “OpenMV” provides renaming of the STM32F4 GPIO to the headers’ pin name:

Shield_PWM1 : GPIO_Point renames PD12;
Shield_PWM2 : GPIO_Point renames PD13;


The child package “OpenMV.Sensor” provides control of one of the feature of this board: the camera sensor. It declares an initialization function that will do the hardware initialization and configuration of all the sensor’s dependencies: an I2C port to talk to the camera module, the camera module itself, and DCMI and DMA to capture images. The package also provides subprograms to use the feature, for instance the “Capture” procedure that will take a snapshot and store it in a frame buffer. Optional features provided by the shields are implemented the same way.


When features or extension boards share hardware resources it is possible that they are not compatible with each other. Board packages will do the best to report such incompatibilities to the user, most of the time with an exception or error code during initialization.


Here is an example of what an application could look like when we put everything together:

Ada_Drivers_Library example diagram_ MP3 Player.png


As of today, the Ada_Drivers_Library has pretty good support of the STMicro STM32F4/7 family (Cortex-M4/7) and the Nordic nRF51 (Cortex-M0). We want this project to be driven by the community, so please don’t hesitate to contribute and/or discuss the implementation choices on GitHub:



Patrick Rogers has been a computing professional since 1975, primarily working on microprocessor-based real-time applications, including high-fidelity flight simulators and Supervisory Control and Data Acquisition (SCADA) systems controlling hazardous materials. He has B.S. and M.S. degrees in computer systems design and computer science, and a Ph.D. in computer science from the University of York, England. As a member of the Senior Technical Staff at AdaCore, he is project manager and a developer of the bare-board products for Ada.
profile.jpgFabien Chouteau joined AdaCore in 2010 after his engineering degree at the EPITA (Paris). He is involved in real-time, embedded, hardware simulation technology and author of the Make with Ada blog post series. Maker/DIYer in his spare time, his projects include electronics, music and woodworking.
Jerome Lambourg is a senior engineer at AdaCore. After graduating from the french High School Telecom ParisTech in 2000, he worked first for Canal+Technologies, and then as a consultant for General Electrics Medical Systems, SAGEM Mobile, and Thales Naval. He then joined AdaCore in 2005. There he worked on various parts of the technology: GPS, GNAT Pro for .NET, AUnit, certification tools (the Qualifying Machine). He is now involved in cross and bare metal platforms, in particular as product manager of GNAT Pro for VxWorks.

[re-printed from psoc-creator-news-and-information by Utsav Ghosh]


Cypress acquired the Broadcom® wireless IoT business with Wi-Fi, ZigBee and Bluetooth product lines in July, 2016. These new products enable you to add wireless connectivity to your PSoC-based IoT designs.

If you are wondering why you do not see these products in the PSoC Creator IDE, its because the new wireless products use the WICED (Wireless Internet Connectivity for Embedded Devices) SDK and associated IDE.

At Electronica, Germany this month Cypress announced the new WICED Studio 4.0 IDE, the industry's most integrated SDK for IoT with support for both Wi-Fi and Bluetooth products.

WICED Studio 4.0


Benefits/features of the SDK are:


  • Runs on Windows®, Mac® OS X®, and Linux® through Eclipse®-based integrated development environment (IDE)


  • Single installer package with support for:
    • Wi-Fi + Bluetooth combo solution
    • Wi-Fi solutions
    • Bluetooth (Basic Rate, Enhanced Data Rate and Bluetooth Low Energy)
  • Sample applications for many popular use cases like
    • Connecting to cloud services
    • Audio-over-Bluetooth/Wi-Fi
    • Low-power BLE-based sensors and beacons
    • Smart home gateways


  • Code snippets to understand WICED APIs


  • Applications for manufacturing and certification


The SDK supports platforms using:


  • Wi-Fi SoCs (like BCM43364)
  • Wi-Fi + Bluetooth combo SoCs (like BCM43340)
  • Wi-Fi + Host MCU SoCs (like the new BCM43907)
  • New Bluetooth dual-mode SoC BCM20706A2 and the ultra-low-power, Bluetooth + MCU SoC BCM20719 that is scheduled for release soon

Work with a Cypress sales/distribution representative to choose your IoT platform and use the Cypress WICED community to get access to the WICED SDKs today!

Note: Cypress has several flavors of the WICED SDK (like WICED Studio, WICED Smart and WICED Wi-Fi), each supporting different platforms. Contact your local Cypress sales representative/distributor or search the Cypress WICED Community to identify the right WICED SDK for your application.

[re-printed from psoc creator news and information]


Congratulations to my colleague Nagahama-san for winning this prestigious award at Japan's Embedded Technology 2016 show in Yokohama.

PSoC 5LP-driven Rapiro robot

The competition is in its sixth year and challenges competitors to create control applications using the TOPPERS application interface. TOPPERS Toyohashi OPen Platform for Embedded Real-time Systems)is an open source software package, based on the technical development of ITRON, which aims to provide a software development base for use in all kinds of embedded systems.


Nagahama-san based her entry on the Rapiro robot kit - with some added bling to attract attention.




Unmodified Rapiro robot

PSoC robot with a little Bling!

OK, that's quite a lit of bling!


She didn't like the way it performed so she replaced the main board with a PSoC 5LP board running TOPPERS and her control software and wrote a simple game to show it all working together. The new application plays a game called "Point this way", which compares the user's hand movements with a random sequence of robot movements. If the movements match the robot wins, and cheers, and if not, it cries!

The PSoC handles the interfaces to the gesture sensor plus the audio amplifier and the 8x8 LED matrix boards that form the robot's eyes. It also controls the head and eye movements, ensuring that the movements are smooth and controlled.

PSoC 5LP board in the Rapiro

The TOPPERS platform is particularly popular in Japan and it has been running on PSoC since 2013. We are very proud of Nagahama-san's success in this competition and we're sending her more ideas for next year!

ARM recently announced the first two processors using the ARMv8-M architecture, ARM Cortex-M23 and Cortex-M33. ARM TrustZone for ARMv8-M adds security features to these cores that allow applications and services to operate securely while safeguarding the secure resources from being misused, corrupted or inspected by intruders. On November 17th christopherseidl and thomasensergueix hosted a webinar explaining how to program secure and non-secure domains on a processor with TrustZone.


Missed the webinar? Don't worry, you can watch the recording here:



During the webinar there were lots of great questions asked. We wanted to share some of these with you here.


Q: What about the code compatibility, migrating from Cortex-M0+ to Cortex-M23? Or Cortex-M3/M4 to Cortex-M33?

A: Cortex-M23 is building on ARMv8-M which is a superset of the AMRv6-M architecture, so code will remain forward compatible. I would just point out, that as the new architecture improved the programmer's model of the MPU, you are very likely to have to adapt MPU management code (assuming MPU was in use). The same is valid for porting from Cortex-M3/M4 (ARMv7-M) to Cortex-M33.


Q: What kind of OS is used in the secure world?

A: Any kind of real-time operating system supporting ARMv8-M can be used. CMSIS-RTOS v2 API provides a standardized interface for RTOS running on Cortex-M23 and M33.


Q: Is RTX supporting natively secure and non-secure tasks creation?

A: The current implementation of RTX runs in the non-secure state, but can call functions from the secure state. Further revisions will allow for other use cases as well. Generally, we advise to use the RTOS in the non-secure state as this will lower the attack surface for hackers.


Q: How do you define the functions in specific address like secure or non-secure? Using SAU, I understand that we can define regions as S/NS. But while defining the C functions, how will we assign that func1 should go to secure area and the func2 or func3 should go to NS area?

A: Any function defined in the secure project will go to the secure memory, while functions from the non-secure project will be stored in the non-secure memory.


Q: Any issues using Trust Zone entry functions with C++?

A: Code written in C++ must use extern “C” linkage for any inter-state interaction.


Q: Is "ARMv8-M Architecture Reference Manual" available (even in draft state)?



Q: Are Cortex-M23 and Cortex-M33 simulated in Keil MDK?

A: In MDK-Professional you can simulate your code using Fixed Virtual Platforms that model the functionality (not the cycle accuracy) of ARM Cortex-M23 and M33.


Q: Any specific built in crypto engine available?

A: there is no crypto engines built into the Cortex-M23 and Cortex-M33 processors. ARM offer crypto-engines as part of the TrustZone CryptoCell product line.

SSE-200 Demo.png

The new way to implement security


If you were lucky enough to attend ARM TechCon in Santa Clara last month, you may have spotted a big red flashing light on the ARM® booth. It was a convenient way to show that a system was in a non-secure mode and was now vulnerable to attacks. Fortunately the ARM CoreLink™ SSE-200 subsystem demo had a big orange lever, which allowed developers to re-enter a secure mode and turn off the alarm!


When we hear scary news about IoT security, we often wish we had a big orange lever to enable better protection - sadly it’s something developers can only dream of. The good news is that there is an even better way to get the protection, without the need for a big control switch! The protection is called ARM TrustZone® and in this blog I will demonstrate how you can implement it in a system.


It starts with the processor


To protect an embedded device, we ideally need to start at the heart of the system –  the processor. Typically the processor runs a collection of many different sections of software. Sometimes this software features many different layers which have accumulated over several revisions of the product. In the past this was normally not an issue, especially when the device was not connected. However as soon as this system connects to the outside world, nobody can guarantee that the resulting code will be completely free of security holes.


Do we have to rewrite everything from scratch?


Luckily, security experts have created a solution which means you don’t need to rewrite all your code. Instead, you can partition software operation between a secure domain (handling very sensitive information, or accessing features that need to be protected) and a normal domain (running all other software components). In this use case, the secure domain is kept to the bare minimum, in order to allow it to be finely inspected. This ensures that it can be trusted to handle the system’s secrets and sensitive features, plus protect the system from being accessed by any other source.


This solution has been used in large systems with TrustZone technology for more than 10 years, so it is well proven. In the past TrustZone required a security monitor to run on the CPU, which handled the software domain separation. This is perfect when your system has plenty of processing power, but is an issue for more energy-constrained systems. The recently announced ARM Cortex®-M33 and Cortex-M23 processors implement TrustZone separation in hardware, making them a great choice for creating embedded secure systems.




But the processor is not alone


Protecting secrets from the normal software domain is great, but what happens if we have several masters in our system? How can we ensure that all the masters are not corrupted and stop them from copying a secret data buffer to another location?


The solution is to implement a control of all accesses, which secures areas in the address map of the device. This security solution guarantees that the system hardware, enforces the rules set by the architects of the system. The real problem is that an SoC doesn’t have a single bus that in turn could be monitored to tell whether the access is authorized or not. In fact, the reality is much more complex, as a single SoC could have multi-layered interconnects with complex cross-communication schemes and a hierarchy of sub-interconnects.


If we wanted to secure a city, would we stand on the highway and check every car?


Don’t go unfiltered!


ARMDev SSG Thumbnail Images 10.16_SIE-200.pngSince we are unable to ensure central control, the only answer is to mount locks on all the doors. In embedded systems implementing TrustZone security, these locks take the form of filters in front of all memories and peripherals, while also instructing masters (including legacy masters) to behave correctly.


These filters are not simple to design, as considerable care has to be taken to validate that they behave correctly, with safe and secure operation. Fortunately, ARM has developed ARM CoreLink SIE-200, a collection of system IP blocks which can to be used for extending TrustZone security to the system. This saves time and effort for the designers of secure embedded systems – however getting the security architecture right still requires a lot of work.


Now, the good news…


SSE-200 Block Diagram.png

We have a solution to this dilemma! With the new ARM CoreLink SSE-200 subsystem, all the security infrastructure is pre-built into the system. Filters, security control and key components are already integrated within an architecture, designed by the same architects that invented the ARM TrustZone technology.


In the CoreLink SSE-200 subsystem each part of the address map is split in two parts: one secure and one non-secure. This high-level security memory mapping is defined by the IDAU (Implementation Defined Attribution Units) connected to the two Cortex-M33 processors. These partitions are predefined in hardware.


In order to allow memories to contain secure or non-secure buffers, the CoreLink SSE-200 subsystem uses the MPC (AHB5 Memory Protection Controller) from the CoreLink SIE-200 System IP. This MPC is controlled by the secure software, which sets the status (secure or not) of each region of the memory. The granularity is configurable, but the default value is to configure the memory by blocks of 256 bytes (which makes porting the software a little easier). This ensures that almost no memory is wasted (it is not necessary to reserve a huge zone for a few stored bytes).


The subsystem also contains a few peripherals, that are secured by a PPC (AHB5 or APB Peripheral Protection Controller). This ensures that certain sensitive controls are kept out of reach from potentially unsafe software. This protects against several use cases which include;


  • The watchdog being triggered by malicious code, resulting in a Denial of Service (DOS)
  • The Message Handling Unit (MHU) between the two cores being used as an attack vector


ARMDev SSG Thumbnail Images 10.16_TZCrypt312-1.pngThe picture would not be complete without talking about debug. In most use cases, we want to prohibit people from observing the inside of the device once it is deployed in the field. However, we may still want to enable trusted agents, to get access to the debug capabilities of the chip. When you choose to include ARM TrustZone CryptoCell-312 in the CoreLink SSE-200 subsystem, a certificate-based secure debug can be put in place. Trusted agents can then each have their own certificate, giving them access to selected features (including debug visibility on some secure information). Processing the certificate with TrustZone CryptoCell ensures that it is possible to hide some information, or even to wipe out personal data (e.g. when a returned product contains customer private data).



More good news!


Making use of all these hardware features is not easy, but the CoreLink SSE-200 subsystem comes with a layer of software, which makes this task significantly easier for firmware developers. The subsystem is integrated with TrustZone CryptoCell's secure libraries and with ARM mbed OS. This IoT software framework is already adopted by more than 200,000 developers, which makes the subsystem software extremely valuable for all embedded product developers.


This subsystem software is currently reserved for lead partners, and it will be distributed as open-source, to enable you to easily port it to derivative devices or other RTOS environments.


This is not just added value for the chip manufacturers, it is also a great way to ensure that future embedded devices (especially in the IoT mark) benefit from a higher level of security. The true benefits of IoT will come to fruition, if we manage to bring this high level of trust to the users.


Security is our challenge!


The bright future of IoT is waiting for us, all we need to do is make it happen - the first step on this journey is to concentrate on your next product design! It is possible to build a secure system very quickly with the help of the CoreLink SSE-200 subsystem, you can even expand security and connect many other masters and peripherals, using CoreLink SIE-200 System IP.


Obviously care should be taken at each stage of the design, but all the foundation elements are available to build efficient secure systems, it is now up to us all to enable a secure IoT!



If you're looking for more information on ARM's new launches you can check out these other blog posts:


Accelerating the deployment of secure IoT: From chip to cloud

The six things you need to know about ARM CoreLink SSE-200 subsystem & ARM CoreLink SIE-200 system IP

ARM TrustZone CryptoCell-312: Simplifying the design of secure IoT systems

Cortex-M23 and Cortex-M33 - Security foundation for billions of devices


For more information about SSE-200 and SIE-200 please attend our webinar 

It's hard to believe that ARM TechCon finished just two weeks ago, it was a busy week for the ARM team! I wanted to take a few minutes to share some of my highlights with you.


IoT product announcement


CvocNHdW8AAN7Q6.jpgAt ARM TechCon this October, it was great to see Mike Muller announce ARM’s product solution.


The new IoT suite includes ARM® Cortex®-M processors (Cortex-M23 and Cortex-M33), a new IoT subsystem SSE-200 with ARM CoreLink™ SIE-200 system IP,  ARM TrustZone® CryptoCell-312, ARM Cordio® radio IP, ARM mbed™ Cloud and ARM Artisan® IoT POP™ IP.


These new products enable partners to quickly deliver a secure, connected IoT device and will ultimately be a key driver, in enabling a 1 trillion device ecosystem and beyond.



IoT 'Cambrian Explosion'

Earlier that week, Masayoshi Son claimed in his keynote address, that IoT is now representing the next ‘Cambrian explosion’ scale shift in technology. We’ve seen the center of the internet shift rapidly from PC to mobile over the last few years, and will most likely witness the crossover from mobile to IoT within the next few.


Interview with EDA Cafe

Later that same week I also had an opportunity to reflect on this exciting announcement with Sanjay Gangal, president of


Demonstrations on the ARM TechCon expo floor


To strengthen the announcement, even had a demonstrator of the technology available on the ARM booth that we are happy to say created much interest, shown here with Simon, a much more photogenic member of our team than me.

Our CoreLink SSE-200 demo (shown in the video here) showed off the capabilities of secure and non-secure memory accesses, further accelerated by TrustZone CryptoCell-312.


Our ARM Socrates™ Design Environment IP Tooling demo, showed how you can extend the CoreLink SSE-200 subsystem to create an IoT-based SoC.

[reprinted from PSoC Creator News and Information]


One of my favorite new features in PSoC Creator 4.0 is the ability to create and use templates for new projects. I used it extensively during my theater presentations at the Electronica trade show in Germany last week (which is why I did not manage to get a blog article out!).


In the presentation I made a robot car follow a line of electrical tape on the desk. The project used PWMs to drive the reflectance sensors and the motors. The two parts of the design were almost identical and so, in the best TV cooking show tradition, I pre-prepared the motor-driving part in order to save a little time and spare people the agony of watching me draw and type!


It is really easy to create a template. You simply make the design, then right-click on the project in the Workspace Explorer and pick the "Copy to My Templates" entry. Job done!


To use them open the New Project dialog as normal and in the "Select project template" step select "My Template project".

When you press Next you see a list of all the templates you have created. I have two versions for my robot presentation and one for my Pioneer 4200 kit.

When the new project is created it will include all the functional content from your selected template. Awesome sauce!


While the robot templates were great at the show I am using my Pioneer template all the time. It is the board I use most often and my template saves me adding the input pin for the switch, the output pins and PWMs for the LEDs, the CapSense, the I2C, and the UART to every single project I make. It is so much faster to delete the stuff you do not want than to add the stuff you usually need. Best of all, I never put the pins in the wrong place when I use the template. I even put commented-out startup code in main.c so I can quickly uncomment the lines that I need for typo-free firmware.


If you find that you use the same hardware for multiple projects or you have design elements that you reuse all the time then project templates could be of real benefit to you. Give them a try - it takes five seconds to create one and ten to use it in a new project. You may find that it saves you hours or days in your future development work!



The new ARM® Cortex®-M23 and Cortex-M33 processors, announced at ARM Techcon 2016, are the first in a new family of ARMv8-M based processors, bringing proven ARM TrustZone® technology to secure even the smallest of embedded devices.


The new processors make it easier for developers to create extremely energy-efficient, secure and connected IoT devices.  Licensed by the majority of the top 10 global MCU suppliers and backed by the world’s No. 1 embedded ecosystem, the Cortex-M23 and Cortex-M33 are set to become the processors of choice for microcontrollers, extending TrustZone as a standard for creating secure IoT solutions.


You can now find out more about these processors and how to program them by joining a training webinar from Doulos, an ARM Approved Training Centre.  Doulos will host two webinars on Friday 2 December, 2016.  Take a look at the Doulos website to register and find out more.


If you can’t make the Doulos webinar, find out more about the security capabilities of the Cortex-M23 and the Cortex-M33 in Tim Menasveta’s recent Cortex-M23 blog and Diya Soubra’s Cortex-M33 blog.


Gadget Guru, Keith Lee shows you how to get a DragonBoard Drone airborne on Open Hours @96Boards. Simple steps to build your own self-piloting drone.

Check out the instructions and youtube flight video at The Gadget Guru blog





ARMDev SSG Thumbnail Images 10.16_TZCrypt312-1.pngConnected devices have become a vital part of our lives, impacting everything from our homes to our offices and factories, even improving our health and fitness. However, these IoT devices have also become an increasingly attractive target for cyber criminals. More connected devices mean more attack vectors and more possibilities for hackers to target us. Last week at ARM TechCon, we announced ARM® TrustZone® CryptoCell-312, the latest product in the CryptoCell line-up (which includes the CryptoCell-700 family and the CryptoCell-300 family).


The CryptoCell-700 family is geared towards high performance, typically aimed at devices and use cases, which involve an ARM Cortex®-A processor under-the-hood. The CryptoCell-300 family is created with high efficiency in mind, typically aimed at devices and use cases involving an ARM Cortex-M or an ARM Cortex-R processor. These are typically designs optimized for low power and low area.


We all know that the IoT will encompass a whole range of intelligent devices. Many of these new devices will require sophisticated security systems, meaning we need to bring security to even the smallest of embedded devices. The brand new ARM TrustZone CryptoCell-312, has been optimized to complement the small, ultra-low power characteristics of the Cortex-M family (including the new Cortex-M23 and Cortex-M33), allowing you to simplify the design of secure systems.


So, what is CryptoCell?

Well, CryptoCell complements ARM TrustZone and fortifies device security. TrustZone provides isolation and gives ARM partners the capability to partition the system, creating a secure execution environment. Using TrustZone prevents software vulnerabilities in one execution environment being exploited to gain access into another. However, isolation is just one part of security – for a comprehensive security platform you need additional roots of trust and security mechanisms. This is where you add CryptoCell into your designs.



CryptoCell-312 is partitioned into 5 domains:

  • Control domain
  • Data interface domain
  • Symmetric cryptography domain
  • Asymmetric cryptography domain
  • Security resources domain


This partitioning helps us maintain a modular approach, which enables all kind of PPA trade-offs. CryptoCell addresses the control and scheduling aspects, data interfaces, cryptography (symmetric and asymmetric) and the various security resources, which turns a cryptographic accelerator into a security solution.


The security resources domain is where platform security elements are enabled, typically using cryptography and off-device tools. These include: lifecycle, ROT management, RNG, key slot policies, provisioning, software image validation (boot time, update time), IP protection (code confidentiality), persistent and volatile data protection, secure debug / DFT and feature enablement.


  • Lifecycle
    Lifecycle refers to the multiple states a device goes through during its lifetime – it starts with the SoC, typically containing little or no sensitive information. ICs are then shipped to OEMs and the chip gets assembled into a device, where it gets loaded with some device maker information. The next stop is often a retailer or a service provider, followed by actual deployment in the field (whether that’s a consumer, enterprise or governmental use).  These various life cycles states need different policies related to all kind of behavioural aspects of the device (including code loading, debug, operability of interfaces and features).


  • Roots of Trust (RoT)
    Some elements serve RoT, which are assumed to be non-modifiable and non-accessible by untrusted entities. These elements use persistent on-chip storage that is accessible only by CryptoCell. Roots of Trust can be in the form of keys, used for various purposes and owned by different entities or other information pertaining to the state of the device.
    CryptoCell also supports a RoT ownership model, which allows multiple owners and multiple sets of roots of trust, which in turn enable different parties in the ecosystem (IC vendor, OEM, Service Provider) to own and monetize processes & assets without having to trust each other.


  • True Random Number Generator (TRNG)
    The True Random Number Generator (TRNG) creates a random seed out of a source of entropy. In CryptoCell the source of entropy is completely digital and made out of standard cell libraries.


  • Key slot
    A Key slot refers to a key and its policy. The policy defines access rights, usage rights and methods of use. Key slots enable isolation of keys from a certain execution environment or full isolation from all environments (i.e. usage at the HW level only).


  • Provisioning
    Provisioning refers to the secure delivery of assets, to a device over untrusted bearers. Provisioning can involve a broad threat model, requiring aspects like mutual authentication and ecosystem enablement.


  • Image validation
    Image validation ensures the integrity and authenticity of an already provisioned software image or software update, being delivered over-the-air.


  • Code confidentiality
    Code confidentiality may also be required in the context of IP protection.


  • Persistent and volatile data protection
    By Persistent and volatile data protection we mean the protection of data stored over different media (for example, flash or DRAM) against both offline and runtime attacks. This also includes rollback protection, preventing a stale set of data from being re-introduced to a device.


  • Secure Debug
    Secure Debug (or Authenticated Debug) is the authentication of a debugging entity and verification of the rights it was granted. The process starts with the introduction of a device unique debug certificate, continues with the validation of that certificate and ends with the hardware based enforcement of the debug policy, captured in that authorization certificate.


  • Feature enablement
    Feature enablement refers to the ability to turn capabilities on and off in the field in an authenticated, well defined manner.


Why do I need CryptoCell-312?

There are three main reasons why you’d want to use CryptoCell-312 in your new IoT device.


Enabling a full set of security services over deeply embedded form factors


CryptoCell-312 enables you to have a full set of security services, over a range of deeply embedded form factors. It provides you with a security platform providing cryptographic and security services, tailored to deal with different needs and threat models.

Enhanced performance allowing efficient offloading of IoT communication


CryptoCell-312 offers enhanced performance – offering a 10x faster cryptography performance when compared with software only operations on cryptography tasks. This drives improved energy efficiency, security and enables better user experiences, for example in the case of a smart door lock (see below).

Technology enforced trust between all stakeholders – allows monetization


IoT devices are often created in fragmented ecosystems, CryptoCell-312 allows trust between stakeholders. This in turn allows multiple entities to monetize their investments without having to trust other parties.



A use case for CryptoCell-312


Smart_lock.pngThere are many applications where security is needed. One such area is smart locks, which have grown in popularity but several do not have adequate security. Some examples of inadequate security include Bluetooth locks that store passwords in plain text and anyone with a Bluetooth sniffer can readily gain access. Other smart locks are vulnerable to replay attacks, which means a hacker can grab data over the air when a legitimate user unlocks the door and they then just replay that data to gain access.


A secure Smart lock should be capable of authenticating a home owner’s device (for example, a mobile phone) attempting to open the door. One way to achieve this is with a back-end cloud service that could be used for lock initialization and authorization.



Step 1

A homeowner buys a smart lock and the package includes a QR code. The QR code includes an App reference and a unique identifier. Once scanned, a mobile lock application is installed on their phone.

Step 2

The secure application then goes through a registration phase with the lock cloud server. When complete, the mobile device is provisioned with an admin key pair and a certificate (signed by the lock manufacturer) unique for that lock.

Step 3


The lock can then securely authenticate requests (for example “open door”)  from that mobile phone and open the door upon successful verification.


To enable these services, there are several security mechanisms that the lock needs to have. These mechanisms include:


  • Secure boot validating the loaded software image, as well as a firmware update mechanism to validate software updates (ideally with the ability to revoke images)
  • The ability to protect the integrity of the Cloud service public key, as well as public keys belonging to authorized users (for example: children, friends and other family members)
  • TRNG to issue random challenges to the device attempting to unlock
  • Asymmetric crypto support for verifying the signed response to the lock’s challenge


CryptoCell-312 is one of the key technologies needed to enable these security mechanisms and provide a security platform for the smart lock system.


Simplifying the design of secure IoT systems

Together with TrustZone, CryptoCell-312 can form a security solution providing cryptographic services and platform security services, tailored to deal with different needs and threat models.


FullSizeRender.jpegJust like that, ARM TechCon is over for another year! Last week was an exciting week for everyone within the ARM ecosystem and it was a very busy week! I wanted to round off the event with one last blog post, so here are some of my highlights from the third and final day of ARM TechCon. If you missed my previous blog posts, you can check out my highlights from day one here: Building better systems at ARM TechCon – day 1 and my highlights from day two here:  Building better systems at ARM TechCon – day 2.


Hacking cars and crashing Jeeps

The third day kicked off with a fascinating keynote from Charlie Miller (Senior Security Engineer, Uber Advanced Technologies Center). Who is well known for his remote car jacking work in the automotive field. Charlie took us on a journey where he shared his various experiences of cracking car systems, starting in September 2012. His frustration of the lack of technical details surrounding earlier attacks, led him and his friend (Chris Valasek) to start their own work.


Charlie and Chris’ journey in this space had many different steps;

  • September 2012 – granted funding from Cyber Fast Track which allowed the purchase of two vehicles (Prius and Ford Escape)
  • August 2013 – successfully plugged into both cars and sent messages to control steering
  • July 2015 – remotely hacked moving Jeep,which lead to the recall of 1.4 million cars
  • August 2016 – managed to remotely attack the car and control its steering, no matter how fast the car was going


Charlie then walked us through the different methods you can use to hack cars which included; Bluetooth, cellular modems, CDs, web browsers and even insurance dongles. Before leaving us with an important message; cars have always been insecure, but it never mattered until now. His biggest call-to-action was for the audience to understand the difference between car hacks. Many news articles use the term “car hacking” but more often than not, these hacks are unlikely to cause life or death situations. The hacks we need to worry about are those that have the ability to tamper with CAN bus messages.


Jeff3.jpgUnlock the potential of Cortex-A systems with ARM's next generation System IP

Following on from his exciting talk at the Linley Processor Conference, jdefilippi (Senior Product Manager, ARM) took to the stage to tell attendees about the new ARM® CoreLink™ CMN-600 and ARM CoreLink DMC-620 coherent backplane IP. He showed us how the  ARM AMBA® specification and CoreLink Interconnect IP has improved over time, building to the latest products in our portfoilio. Jeff highlighted how these new products allow designers to build more powerful systems, delivering six times more compute and five times more throughput. The new products allow designers to tailor solutions and systems from edge to cloud.


Learn more about the new products here: Build more powerful SoCs from Edge to Cloud


Phil Burr.jpgAccelerate your IoT design

ARM’s philburr (CPU Product Marketing Manager) joined Kevin Yee from Cadence Design Systems to discuss how ARM’s Design Start program, the Cadence® Hosted Design Solution (HDS), the CoreLink SSE-100 IoT subsystem and mbed OS can help you to accelerate IoT designs.


ARM and Cadence have spent a lot of time validating IP designs and subsystems, which has improved compatibility and TTM, while reducing risk and cost. Cadence demonstrated the results of this work within their HDS environment, which allows designers to be productive in any location, with flexible systems and 24/7 support. Their demo showed developers working onsite at ARM TechCon in California, working on servers hosted in Munich, with no delay or lag.



Mario2.jpegAssemble systems in days!

mariocooper (Product Manager, ARM) was onsite to show how ARM tooling and models (including CoreLink Creator, ARM Socrates™ Design Environment, ARM Fast Models and ARM Fixed Virtual Platforms) can speed up developer time, meaning that you can assemble systems in days! The second part of his talk showed how Reference Data is used at ARM and how it enables partners to reduce design risk and development costs.







Panel_Jeff.jpegFinding solutions to performance challenges

jdefilippi's second talk of the day was a collaboration with Cadence, where we modelled performance use cases with traffic profilers. Everyone agrees that it is beneficial to find performance issues early in the process and the talk showed how workload use cases can make this easier. The team introduced Traffic Profiles over ARM AMBA interfaces, which enable the creation of these workload use cases. During the talk, ARM and Cadence shared an example of ARMv8-A mobile subsystem, which uses Traffic Profiles implemented on top of the Cadence Simulation VIP.


Thanks to everyone who joined us at ARM TechCon this year, we hope to see you all again next year!

[re-printed from PSoC Creator news and information]


With the recent release of PSoC Creator 4.0 we are making it easier to find the right part number when you are creating new designs in the New Project dialog.

New Project Dialog


As you may have noticed Cypress is proliferating devices and kits and Bluetooth modules at a really high rate these days. This is fantastic news for all of us but some PSoC Creator interfaces are starting to struggle with all the new products it supports. Put simply, it is getter harder and harder to pick the right part got your projects! So, we have re-worked the New Project dialog to make it easy to home in on the device you need.

We have split the selection process by the type of target. There are three types - kits, Bluetooth modules, and "raw" devices. A lot of projects run on one of our kits and so we took away the need to know the precise part number (e.g. CY8C4245AXI-483 - remember that?) for the device on the board. You just pick the kit and the tool automatically selects the part number for you. As you can see… I have a lot of kits. You probably have just one or two because it only shows the kits you have installed.

New Project Dialog - Kit Selection


Our Bluetooth modules are shipping like crazy and we are making more all the time. We saw that it was going to get really tricky to find the module when they were mixed in with the device part numbers in the Device Selector so now we have a simple drop-down listing the modules.

New Project Dialog - Module Selection


Lastly, we still have the ability to pick the device by part number. Even there we needed to add some filters because we now support over 600 devices! There are two drop-down lists to get you straight to your part. The first chooses between PSoC 3, PSoC 4 and PSoC 5LP. The second lists the most popular devices for that type of device. The tool always remembers your last-used device and puts that at the top of the list. After that there are the different series of devices. Picking one of those selects the device with the most resources in that series. Finally you can launch the Device Selector to browse, compare and select from all the devices.

New Project Dialog - Device Selection


We hope you like the new changes. It takes a couple of extra clicks to create a project now but we think that will dwarf the time lost when you pick the wrong part and have to figure out why you cannot program it. Go on… tell me you have never done that (I'll admit to it about once a month)!

For more information about SSE-200 and SIE-200 please attend ARM's upcoming webinar!



Security is complex and designers need building blocks they can trust to achieve stringent security requirements for their IoT designs. The risk of getting security wrong is incredibly high. In order to simplify the design of secure IoT nodes ARM® recently announced a comprehensive suite of products to address the IoT market. Check out nandannayampally's blog post "Accelerating the deployment of secure IoT: From chip to cloud" for more information on the launch.


Within that announcement ARM launched two new products which complete the story around the brand new ARM Cortex®-M33 and Cortex-M23 processors. Together they bring security to these low cost constrained IoT devices:


ARMDev SSG Thumbnail Images 10.16_SIE-200.pngARMDev SSG Thumbnail Images 10.16_SSE-200SS.png

ARM CoreLink SIE-200 System IP for Embedded

A collection of interconnect and controllers IP to allow designers to extend TrustZone security to the entire SoC. The low power IP components are optimized to design TrustZone compatible secure IoT/embedded SoCs around ARMv8-M processors.

ARM CoreLink SSE-200 Subsystem for Embedded

An IoT subsystem based on the Cortex-M33 processor for the fastest, lowest-risk path to ARMv8-M silicon. The subsystem is an integration of the latest ARM IP and provides a foundation for building a secure IoT node.


The two new products are complementary and the intention is to provide designers with a spectrum of solutions to choose from to meet their product requirements for secure IoT solutions. Let’s look at six things you need to know about these new products…


1: CoreLink SIE-200 allows you to secure your system beyond the processorSIE-200.png


CoreLink SIE-200 System IP for Embedded is a collection of low power IP components that can be used to architect a secure IoT/embedded design around ARMv8-M processors. The CoreLink SIE-200 building blocks are built on top of the AMBA 5 AHB5 protocol to form the foundation of a system wide security solution. The interconnect IP, along with the TrustZone controllers provide hardware-enforced isolation between trusted and non-trusted applications. As an example use of the IP, not only is the CoreLink SIE-200 system IP used in stitching the various elements in the CoreLink SSE-200 subsystem, it will also be used in extending TrustZone protection to all peripherals and external IP SoC designers will integrate to build their own IoT solutions (radios, peripherals, sensors).



2: SIE-200 IP provides the lowest-risk IP route for building ARMv8-M SoCs


CoreLink SIE-200 IP provides TrustZone compatible System IP that has been co-developed and validated with the ARMv8-M processors from ARM. The IP follows best practices and recommendations from ARM security architects in building secure systems around the latest ARMv8-M processors. Furthermore, the IP is used to help the ARM tools and OS vendor ecosystem to port to ARMv8-M architecture. Ecosystem partners such as ARM Keil® MDK, mbed OS, IAR, free RTOSA and  Lauterbach also develop their tools with our FPGA platform based on CoreLink SSE-200 subsystem. This ensures compatibility and increased verification for the  SIE-200 system IP. Product designers architecting their secure IoT SoCs with CoreLink SIE-200 can do so with peace of mind and focus on differentiation and value-add.



3: CoreLink SIE-200 IP enables custom IoT solutions

The CoreLink SIE-200 IP blocks support a range of configuration options and the choice of multiple components give SoC architects maximum flexibility in building their secure system architectures. The intention is to allow designers to “buy once and use many” and support multiple architectures (single processor systems to multi-processor systems; coarse or fine-grained memory partitioning; security control options for integration of legacy masters; single or multiple power/clock domains; and many more), all while saving significant verification time. This means you can tailor each design to suit a specific application with efficient sharing of memory and peripherals across secure and non-secure applications.



4: The ARM CoreLink SSE-200 subsystem is the fastest and lowest risk route to ARMv8-M silicon



CoreLink SSE-200 is a second generation subsystem for embedded and it is the foundation on which SoC designers will build secure IoT products. The design of IoT products requires expertise, time and a significant hardware and software integration effort. In order to help partners get to market faster, ARM has mobilized its best experts to create this integrated secure solution. CoreLink SSE-200 subsystem has been thoroughly verified and packaged it in a way that allows product designers to quickly get a state-of-the-art, IoT device to market.


5: CoreLink SSE-200 builds on many new components developed by ARM


The CoreLink SSE-200 subsystem combines all of the latest ARM IP to provide a foundation for building a secure IoT node. The fully verified IP enables you to get security right and keep power consumption low. The system allows you to tweak the configuration, depending on your system requirements:


The CoreLink SSE-200 subsystem hardware components:


The CoreLink SSE-200 subsystem also integrates software components:

  • mbed OS
  • Cordio Bluetooth stack
  • Secure libraries from ARM TrustZone CryptoCell
  • Various drivers and power management features



6: The CoreLink SSE-200 has many different applications


Not all IoT applications are the same and you cannot just have a single design target. Luckily, there are lots of ways that you can configure the new CoreLink SSE-200. Here are two example use cases:


Simple battery powered sensor

A simple battery powered sensor will spend most of it life in hibernate mode to maximize its battery life.  So in this example, to minimize power, the system will keep most of its components powered off. Each block has its own intelligence and does not need to rely on the processor for power gating. From time to time the device will also need to securely connect and stream data to the cloud. Doing a short burst of local processing on the sensor data minimizes power, transmit time and bandwidth. The second, higher performance processor, can perform  the more complex tasks faster  (eg. as required by NB-IoT). As soon as this burst of activity is complete, the system can then switch back to the lower frequency processor, to minimize power consumption.


Plugged system

You may also have an IoT application that is plugged into the wall (e.g. smart home alarm system). Even if preserving battery life is no longer a concern, energy saving is still key to sustainable development. In this use case, the energy-efficient processor can manage local device management, while the high performance processor will improve user experience and can perform advanced processing (e.g. running machine learning algorithms). All of this can happen with a limited power budget thanks to the efficiency of the Cortex-M33 processor.


For more information, follow the links below!



If you'd like to learn more about SSE-200 check out ftbug's blog post Security and the ARM CoreLink SSE-200 subsystem – what you need to know!

Capture.JPGThe Embedded Computing Design 2016 ARM e-mag is out now. This year Embedded Computing Design tracks the evolution of development tools for the world's largest processor ecosystem, provides an update on the mbed OS, implementing TrustZone for v8-M, and more.


Development tools are more critical than ever as ARM IP permeates real-time and safety-critical markets outside the consumer sector, such as industrial, medical, and transportation. In this Q&A with Javier Orensanz Martinez, General Manager, Development Solutions Group at ARM, he explains the evolving role of development tools such as DS-5 Development Studio, as well as how modeling technologies are allowing customers to bring solutions to market faster than ever before.


Get your copy of the 2016 ARM e-mag »

Filter Blog

By date:
By tag:

More Like This