Search
Large amounts of data are stored and processed.
Large amounts of data are stored and processed.
( Source: gemeinfrei / Unsplash)

data capacities Memory requirements of automotive systems

| Author/ Editor: Mahesh Balan and Kishore Kumar * / Florian Richert

Networking, comfort, safety: The demand for high-quality storage systems in modern vehicles is rising rapidly. But which type is best suited for which application?.

The design of automobiles is becoming ever more complex as they are given more and more functions, such as driver assistance systems (ADAS), graphic dashboard units (GIC), air-conditioning and infotainment systems. Each of these subsystems requires non-volatile memory, for example, to store information during a reset or when switching the power supply, thus ensuring reliable and safe operation. The non-volatile memory contains, for example, executable code or other important data such as constants, calibration data and safety-relevant information that is to be retrieved at a later point in time.

Large, reliable, safe and fast: Automotive systems demand high performance from integrated memory modules.
Large, reliable, safe and fast: Automotive systems demand high performance from integrated memory modules.
(Image: Cypress Semiconductor)

There are different types of non-volatile memory, such as 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). Each memory type has advantages and disadvantages in terms of performance criteria such as memory density, read/write bandwidth, interface frequency, rewritability, data retention, power consumption in the various operating modes (active, standby/sleep, hibernate), waiting time, sensitivity to external electromagnetic interference, etc. To understand the real non-volatile memory requirements in these new automotive systems, engineers need to consider real-world applications:

  • Hardly any driver will be willing to wait for minutes before driving off because, after boarding, the dashboard has to boot to display the speedometer, fuel gauge, etc. graphs.
  • A driver has set the positions of the seat and steering wheel, the temperature and his favourite radio station on the radio. The vehicle must save this configuration before switching off the power supply to the subsystems. A loss of the settings would be uncomfortable and annoying for the driver.
  • A vehicle is involved in an accident even though it is equipped with driver assistance systems. The driver or car should be able to provide important data for accident detection, such as the status of various sensors in the seconds before the accident.

With driver assistance systems, it is extremely important to capture the data of certain sensors in real-time and store it permanently in the non-volatile memory. Similarly, the settings of the infotainment system must be instantaneously stored so that they are not lost in the event of a power failure. Both GIS and infotainment systems work with high-quality graphics and therefore require large amounts of overlay data that are part of the boot sequence and are stored and read from an external non-volatile memory.

In addition to application-level requirements, non-volatile memory must also have sufficient rewritability to log data over a period of at least 20 years. In addition, subsystems should be equipped with memory components certified to AEC-Q100. Only then can they obtain the certifications and qualifications required in the automotive sector. Functional safety (ISO 26262) is another important aspect of safety-critical applications.

Requirements for the memory of driver assistance systems

Among other things, driver assistance systems should help prevent accidents. The integrated safety functions, for example, draw the driver's attention to too short a distance. In hazardous situations, the functions implemented can also (temporarily) take control of the car and, for example, initiate emergency braking. But they also provide support during normal driving. Adaptive functions can, for example, automatically switch on the headlights, regulate driving speed, automate braking, transmit warnings from GPS and traffic radio, connect to smartphones, alert the driver to other vehicles or hazards, keep the vehicle in the lane or even monitor the "blind spot". All these functions use non-volatile memory.

Figure 1: Block diagram of a driver assistance system
Figure 1: Block diagram of a driver assistance system
(Image: Cypress Semiconductor)

Figure 1 shows a driver assistance system in which FRAM and NOR Flash are used. External NOR Flash is usually used to store the boot code. Various sensors in the driver assistance system send data at regular intervals via the CAN bus (Controller Area Network) to the microcontroller unit (MCU). Using adaptive algorithms, the MCU determines whether there is a risk of collision or whether it has already occurred.

