When reset is the only option, what do you do if there is no button?

The truth, which many design engineers will already know, is that hardware crashes too, and while perhaps not quite so error-prone as embedded software, it is by no means out of the ordinary for hardware to get into a condition where it simply stops working.

Under these conditions the only recourse is to hit reset. But what happens if there is no reset button to hit? Embedded designs are typically buried away from the user, intended to operate flawlessly and repetitively, this is essentially what embedded control is all about. But as design complexity continues to increase, the surface area for failure also increases, or to put it another way as functional density goes up, the probability of a small glitch rippling through the entire system to become a fully-fledged fault goes up with it.

Most embedded systems still follow a hierarchical design, using a host processor or, perhaps more likely, a microcontroller (MCU) to manage everything. It’s important for the MCU to have the ability to hit the rest button, but self-resetting isn’t necessarily a comprehensive approach, which is why it’s commonplace for embedded designs to use a WatchDog Timer (WDT) implemented using either software or (probably preferable) an external device.

The WDT’s job is to issue a hard reset of the MCU if it doesn’t service the timer within a defined amount of time. The problem is that resetting the MCU isn’t the same as resetting the whole system.

Although the WDT will most likely only reset the MCU, power-cycling is completely indiscriminate and will result in the loss of all operational data. Neither is ideal, which is why some critical devices that require synchronicity, such as SPI-based Flash memory, also feature a hard-wired reset pin. At least, that used to be the case.

The drive for greater density and smaller packages, incident with the move to Quad SPI and Quad Peripheral Interface (QPI) ports means some manufacturers have opted to leave the reset pin out of newer designs, in order to use the smallest possible package size. Embedded developers may welcome these smaller outlines, but the loss of the reset function is a major drawback to system stability and reliable operation.

With the introduction of JESD252 there really is no reason for IDMs (Integrated Device Manufacturers) not to implement its features. In fact, the increased use of SPI Flash memory and, in particular, eXecute-in-Place (XiP) memory has made the interaction between MCU/MPU and memory an even more critical part of system design.

The ability to reset both the MCU and the memory in a coordinated way could be vital in embedded systems where component density and signal integrity are exerting greater influence on the overall design. The synchronised operation of MCU and memory, specifically XiP, necessitates the use of reset over SPI.

Increasingly, IDMs are prepared to reduce and, in some cases, even completely remove on-chip non-volatile memory, to lower the overall cost of MCUs. This is accelerating the move to using external memory for code storage; XiP is designed to allow the MCU to run the code directly from the memory device, which delivers higher performance.

However, it relies on close synchronisation between the MCU and the Flash device over the SPI bus, and that is something that can easily be disrupted by noise. In these cases, the only recourse is to reset the SPI memory to a known state, which is why JESD252 is so crucial in today’s embedded systems.

By implementing JESD252, SPI memory can be made more reliable. Put simply, if JESD252 is available, then using it represents best-practice in embedded design and for this reason design engineers should no longer settle for using SPI Flash devices that do not have a dedicated reset pin. By specifying SPI Flash memory that supports JESD252, engineers and manufacturers can deliver more robust and reliable products.