JEDEC’s Soft Reset Offers Significant Benefits to Embedded Developers
Today’s embedded systems, such as smart devices and endpoints in the IoT, often require instant-on capability while combining high performance with low power consumption. All electronic systems should also include the ability to recover from conditions induced by transient faults. Such faults are often closely dependent on signal integrity, which is something that is made more challenging in today’s high-speed designs.
Recovering from a runtime fault typically requires being able to instigate a controlled reset to all or parts of the system. In extreme circumstances, and where provision for a soft reset hasn’t been made, this can dictate the need to power-cycle a device. For IoT endpoints in remote locations, this can be problematic and expensive, thereby providing just one example of how important reset functions have become in embedded design.
The Serial Peripheral Interface (SPI) is widely used to connect peripherals and memory to a microcontroller or processor in embedded systems. Resetting serial flash memory is an important part of initialization or recovery. To enable SPI memories to be more easily reset by the host processor, the industry standards body JEDEC has defined a serial reset protocol that avoids the need for a dedicated reset pin. This article describes the reset protocol and its use, with particular reference to expanded SPI (xSPI) and executing code from serial non-volatile memory.
The role of SPI flash
The main advantage of a serial interface with respect to a parallel bus is the reduced number of signals required. Fewer signals and I/O pins reduces component cost and power consumption in most cases, as the power required to drive signals off-chip can be a significant contributor to the total power consumption.
The original SPI specification had four signals: a serial clock (SCLK) to synchronize data transfers; one or more chip selects (SS) to enable multiple targets to be addressed, and two data signals (MOSI and MISO) to transfer data in each direction. The standard has been extended in various ways to support higher performance, which now includes the ability to perform a soft reset over the SPI interface.
Serial Peripheral Interface (SPI) (Source: Adesto Technologies)
To increase bandwidth, the SPI interface has evolved and developed, and variants now include dual SPI, which uses both data pins in a half-duplex configuration to send two bits per clock cycle, and quad and octal SPI, which add more data lines to transfer a larger number of bits per clock cycle. In addition, both of these can be used in double data rate (DDR) mode, which transfers data on both clock edges.
Quad and octal SPI interfaces are defined by the JEDEC expanded SPI (xSPI) standard, JESD251, which provides hardware guidelines to enable trouble-free integration of high-throughput xSPI devices in systems.
More recently, JEDEC has also defined and released a standard that provisions for resetting a device over the serial interface. This reset protocol, defined in JEDEC standard JESD252, removes the need for a dedicated reset pin in serial flash.
The standard defines the specific sequence that the chip select, clock, and input data signals need to follow in order to cause the device to perform a hardware reset. This pattern is used so that spurious transitions caused by noise on the serial data line don’t lead to an accidental reset. During a reset, the clock signal is held low, further ensuring that the pin transitions aren’t interpreted as a data transfer, while the chip-select pin is used to ensure that only a specific device is reset.
Reset protocol (Source: Adesto Technologies)
SPI flash memory is widely used in embedded products, particularly for code. This makes it critical to overall functionality, and so it is essential to maintain reliable operation, including the ability to issue a reset if necessary.
Using reset for initialization and recovery
Systems generally use a reset function at power-up to ensure that all parts of the system start in a known state. Reset can also be used to recover from serious faults that may be caused by hardware problems during runtime, which include signal integrity and timing problems, electromagnetic interference, or random memory corruption caused by background radiation (see also “Mitigating Metastability”). Software bugs can also cause a program to crash and become unresponsive.
These occasional errors may be an inconvenience only for consumers, but they can be a serious problem for the IoT, in which thousands of nodes need to have high levels of availability. Increasingly, these devices may not be readily accessible for manual reset or power cycling. Embedded systems will typically use watchdog timers and other self-test mechanisms to detect failures and take corrective action. This may mean performing a “soft” reset wherein only the necessary subsyste