Dwell into this blog to know how to do CAN communication with automotive microcontroller. Start your journey to learn CAN communication protocol with simple DIY project using ElecronicsV3 board and CAN analyzer tool
Add Your Heading Text Here Understand about protocol data unit in can Hardware Transmit Object
Overview and motive Objective is to: To get to know what is FlexCAN driver and its features. To Understand How to use FlexCAN Driver(software environment setup and chronology in software configuration)). FlexCAN Driver GUI explanation for configuring FlexCAN Peripheral. Relation of functions of FlexCAN Driver functions via FlexCAN peripheral features. In Depth Understanding of FlexCAN driver functions/data types, with questions like What and why? Chronology of APIs for using basic features of FlexCAN Peripheral for doing CAN communication(How and When?) By basic features we mean the CAN transmission and reception via Mailbox and FiFo mechanism using polling&Interrupt method. What is FlexCAN Driver FlexCAN Driver are set of libraries which are used for using FlexCAN peripheral to do CAN communication via NXP S32K1xx Microcontrollers. Here by library, we mean a set of .h and .c files written in c language. These set of FlexCAN libraries are: Library of FlexCAN Peripheral Hardware registers. Library for FlexCAN Peripheral Interrupt Handlers. Library for FlexCAN peripheral API’s. Miscellaneous files for FlexCAN. Now in FlexCAN Driver there are 3 sets: FlexCAN_Ip.h/.c FlexCAN_Ip_Hw_Access.h/.c FlexCAN IP_Irq.h/.c 3 extra header files: FlexCAN_Ip_DeviceReg.h/FlexCAN_Ip_Types.h/FlexCAN_Ip_Wrapper.h: The first one contains the function and data types through which different features of FlexCAN peripheral are used. Features like of sending data, receiving data, configuring message id filter table and etc. It contains functions like: FlexCAN_IP_Send(). FlexCAN_IP_receive, FlexCAN_IP_RXFIFO and etc. The Second one also contains the functions and data types through which FlexCAN Peripheral registers. Are accessed. Kind of like Bare Metal codes of FlexCAN peripheral are written in this files. And the Functions of this file are used by FlexCAN_Ip.h/.c files. Third one contains the function definition and data types for for IRQ handler of FlexCAN Peripheral And the last one contains the misceeleneours Data types and macros for using flexCAN peripheral. In our application code, we are just going to add FlexCAN_Ip.h header file to access the FlexCAN Driver in our code. And these files are located in the root directory of S32 DS where software installtion of RTD package takes place. FlexCAN Driver and Code Configuration tool relation. Now for using the FlexCAN peripheral, there is a feature of code configuration tool in S32DS via which we can configure the FlexCAN Driver in Gui base. That is instead of writing code, we can confiure how to use FlexCAN Module by GUI presentation. The code configuration tool in S32 Design Studio, generates the set of .c/.h files for FlexCAN peripheral. These are different from library files which I have explained above. In these generated files it defines and initializes some of the variables. These variables are then used by FlexCAN APIs in the application code. This support of code configuration tool makes it easy for configuring FlexCAN module in easy way via GUI presentation and variables which are generated by code configuration tool are used as parameters in FlexCAN APIs to use them in application code. So, in short to say, code configuration tool generates the values of some of the parameters that has to be send in FlexCAN Driver API. Closure of FlexCAN Driver: There are number of files, functions and data types but for now we are going to concentrate on those which will be required for using FlexCAN in Standard CAN, in normal mode for transmitting and receiving via mailbox and FiFo mechanism. In FlexCAN library there are number of functions and data types through which all the features of FlexCAN peripheral can be used. But we are not going to dwell into all functions and data types. We are just going to cover the functions and data types through which we can send and transmit can data via mailbox/rxfifo mechanisms. As this is the scope of this course and module, for other functions and features you can explore our Advance CAN Courses or can reach out to us privately, Software to install to use FlexCAN Peripheral Driver To use FlexCAN Peripheral Driver, we need to install following things in your Host Desktop/PC: S32 Design Studio IDE 3.4 or 3.5 (any will work though here, we are going to use S32 Design Studio 3.4) S32K1 Real Time Drivers Version 1.0.0 S32 Design Studio 3.4 S32K1 Real Time Drivers Version 1.0.0 S32K1 RTD V1.0.0 is Software Stack for using NXP S32K1xx microcontrollers. It Contains Peripheral Driver library files for using the S32K1xx microcontroller peripherals. It supports all peripherals of S32K1xx MCU’s. This Software Stack contains 2 packages: Autosaur MCAL layer complaint and standard based peripheral driver files for S32K1xx MCU’s. It is Autosar 4.4.0 complaint. Non-Autosar based peripheral driver files for S32K1xx MCU’s. It is a collection of peripheral drivers designed to simplify and accelerate application development on NXP microcontrollers. From Learning point of view and long-term skill development, having handson with Autosaur MCAL layer based peripheral driver file would be a good starting point. But as a fresher it might be more challenging to start with autosar standard. So In this blog, we are going to explore Non-Autosar based peripheral driver for FlexCAN module. Further once having basic Handson with Non-Autosar, will explore Autosar MCAL layer based peripheral driver. Refer to this blog/video to get to know how to install S32 Design Studio 3.4 and Install S32K1 Real Time Drivers v1.0.0. Also it is recommended to explore Code Configuration Tool and Project Creation Modules of S32 Design Studio IDE, so as to get understanding how to use S32 Design Studio throughout the learning cycle. How to use FlexCAN Peripheral Driver FlexCAN Driver can be used via S32 Design Studio Code Configuration tool which provides Graphical User Interface manner in S32 Design Studio IDE, through which we can generate the FlexCAN driver libraries and code automatically in our project. This thing makes it easy to develop applications fast and easy way. The Code Configuration tool generates 2 things: Library Files to use FlexCAN Peripheral. Configured parameters in the form of Data Types (structures, macros, arrays and etc.), which are used as input parameters in different functions of library files. Chronology to follow
Motive To know about CAN peripheral in S32K144 Microcontroller, in terms of functional description and block diagram. To understand how FlexCAN peripheral works in NXP S32K144 MCU’s.( concept of message buffer, mailbox, fifo, meesage id table )(Done) To know how to use CAN peripheral by state machine diagrams. Picking different feature points and explaining their state machines.( Not Right now) To mention FlexCAN features and specs and giving just small brief. To use CAN protocol in NXP Semiconductors S32K1xx Microcontroller’s, there is a peripheral present in S32K1xx series of MCU: The Flex CAN Module. The FlexCAN module fully implements the CAN protocol specification, including the CAN with Flexible Data rate (CAN FD) protocol and the CAN 2.0 version B protocol. It supports both standard and extended message frames, as well as long payloads upto 64 bytes in the case of CAN FD. FlexCAN Module is a peripheral in NXP S32K series of Microcontrollers. All NXP S32K1 and S32K3 microcontrollers have same module FlexCAN which is to be used for doing CAN communication via these microcontrollers. FlexCAN is IP of NXP Semiconductors, that is used in their Automotive Microcontrollers as a microcontroller peripheral which is used for CAN communication. NXP S32K1xx and S32K3xx series of microcontrollers are used in making car ECU’s. In car ECU’s we often have to do the CAN communication for data transfer between 2 ECU nodes. In those cases FlexCAN module is used to do communication via CAN protocol. To know about how CAN communication is done via microcontrollers will recommend reading previous blog: CAN protocol in embedded. What is FlexCAN Module FlexCAN Module is a Microcontroller peripheral in NXP Semiconductors S32 series of microcontroller for doing CAN communication via CAN protocol. S32 series have number of microcontrollers, for understanding we are going to refer S32K144 microcontroller, as this blog series is specific to S32K144 MCU. There can be multiple instances of FlexCAN module in a microcontroller. Like in S32K144 MCU it has 3 instances of FlexCAN module, whereas in S32K344 has 5 instances of FlexCAN module. By instance we mean, number of counts. So, in S32K144 we have 3 FlexCAN modules, meaning 3 communication channels of CAN be done via S32K144. In S32K344 we have 5 FlexCAN modules, meaning 5 communication channels can be done via S32K344. Previous slide Next slide Now for doing CAN communication, FlexCAN module would be using CAN pins of the microcontroller to physically transmit and receive CAN data. The CAN pins are termed as CAN_Rx-CAN_Tx pins in the case of S32K144 MCU and FlexCAN_Tx-FlexCAN_Rx in the case of S32K344 MCU. CAN_Rx & FlexCAN_Rx for receiving pins and CAN_Tx & FlexCAN_Tx for transmitting pins. Each FlexCAN instance in a microcontroller might have different features. Like in S32K144, FlexCAN module 0 has 32 Message buffers, while FlexCAN module 1 and 2 have 32 message buffers. Each Instance of FlexCAN has their own FlexCAN peripheral registers. Which starts at mentioned address of microcontroller memory. These address are named as FlexCAN instance base address. Now which pin to use via which instance is logically mapped as per numbering. FlexCAN0 would be using CAN0_Tx and CAN0_Rx pins. FlexCAN1 would be using CAN1_Tx and CAN1_Rx pins and so on. Now further for each CAN instance there are number of pins available. Meaning let’s say we want to use FlexCAN module0 of S32K144 MCU. For that we will be using CAN0_Tx and CAN0_Rx pins. CAN0_Tx and CAN0_Rx pins can be mapped to number of pins of microcontroller. As shown in Figure We have to set the alternate function registers of the microcontroller to configure the pin that we want to use for corresponding Instance. This pin configuration part is handled by Port Peripheral of the S32K144 Microcontroller. For setting the speed of communication of FlexCAN module, we have to configure its clock and baurate settings. The Clock to FlexCAN module is fed from Clock peripheral of MCU and then FlexCAN module baudrate can be set by application as per their requirements. Block Diagram of FlexCAN Module FlexCAN peripheral block diagram understanding Working of FlexCAN Module FlexCAN module implements the CAN protocol according to the ISO 11898-1 standard and CAN2.0B protocol specifications. CAN 2.0B protocol specification defines the properties and features in CAN protocol (Standard CAN and Extended CAN) and ISO-11898-1 standard specifies how outgoing and incoming CAN data should be managed so that CAN properties are achieved. In FlexCAN module, message buffer space is being termed as Embedded RAM. Both Terms would be used interchangeably throughout the blog. FlexCAN peripheral has a fixed Embedded RAM Space which is used to process the CAN data. In S32K1xx Microcontroller’s, the Embedded RAM is of 512 bytes.( Explain for chapter of can peripheral register where address range of message buffer is specified) Each FlexCAN instance in S32K144 MCU has their own Message buffer, but they are of different sizes.( explain from instance feature difference table and then comparing that to above point statement) FlexCAN instance 0 has 512 bytes and FlexCAN instance 1&2 has 256 bytes of Embedded RAM. The Embedded RAM in FlexCAN Peripheral space starts from address of 0x0080 offset of corresponding FlexCAN instance base address. Embedded RAM space is from 0x080-0x280 memory address in case of FlexCAN module 0 and from 0x080-0x180 in case of FlexCAN module 1&2. For FlexCAN Instance 0 message buffer starts at: 0x40024080, FlexCAN instance 1 message buffer starts at 0x40025080 and for FlexCAN instance 2 message buffer starts at 0x4002B080 Now if we zoom in to Embedded RAM space, its is divided by offset of 4 bytes. As Shown in figure. Further, if we zoom in to write/read on Embedded RAM it has a structure, according to which CAN data frame is written/read into it. It is called Message Buffer Structure. We will get into it in message buffer structure section. MailBox Mechanism If we have Standard CAN frame, in which we are sending 8 bytes of payload data, so according to above message structure it is gonna occupy 16 bytes of space.
Motive: To get understanding of what Port Driver in Autosaur MCAL Layer stack do: Done: What is Port Driver in Autosaur? To get understanding of Different Functions and Data Types in Port Driver Module: Their description, their description with respect to parameters that are send to them, and how are those paramters configured via tool. How to configure different pins in autosar, using Port Driver Module. To get familiarity with Usecases and how to use different Port Driver Module APIs in what chronology. Autosar Documentation blogs: Understanding AUTOSAR and its Applications in the Automotive Industry (einfochips.com) AUTOSAR_SWS_BSWGeneral.pdf : This document explains the BSW layer configurtaion What is Port Driver in Autosar? Port Driver is Part of MCAL Layer in BSW layer of Autosar Stack. Port Driver is responsible for initializing and configuration of microcontroller pins and corresponding ports of those pins. Only Initilization part and configuration part. It initializes and configures pins and ports for various functionalities like: ADC, SPI, I2C, Ethernet, PWM and etc. According to alternate function pin mapping configurations of microcontroller. The Pins and ports which are configured by Port Driver Module, are used by the DIO (Digital Input/Output) Driver module. Only the pins and ports which are configured by Port Driver will be used by DIO Driver Module. Port Driver Module Provide following important functional specifications: Direction setting of Microcontroller pins (Input/Output). Initial value setting of microcontroller pin. Activation of Internal Pull-ups for microcontroller pin. Slew Rate control for microcontroller pins. Microcontroller Alternate function/GPIO registers are used by this layer. Important Data Types in Port Driver: Port_ConfigType: Port_PinType: Port_PinDirectionType: Port_PinModeType: Important Functions in Port Driver: Port_Init : Port_SetPinDirection: Port_RefreshPortDirection: Port_SetPinMode Documents to refer for Port Driver. AUTOSAR_SWS_PortDriver.pdf : This specification specifies the functionality, API and the configuration of the AUTOSAR Basic Software module PORT Driver. Important points of Port Driver? This PORT driver module completes the overall configuration and initialization of the port structure which is used in the DIO driver module. Therefore, the DIO driver works on pins and ports which are configured by the PORT driver. Important Data Types in Port Driver: Port_ConfigType: Port_PinType: Port_PinDirectionType: Port_PinModeType: Port_PinConfigType: Port_UnUsedPinConfigType: Port_Ci_Port_Ip_DigitalFilterConfigType: Port_Ci_Port_Ip_PinSettingsConfig: Port_ConfigType: Port_PinType: Port_PinDirectionType: Port_PinModeType: Port_ConfigType: It is a structure, which contains different contents to initialize the pin of the microcontroller as per user configuration. This Structure is used only in Port_Init() API. And the contents of this structure are changed automatically as we change the configurations in PORT Driver in .ebtresos. //This part has to be written more( Explain use configuration examples) Here by user configuration we mean: Input/Out direction, pull up enable or disable and etc. This structure contains the contents which are used for initialization of microcontroller pin. As the initialization of microcontroller pin is different in SoC’s. So, this structure has different contents from SoC to SoC and its content dependent on GPIO/DIO peripheral registers of corresponding microcontroller. S32K3xx typedef struct { uint16 u16NumPins; /**< @brief Number of used pads (to be configured) */ uint16 u16NumUnusedPins; /**< @brief Number of unused pads */ uint16 au16NumImcrs[PORT_NUM_SIUL2_INSTANCES_U8]; /**< @brief Used pads IMCRs number */ const Port_Siul2_UnUsedPinType *pUnusedPads; /**< @brief Unused pad id’s array and SIUL2 instance */ const Port_Siul2_UnUsedPinConfigType *pUnusedPadConfig; /**< @brief Unused pad configuration */ const Port_Siul2_PinConfigType *pUsedPadConfig; /**< @brief Used pads data configuration */ const Port_Siul2_ImcrConfigType *pImcrConfig[PORT_NUM_SIUL2_INSTANCES_U8]; /**< @brief Used pads IMCR configuration */ const uint32 *pau32Port_PinToPartitionMap; /**< @brief Pointer to pin partition mapping */ const uint8 *pau8Port_PartitionList; /**< @brief Pointer to used partitions */ const Siul2_Port_Ip_PinSettingsConfig *IpConfigPtr; /**< @brief Ip configuration */ const Tspc_Port_Ip_ObeGroupConfig *TspcIpConfigPtr; /**< @brief tspc configuration */ } Port_ConfigType; S32K1xx typedef struct { uint16 u16NumPins; /**< @brief Number of used pads (to be configured) */ uint16 u16NumUnusedPins; /**< @brief Number of unused pads */ const uint16 * pUnusedPads; /**< @brief Unused pad id’s array */ const Port_UnUsedPinConfigType * pUnusedPadConfig; /**< @brief Unused pad configuration */ const Port_PinConfigType * pUsedPadConfig; /**< @brief Used pads data configuration */ uint8 u8NumDigitalFilterPorts; /**< @brief Number of configured digital filter ports */ const Port_Ci_Port_Ip_DigitalFilterConfigType * pDigitalFilterConfig; /**< @brief Digital filter ports configuration */ const uint32 *pau32Port_PinToPartitionMap; /**< @brief Pointer to pin partition mapping */ const uint8 *pau8Port_PartitionList; /**< @brief Pointer to used partitions */ const Port_Ci_Port_Ip_PinSettingsConfig *IpConfigPtr; /**< @brief Ip configuration */ } Port_ConfigType; For now, we will focus on data structure elements of S32K1xx. u16NumPins : Number of pins which are configured u16NumUnusedPins : Number of unsused pins left( uint16 * pUnusedPads: const Port_UnUsedPinConfigType * pUnusedPadConfig: Port_PinConfigType * pUsedPadConfig: u8NumDigitalFilterPorts: Port_Ci_Port_Ip_DigitalFilterConfigType * pDigitalFilterConfig uint32 *pau32Port_PinToPartitionMap: uint8 *pau8Port_PartitionList: Port_Ci_Port_Ip_PinSettingsConfig *IpConfigPtr: Port_PinType: Use for symbolic name of a Port Pin. Sybolic name is the pin count of that pin. Port_PinDirectionType: Tab Content Port_PinModeType: Tab Content
https://youtu.be/N6w_xWoOH-Q Overview In this blog, we will get to know how to use FreeMaster Desktop Application Via S32 Design Studio. for NXP Semiconductors S32 automotive Microcontrollers. We Will be using ElecronicsV2 Development Board which has ARM Coretx M4 Processor based Automotive Microcontroller: S32K144 The objective of this blog series is to teach people on how to use FreeMaster Desktop application: which is a great tool for run time debugging, as it provides run time debug monitor(Oscilloscope, Watch Grid, sending 2-way commands) and data visualization (Creating animated GUI pages). The best part about this is that real time debugging and tracing can be done without any expensive or heavy debuggers (SWO/Jlink/JTAG/Lauterbach/PEMicro or etc) and that too on interesting GUI pages. One can Interface FreeMaster with our Target Development Board (ElecronicsV2/AutoboardV1), via UART, CAN, ProBug Jlink Debugger or even over TCP/IP network. To know more about FreeMaster: what is it, why it should be used and its features. Checkout This Blog: FreeMaster Debugging Tool – Get To Byte This is getting started blog to learn and teach how to use FreeMaster Desktop Application. Initially we will be using it via UART and ProBug Debugger. In later blogs and stages, we will be interfacing it via CAN, TCP/IP and exploiting many other features of FreeMaster. Subscribe yourself to get notified Blog will be out on 20th of June 2024. Right Now, blog is under development, so subscribe yourself from below button and tell us about your use-cases so that we can customise blogs according to your needs. Subscribe
Add Your Heading Text Here Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Overview So, hello guys, welcome to gettobyte platform. Continuing our Automotive technology series. In today’s blog we are going to start with Autosar technology of Automotive Industry. In the last blog, of automotive technology series we have get to know about Autosaur Technology. Now from this blog we will start with Handson activity and skill-based learning on Autosaur Technology using MCAL Layer. We will be mainly focusing on practical learning on Autosar, for theoretical understanding and concepts, will share necessary links and resources. What is Autosar Autosar is Software standard that has been standardized to write Software for automotive vehicles. Here by software, we mean by embedded software that is programmed in microcontrollers to develope automotive electronics/electrical sub-system. Autosaur has various layers in it, to know in detail about each of these layers and their role, explore/check out the last blog, or watch this video. To start with Autosar technology as a hobbyist and with DIY implementation, the easiest way is to start with the MCAL (Microcontroller Abstraction Layer) layer of Autosar technology. What is MCAL Layer? MCAL Layer is the closest layer to the microcontroller, and it is kind of like Real Time Driver (RTD) for all the peripherals of the Microcontroller in autosar software standard. Using this layer only, embedded software’s for automotive vehicles are developed. Those who don’t know, Real Time Driver (RTD) are software stack in microcontroller world to use microcontroller peripherals. For automotive application this Real Time Driver (RTD) Terminology is being referenced as MCAL(Microcontroller Abstraction Layer). To know more about software stacks used in microcontroller checkout this blog.To know about different kind of automotive embedded applications, checkout this blog. Now what Autosaur technology has done is that whatever automotive embedded application we are developing, RTD (Real Time Driver) files that will be needing to develop application code would be same irrespective of microcontroller whether it is on NXP, Infineon, Renesas or etc. So, each microcontroller company has to make the Real Time Driver for their Microcontroller up to the MCAL layer standard so that their microcontrollers can be used for automotive applications. To know about microcontroller, checkout this blog. So it also means, that doing handson with MCAL layer for any one microcontroller, it will give us basic/intermediate level of learning, understanding and knowledge to build different applications according to autosar software standard. And this is what we are going to follow. Strategy to learn autosar technology Autosar technology is a very important skill for job seekers in the automotive industry. Be it a working professional, college student or fresh graduates, having the skill set of autosar technology in their resume makes them outstand. But there are certain challenges in learning autosar technology. For learning autosar technology an automotive microcontroller is required so that we can make DIY and practical automotive projects using autosar software stack. Thus, what we are going to follow is we will learn and do Hands-on with MCAL layer of automotive Microcontrollers, for building automotive applications and the MCAL layer stack is provided by respective microcontroller companies. As Only for automotive microcontroller’s MCAL layer is available. MCAL layer is not available for General Purpose microcontroller like that of: STM32, ESP8266/32 and Arduino Uno boards. So, to use MCAL layer first requirement is to have a microcontroller and its development readily available. Here come’s the ElecronicsV2 development board. ElecronicsV3 board, which is development board for developing automotive applications/projects using autosar software stack It is low-cost Automotive, development board based on S32K144 automotive Microcontroller. Comes at cost of 5000 INR. In autosar technology as told there are many layers, as told in what is autosar section. So, to use and configure layers above MCAL layer, there are specific code configuration tools and IDEs for using autosar Stack. These tools are provided by companies like: Electrobit, Mentor Graphics, Vector and etc. But these tools are very expensive. Thus, what we are going to do is we will start from MCAL layer, as MCAL layer code configuration, generation and development can be done by IDE which are provided by microcontroller companies. Thus, for elecronicsV2 development board which has NXP semiconductors S32K144 Microcontroller there is S32 Design Studio IDE in which we can do full MCAL layer configuration, generation and development. Using MCAL layer we will develop different application by interfacing different automotive sensor/modules to ElecronicsV2. By this way we will be able to make automotive applications using MCAL layer that will give us exposure to autosar software architecture Tools Needed Hardware We will be doing this activity using NXP Semiconductor S32 Microcontroller family. NXP S32 family of Microcontroller, are automotive grade MCU’s for which NXP provides full MCAL layer support for all of its S32 MCU’s. To know more about NXP S32 Family of Automotive Microcontroller/Microprocessor, checkout this blog. One such microcontroller of NXP is S32K144, for which gettobyte has developed a cost friendly and easy to use development Board ElecrronicsV2. We will be using this Development Board (ElecronicsV2) and Microcontroller(S32K144) through-out our Autosaur learning series. To know more about elecronicsV2 board and S32K144 Microcontroller, checkout this blog. And for programming and debugging the ElecronicsV2 board, we will be needing a debugger. JlinkV9 debugger is what we are going to use initially, but soon in upcoming time, gettobyte will be coming up with its own Jlink debugger. That will be updated soon. To know more about Debuggers in microcontroller world, checkout this blog: Mastering the Art of Debugging Technology in Microcontrollers So before continuing further will recommend buying the elecronicsV2 board and JlinkV9 debugger from below links: 1) ElecronicsV2: Arduino of automotive world. 2) JlinkV9 Debugger: Universal Debugger for all ARM Based MCU’s. Software In terms of Software, we will be needing an IDE (Integrated Development Environment) to develop embedded software on microcontroller. For that we will be using S32 Design Studio, which is dedicated IDE for NXP S32 Automotive Microcontroller’s. For the Installation of S32 Design Studio and guide on it, refer to following playlist on my YouTube Channel: NXP Semiconductors S32 Design Studio – YouTube.
What is CSEc Peripheral CSEc is a microcontroller peripheral in NXP Semiconductors S32K1 series of Automotive MCU’s. CSEc peripheral is a security subsystem, which is based on SHE standard for doing cryptographic operation and establishing secure communication between the ECUs in the car. Security subsystem is a dedicated subsystem within an IC (Microcontroller or SoC) through which we can perform cryptographic operations in microcontroller and protect cryptographic keys from the software attacks. Broadly there are 2 types of security sub-systems in a microcontroller for doing cryptography operations: Secure Hardware Extension (SHE) Hardware Security Module (HSM) The security-subsystem, which we are discussing in this blog: CSEc Module, is based on SHE standard security sub-system. That means using the CSEc peripheral present in S32K144 MCU, we can perform symmetric crypto operations and secure up to 17 user keys. To know more about the SHE standard, refer to this blog. Configuration of CSEc peripheral As CSEc peripheral is SHE standard based security-subsystem and in SHE standard all the controlling of the crypto algorithms and operation’s is done via finite state machine or small CPU core. In S32K1 series, it is done via finite state machine thus the control logic for using CSEc peripheral is command wise. There are commands specified for doing crypto operations according to HIS-SHE specification version 1.1 We just need to specify which command to send, and corresponding crypto operations are executed. (make a graphic showing state machine, she specification and commands with elecronicsv2 and s32k144 photo) The state machine algorithm to use CSEc peripheral is implemented in FTFC module of the S32K1 MCU’s. FTFC is a Flash memory module which is a Hardware IP in S32K1 series of MCU which is used to modify flash memory contents. Flash memory configuration, initialization and all other things are done by FTFC module. Will deep dive into FTFC module in separate blog. For now, to use CSEc peripheral, features have been added to the FTFC module to support SHE functional specification version 1.1. The FTFC module enables encryption, decryption, CMAC generation-verification and algorithms for secure messaging applications. Additional APIs are also available for Secure Boot configuration, True Random Number Generation (TRNG) and Miyaguchi-Prenell compression. The FTFC core takes care of the flash as well as CSEc functionalities. So, to use CSEc peripheral, we need to configure FTFC module. This configuration is flash memory partitioning, we need to partion the flash memory to emulated EEPROM. By doing so, the FTFC module enables encryption, decryption and CMAC generation-verification algorithms for secure messaging applications. The user can configure the FTFC module for emulated-EEPROM operation by issuing a Program Partition Command (PRGPART). The PRGPART command provides flexibility to specify the partition size between emulated-EEPROM operation and normal operations as per user’s wish. To enable CSEc functionality, the device must be configured for emulated-EEPROM operation. The PRGPART command is used to enable CSEc and also provides a mechanism to specify the key size. Depending on the key size, the last 128/256/512 bytes of EEERAM are reduced from the emulated- EEPROM and become un addressable (so as corresponding EEPROM –backup). This storage is secured and utilized to store cryptographic keys. Once the user configures the FTFC module for CSEc functionality and loads the user keys for the security operations, the device is ready for any security related operations as described in the HIS-SHE specifications. //Show practical codes/API and working of flash memeory partionining // understand abput how memory configuration is being done, what size is done and what size is left and which API is used //How to check CSEc peripheral is configured and memory partioning is done. Crypto operation command using CSEc Okay so now once CSEc is being configured and initialized for use now let’s dwell into how to do crypto operations with it. CSEc peripheral uses command-based programming interface. Crypto operations like Encryption, decryption, loading keys, generating keys and etc. all are done via commands. These commands are handled by CSEc PRAM interface. CSEc PRAM interface is a memory area of around 128 bytes. which is divided into 8 sections. Each section is termed as page here. Starting from page 0 to page 7. Each page of 16 bytes. As shown in below pic. So, we send the command by writing it on page 0 according to the command header specified below and with the command some additional information required by that command and in return we get the result on pages 1-7. The Structure of the command header is standard for all the commands, command header is divided into 6 bytes. –> FuncID: Function Identification (ID) field is a 1 bit long and specifies the security command to be executed. Valid from 0x00 to 0x16. In the code enum One can relate CSEc PRAM interface as a Sheet. That sheet is divided into 8 horizontal lines are. Terminologies to refer to these lines is pages. So their are total 8 pages, starting from page 0 to page 7. Now in first page 0, we write the command In the above image, first page Page 0, includes the command header (Page 0, Word 0) and message control length (Page 0, Word 3). The rest of the pages are utilized for input/output data information. Writing to the command header triggers the macro to lock the CSEc PRAM interface and start the CSEc operation. Hence, to setup a CSEc command, the user should first enter data information followed by message length information and must write command header last. Cryptographic Keys in CSEc Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Cryptographic ciphers in CSEc Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Cryptographic Operations in CSEc Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Features of CSEc Peripheral Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. CSEc Peripheral has following