Matching non-volatile memory selection to automotive-system requirements -

Matching non-volatile memory selection to automotive-system requirements

Designing vehicles has become more complex as automotive systems continue to integrate new functionality such as Advanced Driver Assistance Systems (ADAS), Graphical Instrument Clusters (GIC), HVAC, and Infotainment Systems. To ensure reliable and safe operation, each of these subsystems requires some form of non-volatile memory for storing some information during resets and power toggling. Non-volatile memories are used to store executable code or other important data like constants, calibration data, safety and security related information for future retrieval.

There are several different types of non-volatile memories in the market, including NOR Flash, NAND Flash, EEPROM (Electronically Erasable Programmable Read Only Memory), FRAM (Ferroelectric Random-Access Memory), MRAM (Magnetic RAM), and NVSRAM (Non-Volatile Synchronous RAM), among others. Each memory type has its own advantages and disadvantages over other memories in terms of different performance metrics: memory density, read/write bandwidth, interface frequency, endurance, data retention, current consumption at different power modes (active, standby/sleep, hibernate), soak time, susceptibility to external electro-magnetic interferences, etc.

To understand the real requirement of non-volatile memories in these emerging automotive systems, engineers need to consider real-world use cases like:

  • After starting a car, will drivers be willing to wait a few minutes before being able to drive for the cluster to boot-up and show the graphics related to speedometer, fuel quantity, etc.?

  • A driver has just made personal adjustment with respect to seating position, steering wheel position, temperature settings, and favorite radio channel and then has to quickly turn off the engine. How annoyed would the driver be if the car didn’t remember these settings before power to these subsystems was cut off?

  • A vehicle is in an accident despite having ADAS safety systems. Will you be able to provide the investigation team with the data they need, such as the state of different sensors the few seconds before the accident occurred?

In the case of ADAS systems, it is extremely important to capture real-time data of certain sensors instantly and store data in non-volatile memory. Similarly, Infotainment system settings need to be stored instantaneously to be able to retrieve them upon power loss.  Both GIS and Infotainment systems utilize high-end graphics and so require relative huge amounts of overlay data as part of the boot code sequence that needs to be stored and retrieved from external non-volatile memory.

Apart from meeting application-level requirements, non-volatile memories also need to ensure sufficient write-cycle endurance to log data for at least 20 years. In addition, achieve automotive grade certifications and qualifications, subsystems should also have AEC-Q100-qualified memory components.  Functional safety (ISO 26262) is another important aspect in these safety critical applications.

ADAS Memory Requirements

ADAS systems are developed to automate/adapt/enhance vehicle systems for safer and better driving. Safety features are designed to avoid accidents by offering technologies that alert the driver to potential problems or avoid collisions by implementing safeguards and taking over control of the vehicle. Adaptive features may automate lighting, provide adaptive cruise control, automate braking, incorporate GPS/traffic warnings, connect to smartphones, alert driver to other cars or dangers, keep the driver in the correct lane, or show what is in the driver’s blind spots.

Figure 1. Block Diagram of ADAS System (Source: Cypress)

Figure 1 shows a simplified block diagram of an ADAS systems utilizing FRAM and NOR Flash. External NOR Flash memory is typically used to store the boot code. However, various sensors in the ADAS system send data to the MCU at regular intervals over the CAN (Controller Area Network) interface. The MCU runs adaptive algorithms to check if there is a chance of collision or if a collision has already happened. The runtime variables of processing algorithms and the current state of the sensors are stored inside the RAM of the MCU.

When the algorithm detects an accident, the airbag control module should deploy the airbag instantaneously using backup power to ensure deployment even in the case of power-loss during an accident. The state of the sensors during the accident should also be immediately stored to non-volatile memory for data recording. This information can be extremely useful to understand the cause of an accident so that automotive manufactures can deploy more advanced safety systems and insurance companies can determine whether a particular claim is valid or not.

Event Data Recorders (EDRs) are systems which capture data of different critical subsystems just before an accident happen. EDRs can either be part of the same ADAS MCU or a different MCU that receives the critical sensor data and communicates with the ADAS MCU. Today, multicore devices such as Cypress Traveo MCUs enable an entire CPU core to be dedicated to EDR functionality.

Data captured by an EDR includes the severity of collision by measuring the force of impact from pressure sensors on the front side of the car, vehicle speed, engine RPMs, steering input, throttle position, braking status, seat belt status (for passenger detection), air-pressure in tires, warning signals, and finally airbag deployment. These data should be recorded a few seconds before and during the crash. Clearly, the MCU cannot wait for the accident to occur to begin storing these data. Thus, the MCU needs to store these data continuously. Thus, EDRs require a non-volatile memory that supports almost infinite endurance.

