Use HyperBus to Expand Memory in Tiny IoT and Wearable Designs to Save Space and Cost

By Adesto Technologies

With IoT nodes and wearable devices shrinking, designers need to make maximum use of their microcontroller’s on-board memory to minimize board space, power, and cost. However, sometimes memory expansion cannot be avoided. Instead of defaulting to a 32-bit controller’s bus structure, designers should consider HyperBus, a high-speed, 333 Mbit/s, 8-bit, double data rate (DDR) interface for both address and data.

As much as designers try to avoid expansion, it’s often necessary due to increased memory requirements during development. Or, the developers are simply future-proofing the design by anticipating future expansion needs.

With HyperBus, microcontrollers can support external flash and RAM on the same bus, versus the 16-bit data and 16-bit address bus and associated control pins of a typical 32-bit interface. It works with any memory device that has a HyperBus interface port, and is an effective, easy-to-use interface for low pin count memory expansion in space-constrained applications.

Although the operation of the bus is transparent to firmware, it’s important that developers new to HyperBus familiarize themselves with the operation of the high-speed bus signals to ensure a robust design. This article will first describe the operation of HyperBus. It will then introduce microcontrollers that incorporate the interface, and show users how to go about applying it effectively and testing their design.

HyperBus explained
As mentioned, HyperBus uses a high-speed 8-bit DDR interface for both address and data. In addition, it uses a differential clock, a read/write latch signal, and a chip select for each memory device. HyperBus supports external flash and RAM on the same bus, and works with any microcontroller with a HyperBus compatible peripheral interface.

HyperBus is set up as a master/slave interface, where one host master interfaces to one or more slave memory devices on the bus. HyperBus flash memory devices are referred to as HyperFlash™, and HyperBus DRAM memory devices are referred to as HyperRAM™.

The bus uses a differential clock with signals designated CK and CK#. As HyperBus is a DDR interface, data is transferred on both rising and falling clock edges. The clock is driven only by the master, and its frequency may not exceed the rated clock frequency of the slowest HyperBus memory on the bus.

The bidirectional 8-bit bus is designated DQ[0-7] and transfers address, data, and commands between the master and slave devices. A bidirectional read/write data strobe signal, designated RWDS, is used to latch data. RWDS is controlled by whatever device is reading data, so if the microcontroller host is writing data to HyperRAM, the HyperRAM controls the RWDS signal. The data being read on DQ[0-7] is aligned with both edges of the clock.

Each slave device is selected using an active low chip select, designated CS0#, CS1#, CS2#, etc. Only one chip select may be active at any time. All bus transactions are initiated with the designated chip select transitioning from high to low. All bus transactions are terminated with the designated chip select transitioning from low to high. Developers must insure that one chip select is active at any time. Failure to do so may result in more than one HyperBus slave device driving RWDS at the same time, which can result in corruption of data.

An active low hardware reset signal, designated RESET#, is driven by the master. When pulled low, it resets the state of any external HyperBus memory devices connected to the signal. This includes resetting the memory device’s internal configuration registers. However, it does not affect the state of the internal memory of the HyperBus memory devices. On most HyperBus master microcontroller interfaces, RESET# is not part of the HyperBus peripheral but is instead a general I/O pin. HyperBus slave devices have a weak pullup on the RESET# pin, so if it is left floating it is pulled to a high state.

Any HyperBus-compatible peripheral on a microcontroller must conform to the HyperBus specification. A good example of a HyperBus-compatible microcontroller is the STM32L4R9 Arm® Cortex®-M4F from STMicroelectronics (Figure 1). The STM32L4R9 has 2 Mbytes of internal flash memory, and 640 Kbytes of SRAM. It has a wide variety of peripherals, including two OctoSPI interfaces that can be configured as HyperBus interfaces.

Diagram of STMicroelectronics STM32F4L9 microcontroller (click to enlarge)

Figure 1: The STMicroelectronics STM32F4L9 microcontroller is based on an Arm® Cortex®-M4 core with FPU and has two HyperBus-compatible interfaces, seen here highlighted in orange. (Image source: STMicroelectronics)

The STM32L4R9 accesses the HyperBus external memory addresses as memory mapped into the microcontroller’s AHB bus address space, so reads and writes to external memory are accessed by the core in the same way as internal memory. Once the external memory devices are configured, operation of the HyperBus is transparent to the core.

HyperBus memories are all 16-bit wide memories, so all accesses from the STM32L4R9 must be on 16-bit memory boundaries. Data accesses from the STM32L4R9 master can be 16-bit or 32-bit, and must also be on aligned boundaries.

A typical read or write transaction on the HyperBus consists of a sequential series of 16-bit, one clock cycle data transfers via two corresponding 8-bit wide, one-half clock cycle data transfers, one on each single-ended clock edge or differential clock crossing. Read and write transactions always transfer full 16-bit words of data. Read data words always contain two valid bytes. Write data words may have one or both bytes masked to prevent writing of individual bytes within a write burst. Byte transfers are not supported in the HyperBus protocol, nor does it support bit operations such as bit-banding.

Each HyperBus-compatible port on the STM32L4R9 has a dedicated 256 Mbytes of memory-mapped address space, mapped as follows:

HyperBus1 (OctoSPI1) 0x90000000 to 0x9FFFFFFF
HyperBus2 (OctoSPI2) 0x70000000 to 0x7FFFFFFF

The internal address of the HyperFlash or HyperRAM memory device being accessed is offset from the base memory address of the above location. For example, if the STM32F4L9 reads from memory location 0x90000047, it reads back the value stored in the memory device accessed on HyperBus1 in memory location 0x0047.

Cypress Semiconductor developed the HyperBus specification, and also has a product line of HyperBus memories. The Cypress S26KS512SDPBHI020 64 MB x 8 HyperFlash Memory can easily interface to one of the OctoSPI ports. It supports wrapped burst accesses of up to 32 16-bit words. With a maximum 166.6 MHz clock rate, the S26KS512 HyperFlash supports the full 333 Mbytes/s sustained read rate. At the OctoSPI maximum clock of 60 MHz, the STM32L4R9 can read any external HyperBus memory at 120 Mbytes/s, maximum.

The STM32L4R9 can execute code directly out of this flash memory if the HyperFlash is accessed through the Cortex-M4 system bus. When used for code memory, the OctoSPI supports eXecute In Place (XIP) with an integrated prefetch buffer that loads the next memory address from the external memory.

The Cypress Semiconductor S27KS0641DPBHI020 8 MB x 8 HyperRAM memory is a self-refreshed DRAM that can expand the STM32L4R9 data memory. It supports wrapped burst accesses of up to 64 16-bit words. The S27KS0641 HyperRAM also supports up to 333 Mbytes/sec sustained read rate and can be read by the STM32L4R9 at a maximum 120 Mbytes/s.

Interfacing to HyperBus memories
The STM32L4R9 has two HyperBus-compatible ports, and each can separately interface to HyperRAM and HyperFlash external memory devices (Figure 2). The RESET# signal is optional and so is not shown in the figure. With both the Cypress HyperFlash and HyperRAM, the STM32L4R9 can easily extend its internal memory with minimal impact on pc board size and design complexity.

Related Products