32-bit AVR MCUs for automotive applications (Part 3)

In the first part of this series, we took a closer look at how Atmel’s AVR low-power 32-bit microcontrollers (MCUs) help enable the implementation of various product-differentiating features, including advanced control algorithms, voice control and capacitive touch sensing. In part two, we discussed powering Atmel’s AVR UC3C 32-bit automotive-grade microcontrollers with either a 3.3V or a 5V supply  (generally supporting 5V I/O) and focused on Atmel’s Peripheral Event System.

And today we will exploring how Atmel’s low-power 32-bit microcontrollers (MCUs) are used to help protect IP and bolster system safety. Firstly, it is important to note that code protection has become a critical design consideration, as software contains an increasing amount of intellectual property (IP). As such, internal Flash memory should be locked to protect code from being read or copied – with system development significantly accelerated by making application code available from third-party devs in a locked section of the Flash memory.

“Microcontrollers must either be programmed before they are assembled on boards or programmed in-device. Yet, preprogramming creates a challenge in logistics, as devices must be programmed in a trusted facility and transported to the manufacturing site,” an Atmel engineering rep told Bits & Pieces.

“In contrast, programming in-system allows the most recent code to be added during the manufacturing stage or in the field. The AVR UC3C arrives with USB drivers that support the Device Firmware Upgrade (DFU) class to allow devices to be programmed over the system’s USB port. As an alternative, a boot loader can be used to allow in-system programming using the CAN interface.”

And that is precisely why Atmel’s AVR UC3C 32-bit microcontroller architecture includes the Atmel FlashVault code protection technology, which allows the on-chip Flash to be partially programmed and locked, creating secure on-chip storage for software IP and boot loader operation.

On the system safety side, systems must be able to recover quickly from clock failure. Indeed, motor control systems must be able to shut systems down upon detection of clock failure to prevent severe damage to the motor or operator. To achieve this, the UC3C devices incorporate a main clock failure detection functionality that immediately switches over to the internal 115kHz RC oscillator in case of malfunction. The system may either continue operation using the backup clock (while triggering an alarm that the primary clock has failed) or perform any necessary shut-down operation to place the system in a fail-safe condition.

Interested in learning more about 32-bit AVR MCUs for automotive applications? Be sure to check out part four of this series which details how Atmel MCUs can be used to streamline automotive development. Part one can be read here and part two is available here.

Interested in learning more about 32-bit AVR MCUs for automotive applications? Be sure to check out part one, two, three and four of this series.

32-bit AVR MCUs for automotive applications (Part 2)

In the first part of this series, we took a closer look at how Atmel’s AVR low-power 32-bit microcontrollers (MCUs) help enable the implementation of various product-differentiating features, including advanced control algorithms, voice control and capacitive touch sensing.

We also discussed powering Atmel’s AVR UC3C 32-bit automotive-grade microcontrollers with either a 3.3V or a 5V supply (generally supporting 5V I/O). This has been achieved by moving to a modified 0.18-micron process technology, which supports higher I/O voltage levels in a reliable and cost-effective manner without any complex and expensive voltage conversion. In addition to supporting 5V I/O, the UC3C has been designed to support a wide range of high-performance peripherals required by automotive applications, including:

• ADC: 16 channels with 12-bit resolution at up to 1.5M samples/second; dual sample and hold capabilities; built-in calibration; internal and external reference voltages.
• DAC:  Four outputs (2 x 2 channels) with 12-bit resolution; up to 1M sample/second conversion rate with 1us settling time; flexible conversion range; one continuous or two sample/hold outputs per channel.
• Analog comparator:  Four channels with selectable power vs. speed; selectable hysteresis (0.20mV and 50mV); flexible input selections and interrupts; window compare function by combining two comparators.
• Timer/Counter: multiple clock sources (five internal and three external); rich feature set (counter, capture, up/down, PWM); two input/output signals per channel; global start control for synchronized operation.
• Quadrature decoder: Integrated decoder supports direct motor rotation detection.
• Multiple interfaces: includes a two-channel, two-wire interface (TWI), master/slave SPI, and full-featured USART that can be used as an SPI or LIN.
• Fully integrated USB:  built-in USB 2.0 transceivers support low (1.5Mbps), full (12Mbps) and on-the-go modes; included in the AVR Software Framework are production-ready drivers for various USB devices (mass storage, HID, CDC, audio), hosts (mass storage, HID, CDC) and combined function devices.

Atmel’s AVR UC3C 32-bit automotive-grade microcontrollers are also designed to achieve higher system throughput with our Peripheral Event System.

“Managing peripherals by the CPU can become a major system bottleneck, especially as the number of peripherals and their operating frequencies increase. With high sampling rates across multiple channels, interrupt overhead and data processing can consume a large percentage of the processor’s available clock cycles,” an Atmel engineering rep told Bits & Pieces. “If the CPU load needs to manage a single SPI port even at a low data rate of 1.2Mbps, this would require 53% of the processor’s capacity. In addition, the interrupt latency increases and introduces jitter.”

And that is why AVR UC3C architecture utilizes Atmel’s peripheral event system, which allows CPU-independent handling of inter-peripheral signaling through an internal communication fabric that interconnects all peripherals. Rather than triggering an interrupt to tell the CPU to read a peripheral or port, the peripheral instead manages itself by directly transferring data to the SRAM for storage – all without requiring any action by the CPU.