The runtime variables of the processing algorithms and the current status of the sensors are stored in the RAM of the MCU. If the algorithm detects an accident, the control module must immediately trigger the airbags with power from the backup system. This ensures that the airbags are triggered even if the normal power supply fails. The status of the sensors during the accident should also be stored immediately in a non-volatile memory. This information can be extremely valuable for later determining the cause of the accident. Automobile manufacturers can use this data to improve their safety systems.

Recording important data in the event of an accident

Event Data Recorders (EDR) are systems that collect data from important subsystems immediately before and upon the occurrence of a critical event. EDR can be part of the same ADAS MCU - or another MCU that receives the sensor data and communicates with the ADAS MCU. Multi-core chips such as the Cypress Traveo MCU can dedicate one core to the EDR function. The data collected by the EDR includes the severity of the collision. Pressure sensors at the front of the vehicle use pressure sensors to measure the force of the impact.

The vehicle speed, engine speed, steering movements, position of the accelerator pedal, status of the brakes, status of the seat belts, tire pressure, warning signals and finally the deployment of the airbags are also included. This data should be recorded for a few seconds before and during the accident. The MCU must not start saving status values when an event occurs. Rather, it must record this data continuously. To do this, EDR requires non-volatile memory, which can be rewritten almost indefinitely.

This is where FRAM comes in. It stores data practically latency-free in about 10 µs. For comparison: EEPROM usually requires several 10 ms for writing and is therefore unsuitable for safety-critical applications. The combination of immediate writing and high clock speeds makes FRAM a good choice for applications where a large amount of data has to be stored quickly. When using SPI, developers can freely determine how many bytes should be written into the FRAM. If one or two bytes are stored at any memory location in a FRAM, the write cycle time is approximately 1 µs.

Unlike EEPROM or Flash, FRAM works without a side buffer. FRAM writes each data byte immediately after receiving the eighth bit. For the engineers, this means that they do not have to worry about the size of page buffers and how they change during the transition to the next memory density. FRAM can be rewritten about 1014 times and is, therefore, several orders of magnitude larger than EEPROM with 106 or FLASH with 105 write operations. This makes FRAM suitable for predictive data logging in which data is constantly written. In addition, FRAM requires very little power for write and read operations (about 300 µA at 1 MHz) and is therefore suitable for driver assistance systems in which data must be stored during a power failure due to an accident, even with low-capacity power supplies or from capacitors. The standby currents of FRAM (typically 100 µA) are also significantly lower compared to other non-volatile memories.

Memory requirements of valve units

The armature unit displays important information such as speed, engine speed, fuel supply, and engine temperature in digital form or graphically or analogically via pointer instruments with the aid of stepper motors. It also contains warning symbols, e.g. for battery condition, temperatures, low oil pressure, brake failure, and safety symbols, e.g. warnings when the seat belt is not fastened, tyre pressure is too low, doors are not locked, and displays for switched-on headlights, as an indication of upshift, when the handbrake is applied, as well as non-critical information such as interior and exterior temperatures, total and trip meters, etc.

Latest armature units also have a head-up display (HUD). It reduces the risk of losing sight of the road and gives the driver extra time to identify and react to hazards. This display can be limited to the most important information, such as speed and navigation, as well as the warning symbols with the highest priority.

Figure 2: Block diagram of a dashboard unit
Figure 2: Block diagram of a dashboard unit
(Image: Cypress Semiconductor)

Figure 2 shows a simplified block diagram of a valve unit with HyperRAM and HyperFlash at HyperBus interfaces and NOR Flash at the DDR-HSSPI interface. The unit's MCU is connected to other subsystems via various communication protocols such as CAN-FD, CXPI (Clock eXtension Peripheral Interface), Ethernet AVB and MediaLB (Media Local Bus)/MOST (Media Oriented Systems Transport) to receive information for display.

After switching on the power supply, the safety engine of the valve unit checks the authenticity of the firmware. The MCU software is then executed in XiP mode (eXecuting in Place) from the external HyperFlash via the HyperBus interface or from the NOR Flash via the DDR-HSSPI interface (Double Data Rate - High Speed Serial Peripheral Interface). XiP functionality allows the MCU to execute code directly from external memory without first copying it from the external flash to the internal RAM. This increases response speed.