FRAM memory offers many advantages over traditional EEPROMs for ADAS. Critical data storage is near instantaneous, on the order of 10 us with no soak time requirement, which is critical for ADAS. EEPROM typically requires tens of ms soak time, making them unsuitable for safety critical applications. The combination of no-write delays and high clock speed makes the FRAM well-suited for applications that need to write a lot of data quickly. When using SPI, designers have complete freedom over how many bytes to write to FRAM. When a byte or two is written in random locations in an FRAM, the write cycle time is approximately 1 µs. Compare this to an EEPROM or Flash which imposes a 5 to 10 ms write cycle.

Unlike EEPROM or Flash, FRAM does not use a page buffer. FRAM writes each data byte immediately following the eighth bit in each byte received. This means engineers do not have to worry about page buffer sizes that change when the system grows to the next memory density.

In terms of write endurance, FRAM can support 1014 writes, many orders of magnitude higher than EEPROM at 106 and FLASH at 105 . Thus, FRAM can serve as a trailing data loggers where data is constantly being written.  Furthermore, FRAM requirse very low active power for write and read operations (for example, 300 µA at 1 MHz) making it suitable for ADAS where data needs to be written with a low power back-up supply or through capacitors in case of power loss due to accidents. Stand-by currents of FRAMs are also much lower (i.e., 100 µA typical) compared to other non-volatile memories.

Instrument Cluster Memory Requirements

The Instrument Cluster system displays vital information such as speed, RPM, fuel level, and engine temperature level in either digital form on a graphical display or in analog form using stepper motor controls. It also displays warning symbols such as battery warnings, temperature warning, low oil pressure warning, brake warning, safety symbols such as seat belt indicator, low tire pressure indicator, door lock indicator, head light indicator, gear shift indicator, hand brake indicator, and non-critical information such as cabin and outside temperature, trip meter/odometer readings, etc.

Recent cluster systems also include a Heads-Up Display (HUD). A HUD is an optical system that projects the driving information on the windshield of the vehicle. With a HUD, the driver can access vital information without having to look away from the traffic ahead. This decreases the potential risk of losing eye contact from the road and gives the driver extra time to identify and react to hazards. This display can include a minimal set of the most important information such as speed, navigation, and other high priority warning symbols.

Figure 2. Block Diagram of Instrument Cluster System (Source: Cypress)

Figure 2 shows a simplified block diagram of an Instrument Cluster system built around HyperRAM and HyperFlash on HyperBus interfaces and a NOR Flash on the DDR-HSSPI interface. The cluster MCU can interface with other subsystems over different communication protocols such as CAN-FD, CXPI (Clock eXtension Peripheral Interface), Ethernet AVB, and MediaLB (Media Local Bus)/MOST (Media Oriented Systems Transport) to collect the information to be displayed by the cluster.

Once the Instrument Cluster system is powered, the security engine immediately verifies the authenticity of the firmware. After this, MCU software execution starts by executing in place (XiP) from external HyperFlash over the HyperBus interface or from NOR Flash over the Double Data Rate – High Speed Serial Peripheral Interface (DDR-HSSPI). XiP functionality allows an MCU to execute code from external memory directly instead of having to first copy code from external Flash to internal RAM, thus increasing responsiveness. NOR Flash/HyperFlash memories can be configured with an initial address location of program code and power-up in Read mode after a specified number of clock delays. Thus, as soon as the MCU powers up, it can directly access the code to be executed rather than having to delay the extra clock cycles to first provide an address and read command.

Static elements can be retrieved from external HyperFlash and displayed as the base layer on the Cluster LCD. Automotive MCUs like Cypress’ Traveo support additional capabilities to decompress these static HMI elements on-the-fly without the necessity of going through RAM first. Dynamic content with faster update rates like needle information can be retrieved from external HyperRAM.

HVAC and Infotainment System Memory Requirements

The HVAC (Heating, Ventilation and Air Conditioning) system takes care of maintaining the temperature and air flow inside the cabin. Infotainment systems can run different applications similar to our mobile phones and provide a user interface to change HVAC system configurations, music system settings, enter destination information on a navigation application, change the seat/steering wheel position/heights, adjust mood lighting inside the cabin, and so on. Some of the latest automobiles integrate a fingerprint reader as well to authenticate and identify the driver. This allows the HVAC and Infotainment systems to quickly adjust the cabin to a driver’s preferred settings.

Figure 3. Block Diagram of HVAC and Infotainment Systems (Source: Cypress)