“From a power perspective, only those blocks that are part of the conversion are active. The CPU is free to execute application code or conserve power in idle mode during the entire event,” the Atmel engineering rep continued. “In addition, the peripheral event controller allows a more deterministic response compared to a CPU-based, interruptdriven event controller, because the latency is fixed to 3 cycles, i.e., 33ns when operating at 66MHz. This enables precise timing of events without jitter, resulting in constant sample rates for ADCs and DACs.”

Interested in learning more about 32-bit AVR MCUs for automotive applications? Be sure to check out part three of this series which details how Atmel MCUs can be used to help protect IP and bolster system safety. Interested in learning more about 32-bit AVR MCUs for automotive applications? Be sure to check out part one, two, three and four of this series.

Getting up close and personal with SERCOM

Last week, Bits & Pieces discussed Atmel’s Peripheral Event System in the context of the recently launched SAM D20 microcontroller (MCU) lineup. Today, we’re getting up close and personal with SERCOM (Serial Communication Module) on the  SAM D20 which can be configured to support UART/USART, SPI or I2C.

“SERCOM offers immense flexibility when embarking on a design since it allows devs to configure available interfaces as needed. Essentially, there are two very important benefits to this approach,” explained Andreas Eieland, Sr. Product Marketing Manager, Atmel.

“Firstly, you no longer need to trawl through microcontroller specifications looking for a device with the number of types of serial interfaces you require. Not only does this save a lot of time but it also allows you to adopt a single microcontroller for a number of similar designs where the interfaces required may differ slightly and you no longer have to buy a device that has five UARTS because you need three SPIs.”

According to Eieland, another benefit of Atmel’s SERCOM relates to designing the PCB. By choosing the interface type to coincide with the location of any supporting interface components or interconnect on the PCB, engineers can ensure more efficient PCB routing that is not only potentially shorter, but also avoids any long signal paths past electrically noisy components.

“This is made possible by having multiple SERCOM modules and the fact that each SERCOM module boasts multiple pin connection options. Remember, Atmel’s SAM D20 device supports I2C fast mode of up to 400 kHz while SPI and UART are capable of up to 24 Mb/s transfer speeds,” he continued.

“Plus, the serial communication modules all are connected to the Peripheral Event System – facilitating peripheral cooperation without CPU intervention. Each SERCOM module is also capable of being reconfigured by software into another interface type on-the-fly.”

Additional data about Atmel’s Peripheral Event System and SERCOM for the SAM D20 can be found here.

A closer look at Atmel’s Peripheral Event System

As previously discussed on Bits & Pieces, Atmel recently introduced the SAM D20 MCU, an extensive product lineup based on ARM’s Cortex -M0+.

The SAM D20 boasts a number of power-saving techniques, including an event system that allows peripherals to communicate directly with each other without involving the CPU or bus resources. This is known as the Peripheral Event System.

According to Andreas Eieland, Sr. Product Marketing Manager at Atmel, the Peripheral Event System can best be described as a routing network independent of the traditional data bus paths. Meaning, different triggers at the peripheral level can result in an event, like a timer tick triggering a reaction in another peripheral.

“Comprising 8 independent channels, the Event System offers a fixed latency of 2 cycles. Without any jitter it is a 100% deterministic method and a perfect fit for real-time applications,” Eieland explained.

“No events are lost and they are handled at a peripheral level in two cycles, even if the CPU is performing a non maskable interrupt. Traditionally the way of handling actions for a low power application would be through the use of interrupts, although they wake up the CPU.”

To better illustrate the advantages of an Event System, Eieland cited an example of a motor drive application using PWM.

“To detect erroneous situations, many motor applications use an analog comparator or ADC to measure the current going into the motor drive, in an over current situation you want to shut down the PWM channels driving the motor as soon as you can to prevent permanent damage to the circuit and for safety reasons,” he said.

“Without an Event System the overcurrent situation will trigger an interrupt, but the interrupt service request might be delayed if the CPU is performing other higher priority tasks. Using the Event System you can connect the analog comparator or ADC directly to the timer and always shut down the timer in two cycles, regardless of what the rest of the MCU is doing.”

Although Peripheral Event capabilities are useful on many different levels, the primary advantages of such a feature include minimizing power consumption, optimizing the off-loading of routine tasks from the CPU and achieving a totally predictable reaction time.

Additional information about Atmel’s Peripheral Event System can be found here.

The Peripheral Event System in Atmel’s SAM4L ARM Cortex-M4 based Microcontroller

Atmel’s SAM4L ARM Cortex-M4 based MCU has inherently low current consumption for such a powerful chip. But it also has a Peripheral Event System that allows you to service interrupts or external conditions without waking up the core processor.

Periphereal Event-System for Atmel’s SAM4L Cortex-M4

Keeping your microcontroller unit in sleep mode will reduce system power consumption. Increasing the throughput will reduce the time spent in active mode. Atmel’s Peripheral Event System allows peripherals to communicate directly with each other without involving the CPU (central processing unit). It is a routing network independent of traditional data paths such as system buses. Peripherals can trigger events such as data transfer to another peripheral or the copying of a message directly to the MCU internal memory. All this can happen while the processor is asleep. You spare the CPU from the time-consuming handling of interrupts since the Peripheral Event System is doing these repetitive tasks. This will free up more time for the MCU to handle other tasks in the application, or allow the MCU to remain in sleep mode for a longer time. The Peripheral Event System lowers power consumption and increases performance.

You can read more about conserving power in an Atmel white paper: Redefining the power benchmark.