Embedded Systems Academy (EmSA), a leading provider of embedded software solutions for CAN based industrial networks, is pleased to announce the release of its Micro CANopen libraries as Open-CMSIS-Pack following the Common Microcontroller Software Interface Standard (CMSIS) by Arm. This new integration enables developers to easily implement CANopen communication protocols in their embedded systems.
Until now, these Micro CANopen libraries were already available as part of selected NXP MCUXpresso Software Development Kits (SDKs). Along with NXP’s recent release of support for MS Visual Studio Code, SDKs and third-party libraries are moving to Open-CMSIS-Packs, ensuring compatibility with a wider range of development tools and microcontrollers. For more information on NXP’s step towards VS Code and Open-CMSIS-Packs, follow this link.
The Micro CANopen libraries from EmSA offer a minimalistic implementation of the CANopen and CANopen FD communication protocols for I/O devices and basic managers/controllers. They are designed to simplify the development process by providing a compact and efficient solution, saving valuable time and resources for embedded system developers. Through the Open-CMSIS-Pack format, developers can leverage the libraries seamlessly, further enhancing the efficiency and reliability of their CANopen-enabled applications.
The published Micro CANopen libraries may be used at no license charge and are adequate to implement basic I/O devices with a limited number of parameters or a controller with a limited number of nodes to handle.
“We are excited to bring our Micro CANopen libraries to the Open-CMSIS-Pack ecosystem,” said Olaf Pfeiffer, CEO of Embedded Systems Academy. “By making our libraries available as Open-CMSIS- Packs, we aim to empower developers to effortlessly integrate CANopen or CANopen FD support into their embedded projects.”
Developers can use any tool that supports Open-CMSIS-Packs to access these CANopen libraries such as NXP MCUXpresso, Visual Studio Code, Arm Keil MDK and IAR Embedded Workbench. The libraries are compatible with the latest Arm CMSIS releases and initial support covers several popular NXP LPC and i.MX microcontroller derivatives.
Example of the access to the Micro CANopen libraries, here using Arm/Keil’s Pack Installer
The current beta release features the Micro CANopen release for selected NXP microcontrollers. Future releases will support NXP’s auto-configuration and more derivatives with CAN or CAN FD interfaces.
Over the last years we published more than 50 articles, papers, books, webinars and we also continuously updated our training materials. However, some of the training material and especially scientific papers only reach a small percentage of the embedded community. Therefore we decided to publish more free educational videos to reach more of you. As a start we created several playlists on our EmSA Youtube channel. These include:
CANopen FD Intro:
Introductory videos to CANopen FD, also covering some basics like an introduction to the CANopen Object Dictionary concept
CAN (FD) Security:
Video collection about CAN and CAN FD security challenges and solutions
MCUXpresso Middleware:
Video collection about NXP’s MCUXpresso and CANopen libraries included
We plan to publish more videos in the upcoming month, further focusing on CAN, CAN FD, CANopen, CANopen FD topics including introductory videos as well as in-depth technology classes.
Please subscribe to the channel to stay informed about new videos published.
Darmstadt and Hannover, June 12th, 2019. PEAK-System Technik GmbH (www.peak-system.com) and Embedded Systems Academy GmbH (www.esacademy.de) have deepened their partnership to provide common CANopen, CANopen FD, and J1939 solutions. For more than 15 years, Embedded Systems Academy GmbH (EmSA) has offered numerous CANopen software products including monitors, analyzers, simulators, configurators, and protocol stacks for the CAN (Controller Area Network) hardware of PEAK-System Technik GmbH (PEAK). Building on that partnership, PEAK has now become a shareholder and partner of EmSA.
“By formally joining the PEAK Group of companies, we can now more easily share resources and are better positioned to streamline development processes that involve both CAN hardware and software,” says Olaf Pfeiffer, General Manager of Embedded Systems Academy GmbH.
Current projects of PEAK and EmSA include CANopen (FD) generic input and output devices, CANopen (FD) protocol libraries, security options for CAN and diagnostics and test systems for CANopen (FD) and J1939.
“The deepened partnership with EmSA will provide our hardware customers with a variety of easy-to-use software products for CANopen, CANopen FD, and J1939 applications,” says Uwe Wilhelm, General Manager of PEAK-System Technik GmbH. “We’ll announce our new joint CANopen and CANopen FD solutions on our websites and blogs over the coming months.”
The new CANgineBerry is an active CAN interface with a Cortex-M0 microcontroller and various firmware options. At launch, two options are available: One for a CANopen Controller / Manager and one for a configurable CANopen slave device.
The CANopen Controller scans the network for connected slave devices within less than 50 ms after power-up, sets up process data handling, starts the network and continues monitoring it. Once the host that CANgineBerry is connected to is up and running as well, it can immediately start using the CANopen network and access any device.
The second firmware option is implementing a CANopen slave device which is fully configurable with node ID and with an Object Dictionary that the user creates with the provided CANopen Architect software (evaluation version is sufficient for this use).
The CANgineBerry’s host can be a Raspberry Pi®, another embedded computing systems or even a PC. The communication to the host system uses a regular serial channel (TTL-UART), so no special driver is required as UART support is typically part of all operating systems. The communication between host and CANgineBerry and the API is designed to serve the application. For example, heartbeats are automatically monitored but the host is only informed about changes in the heartbeat status (like “activated” or “lost”) but not about every individual heartbeat message.
This architecture of CANgineBerry addresses the shortcomings of many “CAN shields” that are passive, have no own intelligence and require the host computer to handle all CAN communication message by message. In worst case, a CAN system can have more than ten thousand individual messages per second. Sometimes the real-time requirements are below 10 ms for some responses which is not realistically achievable with a Linux or Windows® based host and a passive approach.
Summary of firmware options currently available or under development:
CANopen self-configuring Controller / Manager
CANopen slave device (configurable via EDS, Electronic Data Sheet)
Lawicel CAN-RS232 protocol
CANcrypt (secure CAN communication) for the above versions
CiA 447 – automotive add-on electronics
J1939 gateway
For more information about the CANgineBerry, current firmware options and availability, visit www.CANgineBerry.com
Meltdown and Spectre are considered by many to be the biggest security flaws in the history of computing, both in terms of numbers of affected devices (billions) and time they have been laying dormant (20 years). Whenever security issues like these that affect PCs and mobile devices become public, we take a look at how they might affect Embedded Systems as well. An inconvenient truth in our industry is that software in Embedded Systems does not get updated, to put it mildly, as often as regular desktop PCs. Sometimes that means “never”. That is why even “ancient” attack vectors like the WannaCry and its descendants such as Petya and NotPetya ramsomware can still cause major damage in various systems, even months or years after the underlying security issues have been made public.
The core issue behind Meltdown and Spectre is that parts of a memory protection and isolation system are being compromised on a hardware level. Such isolation is meant to ensure that one task or program can not access the memory used by another task or program and potentially spy out sensitive information. The “good news” for most older chips and many embedded microcontroller devices first: They often don’t have a vulnerable memory isolation logic (involving out-of-order or speculative code execution) in the first place. It is actually worse: The memory in most lower-end embedded chips is wide open to all running tasks. While some microcontrollers do provide an MPU (Memory Protection Unit, see ARM Community for an example), it is often limited in terms of number of memory areas, sizes and number of levels/tasks supported. From our experience it is safe to say that a large number of embedded applications doesn’t make use of it at all. And when an MPU is used, then the primary goal is often to protect code against memory-crossing bugs to make it safer against failure, but not attacks. With these types of systems, once a hacker manages to execute some code on an embedded device, this code should be assumed to immediately have access to all resources of the chip, including the memory.
This looks like a devastating assessment from a security standpoint, however, injecting code into an embedded microcontroller is not easy. Many such systems do not use an operating system at all, have no command line or only a very limited user interface without the option to load and start a piece of code. Typically the only way to inject code is through a bootloader or a debug interface, if at all. It is up to the system designers, sometimes the factory programming and the program running on an embedded microcontroller to disable casual access to these functions.
We know that for many designers of embedded systems, the time they can spend on security issues is limited. If you are part of this group, you may use the publicity around Meltdown and Spectre to justify some extra time to review potentially vulnerabilities to attacks that are based on the same principle: to load or inject malicious code that spies out or manipulates data in your embedded system.
For such a review, first look for all options how code could be injected into your system or altered. Could an attacker make use of any of the provided bootloader mechanisms or the debug interface? If you can’t disable all of these because you need to be able to update “legitimate” code, then authentication is mandatory and encryption during transmission highly recommended. Preferably implement different layers of authentication, for example one to access the interface to update code and another one to protect the code itself. For an example see the secure secondary bootloader we implemented for NXP. Also, review if your microcontroller has a MPU or similar and how you can make best use of it not only to protect the system from buggy code but also from intentional attacks.
Together with NXP, the Embedded Systems Academy implements a secure CAN FD bootloader based on the CANcrypt security protocols. The bootloader will be available to users of the LPC546xx as free download. It is a “secondary bootloader”, meaning that it only provides security for the added bootloading channel, in this case the CAN FD interface. Someone with physical access to the LPC546xx will always be able to use the primary, on-chip bootloader to re-flash the device with any code.
The security system of the bootloader uses two security levels, each based on a symmetric key (default 128bit, up to 1024bit optional).
On the CAN FD communication level, the CANcrypt protocol (www.cancrypt.eu) is used to ensure that only an authorized communication partner can activate the bootloader, erase the flash memory and send new code to the LPC546xx. The CANcrypt connection key used for this level is generated by the system builder or integrator that initially assembles the entire system.
On the file transfer level, the file containing the new code to be loaded is encrypted using an encryption and authentication method based on a code protection key that gets programmed into the LPC546xx at the same time when the bootloader is installed (typically at manufacturer end-of-line assembly and test).
Figure: Secure bootloader security levels
These two levels ensure a separation of the security features between manufacturer and system integrator/builder or service technician. Only an authorized technician will be able to connect his diagnostic device or software to the bootloader. But at this security level alone it will not be possible to generate authorized firmware, that requires an additional key only known to the manufacturer.
The version for free download is a binary only and will use a pre-selected cipher algorithms, fixed default configuration for parameters like CAN FD bit rates, CAN IDs and timings and timeouts used. The full source code is available from Embedded Systems Academy, giving users full control over all configurations and cipher algorithms used.
NXP offers a Two-Part Webinar based on the LPC54000 series about CAN-FD and secure bootloaders.
Part I: “An intro to CAN-FD” will be held on Thursday, May 25, 5:00 PM – 6:00 PM CEST.
In this webinar CAN bus expert Andy Ayre from Embedded Systems Academy will give you a technical overview of the improvements and benefits of CAN-FD over classic CAN, and how to specifically leverage this new technology on the LPC54618 MCU.
Part II: “CAN stack porting and secure bootloaders” will be held on Thursday, June 29, 5:00 PM – 6:00 PM CEST.
Experts from Embedded Systems Academy explain the requirements for an implementation of secure and non-secure bootloaders in CAN and CAN-FD systems – leveraging the LPC546xx MCU family as an example.
With about 900 exhibitors the Embedded World reached a size where it is impossible to “see it all”. Yes, you can still walk by all booths in a day, but you might easily miss hidden highlights. It was quite obvious that IoT – the Internet of Things – is a current hype. To me this is quite astonishing as already some 10+ years ago we built an “Embedded Internet Demo” – at that time based on a Philips 8051 with a dial-up modem connected. The main difference between now and then is that now smart phones are widely spread and we are “always online” and now can access our embedded devices “at any time”. Among the visitors one could recognize a lot of skepticism for what exactly we really need the IoT, other then it being hip and cool to be able to control “everything” with our smart phone.
An unusual approach to get remote access to embedded applications was shown by Raisonance (http://www.iotize.com) – they have a miniature NFC or Bluetooth module that connect to the JTAG/SWD debug port of an application. So it can be added to any application with debug port, sometimes even without the need to re-compile the code, if you have the knowledge where in memory the variables are that you want to have remote access to. A great tool to get started with IoT without requiring a re-design of existing hardware.
At the CiA (CAN in Automation) booth a CAN FD demo integrated devices and tools from multiple vendors. CAN FD (Flexible Data) allows higher bit rates and longer contents (up to 64 bytes) of the data frame. Especially bootloader applications and other software update features benefit from the higher data throughput. For such applications it seems to be possible to increase the effective data throughout 8 fold easily, potentially even more.
We at ESAcademy further enhanced our portfolio of CANopen Diag products. There is now a second hardware, based on PEAK’s mini Display, that offers a subset of the diagnostic features provided at a price point of well below 1000 Euro. The CANopen Test Machine System part of the CANopen Diag now allows to create tests based on MS Visio graphs. The transitions in a state diagram can be used to transmit or receive a CAN/CANopen message or to influence/set/test/query variables or timers. More details and examples will be published shortly.
The new LPC4000 family of microcontrollers from NXP Semiconductors combines two powerful ARM Cortex cores in one microcontroller. The integrated Cortex-M4 and Cortex-M0 can run asymmetrically at up to 150MHz and have access to internal memory of up to 1MB Flash and 264k of RAM.
A multilayer bus matrix with 4 separate RAM blocks ensures that both microcontrollers have independent, fast access to “their” memory, minimizing wait-states.
Next to the “usual” LPCxxx peripherals the new devices also feature high-speed USB and an AES decryption engine for security.
There are several applications that benefit from a dual core solution. If a lot of communication is required, like handling complex communication protocols with specific timing requirements, a dual-core solutions allows using one core as a communication co-processor, clearly separating communication and process handling.
For more information, see NXP’s web pages.
Deutsch
English
Learn about our current product range for embedded systems
Embedded Networking with CAN and CANopen. Your technology guide for implementing CANopen devices.
Implementing scalable CAN security. Authentication and encryption for higher layer protocols, CAN and CAN-FD