Memory with NOR Flash/HyperFlash can be programmed with an output address for the program code and starts in reading mode after a preset delay in clock cycles after switching on. As soon as the MCU is supplied with power, it can immediately access the code to be executed instead of first having to pass an address and the read command for a few clock cycles. Static elements can be taken from an external HyperFlash and displayed as a basic level in the LCD of the valve unit. Automotive MCUs such as Traveo from Cypress support additional options for decompressing these static HMI elements during readout without first having to pass via RAM. Dynamic content with faster update rates, e.g. pointers, can be retrieved from the external HyperRAM.

Requirements of climate and infotainment systems

Figure 3: Block diagram of a climate and infotainment system
Figure 3: Block diagram of a climate and infotainment system
(Image: Cypress Semiconductor)

The HVAC system (heating, ventilation, air conditioning) ensures pleasant temperatures and ventilation in the passenger compartment. Apps on the infotainment system serve as user interfaces for setting the HVAC system, playing music, entering destinations in a navigation program, setting seat and steering wheel positions or adjusting the lighting mood in the passenger compartment. Some of the latest car models include a fingerprint reader to authenticate and identify the driver. This allows the climate and infotainment system settings to be quickly adapted to the driver's preferences. Figure 3 shows a climate and infotainment system with all memory elements connected to the main MCU. There are three further subsystems compared to the dashboard:

  • Touchscreen controller for detecting finger touches,
  • Heating/air conditioning system to control the temperature in the passenger compartment,
  • Controller for the various connectivity options in the vehicle (Bluetooth, GPS, WiFi, GSM, FM tuner, etc.).

HyperFlash and HyperRAM are often used to store high-quality graphics. The boot code is in NOR Flash and settings in FRAM. This means that the settings can be called up reliably even if the vehicle's electrical system is switched off and on again immediately.

Properties of different memory interfaces

Figure 4: NOR flash memory interface via Quad SPI.
Figure 4: NOR flash memory interface via Quad SPI.
(Image: Cypress Semiconductor)

Each MCU with SPI interface can access NOR Flash. NOR Flash such as Cypress S25FL256L have an SPI with multi I/O options and support both DDR (Double Data Rate) and QPI (Quad Peripheral Interface). Multiple Flash devices can be connected to the same bus and addressed individually using a chip select (CS) signal (Fig. 4).

Figure 5: FRAM memory interface via SPI
Figure 5: FRAM memory interface via SPI
(Image: Cypress Semiconductor)

The MCU can use low-level hardware drivers (LLD) to read, program and delete data. The architecture is optimized for fast access times and high program speeds. Figure 5 illustrates access to FRAM via a simple SPI interface. Serial FRAM can currently be clocked up to 40 MHz.

Figure 6: HyperBus interface to memory or peripheral devices.
Figure 6: HyperBus interface to memory or peripheral devices.
(Image: Cypress Semiconductor)

Because the serial data throughput correlates with the serial clock, SPI is well suited for MCU-based systems that require high data rates. Microcontrollers without their own SPI interface can access it via GPIO via bit-banging. HyperFlash and HyperRAM can be accessed via a HyperBus interface with 12 signals. When reading, HyperBus allows a 4 times higher throughput (333 MBit/s compared to 66.5 MBit/s) compared to Quad-SPI with one third of the lines required for parallel NOR Flash. This interface works with differential task signals (CK, CK#), Read/Write Data Strobe (RWDS), Chip Select and an 8-bit data bus (Figure 6).

This article was first published in German by Elektronik Praxis.

* Mahesh Balan is Application Engineer at Cypress in San Jose, USA

* Kishore Kumar is Sr. Staff Applications Engineer at Cypress Semiconductor in San Jose, USA