Figure 3 shows a simplified block diagram of the HVAC and Infotainment system with all memory elements interfaced to the main MCU.  Here, we have 3 additional subsystems compared to the Instrument Cluster system:

  • Touchscreen controller to detect finger touches on the display

  • Heater/air-conditioner to control the cabin temperature

  • Connectivity subsystem to enable connectivity options within the car (Bluetooth, GPS, WiFi, GSM, FM Tuner, etc.)

HyperFlash and HyperRAM memories are used to support high-quality Graphics. NOR Flash is used for boot code storage and FRAM is used to store settings information so that even if the car is turned-off and turned-on immediately, cabin settings can be reliably retrieved.

Memory Interfaces

Now that we have discussed the requirements for non-volatile memories in different Automotive segments, let’s understand the different interfacing mechanisms between these memories and MCUs.

Any MCU with a SPI interface can easily access NOR Flash. NOR Flash devices like Cypress’ S25FL256L provide SPI with multi-I/O options that support both Double Data Rate (DDR) and Quad Peripheral Interface (QPI) options. Multiple Flashes can also be connected on the same bus and be independently accessed using the Chip Select (CS) signal.

Figure 4. NOR Flash Memory Interface over Quad SPI (Source: Cypress)

Figure 4 shows the hardware connections between MCU and NOR Flash. Low-Level Driver (LLD) software can be used by the MCU to read, program, and erase NOR Flash memory. The design architecture is optimized for fast access time and program speed. Note that the internal technology used within the NOR Flash determines the density of the memory. NOR Flash utilizing traditional Floating Gate technology stores 1 data bit per cell storage over a conductive layer. NOR Flash built on an insulator layer such as MirrorBit technology can store 2 data bits per cell, thus providing a lower cost structure for densities greater than 256 Mb.

Figure 5. FRAM Memory Interface over SPI (Source: Cypress)

Figure 5 shows how a simple SPI interface can be used to access FRAM. For microcontroller-based systems that require high serial data rates, the SPI interface is an ideal choice. Serial data throughput correlates to the serial clock speed. Serial FRAMs can be clocked at up to 40 MHz. Microcontrollers that do not have a dedicated SPI port can alternatively “bit bang” through GPIOs.

HyperFlash and HyperRAM can be accessed using a HyperBus 12-signal interface. HyperBus provides about 4 times higher read throughput up to 333 MBps compared to Quad-SPI (66.5 MBps) with one third the number of pins required for parallel NOR Flash. This interface uses differential clocking (CK, CK#), Read/Write Data Strobe (RWDS), Chip select, and and 8-bit data bus.

Figure 6: HyperBus Interface between Memory or Peripherals (Source: Cypress)

Data Integrity and Security

Data Integrity and security are two important aspects in choosing memories for automotive applications. Today’s memories offer a variety of features to improve data integrity and security. For example, Advanced Sector Protection (ASP) offers greater resolution for locking sectors along with different power-on reset behaviors and assists in implementing secure boot code. At a basic level, ASP is simple. Any sector can be locked to prevent programming and erasure. There are two ASP methods to lock a sector: Persistent Protection Bits (PPB) and Dynamic Protection Bits (DYB) protection. These two methods can be used together and in addition to Block Protection (BP) and/or WP# pin hardware protection method.

Automatic Error Correction Code (ECC) functionality operates transparently with normal program, erase, and read operations. As the device transfers each page of data from the write buffer to the memory array, internal ECC logic evaluates the ECC Code for the page into a portion of the memory array that is not visible to the host system. The device evaluates the page data and the ECC Code during each initial page access to verify the page’s integrity. If needed, the internal ECC logic corrects one-bit errors during the initial access.

NOR Flash also provides an extra flash memory area that can be programmed once and permanently protected from further changes. In the case of Cypress’ FL-S NOR Flash family, this One Time Program (OTP) array is on the order of 1K and consists of 512 bytes for Factory Locked Secure Silicon Region and 512 bytes for Customer Locked Secure Silicon Region.


Today’s automotive systems require a wide array of memory options that offer different reliability, responsiveness, and throughput to meet the individual needs of each of the many vehicle’s subsystems.  By selecting the right mix of memories, engineers can ensure reliable and safe operation of the vehicle while meeting the responsiveness expectations of drivers.


Mahesh Balan earned his BTech in Electronics and Communication Engineering from Model Engineering College. He is currently working on PSoC 3/4/5LP based projects andassisting PSoC users with their designs.

Kishore Kumar ( works as a Sr. Staff Applications Engineer at Cypress Semiconductor focusing on Automotive Capacitive sensing Buttons & Touchscreen controllers, Fingerprint, MCU products. He holds a Bachelor’s degree in Electronics and Communications Engineering from College of Engineering, Guindy.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.