Skip to main content
Macro view of SPI flash chip on PCB with Aardvark host adapter connection

Reading SPI Flash Device IDs with the Aardvark Host Adapter

GSAS Engineering · · 2 min read

Reading the JEDEC Device ID from an SPI flash chip is the essential first step in any flash programming workflow. It confirms that the Aardvark I2C/SPI Host Adapter can communicate with the flash device, verifies the device manufacturer and part number, and validates the SPI bus configuration (clock polarity, phase, bit rate, and chip select) before attempting to program or read flash contents.

The JEDEC Read ID Command

The Read Identification command is defined by the JEDEC SFDP (Serial Flash Discoverable Parameters) standard and is supported by virtually all SPI NOR flash devices. The command sequence is:

1. Assert chip select (SS active low).
2. Send opcode 0x9F on MOSI.
3. Clock 3 additional bytes while reading MISO, these are the 3-byte Manufacturer and Device ID.
4. De-assert chip select.

For example, a Micron M25P32 responds with 20 20 16 (hex): manufacturer ID 0x20 (Micron/STMicroelectronics), memory type 0x20 (SPI NOR), and memory capacity 0x16 (32 Mbit). A Winbond W25Q32JV responds with EF 40 16: manufacturer 0xEF (Winbond), type 0x40, capacity 0x16 (32 Mbit).

Step-by-Step with Control Center

1. Connect the Hardware

Connect the Aardvark to the SPI flash target using a 10-pin ribbon cable. The pin mapping is:

Aardvark PinSignalFlash Pin
1SCKCLK
3MOSIDI (Data In)
5MISODO (Data Out)
7SSCS (Chip Select)
9GNDGND
10VCC (target power)VCC

Enable Target Power in the Aardvark menu to supply 3.3V/5V to the flash device if it is not otherwise powered.

2. Configure SPI Settings

In Control Center Serial Software, set the SPI parameters:

  • Polarity: Rising/Falling (SPI Mode 0 for most flash devices)
  • Phase: Sample/Setup
  • Bit Rate: 1 MHz (conservative starting point, increase after communication is verified)
  • Bit Order: MSB first
  • Slave Select: Active Low

3. Send the Read ID Command

In the SPI Master panel, enter the MOSI data: 9F 00 00 00

The first byte (0x9F) is the Read ID opcode. The three 0x00 bytes are dummy bytes that clock out the 3-byte device ID response on MISO. The Aardvark transmits on MOSI and simultaneously receives on MISO.

4. Read the Response

Control Center displays both the MOSI (transmitted) and MISO (received) data. The MISO bytes corresponding to the three dummy bytes contain the Device ID. The first MISO byte (corresponding to the opcode byte) should be ignored, it is undefined during the command phase.

Verification and Next Steps

If the Device ID matches the expected value for your flash chip, the SPI bus configuration is confirmed correct and you can proceed to flash programming operations (erase, program, verify) using either Control Center, Flash Center Software, or the Aardvark API.

If the response is all 0xFF or all 0x00, check: chip select polarity, SPI mode (try Mode 3 if Mode 0 fails), target power, and physical connections.

Alternative Approaches

The same Read ID operation can be performed through:

  • Flash Center Software: automatically reads the device ID during target device selection, with a built-in database of thousands of flash devices.
  • Aardvark API: programmatically in C, Python, or C# for automated test scripts that need to verify flash device identity before programming.
  • Cheetah SPI Host Adapter or Promira Serial Platform: same command sequence, higher clock speeds available (40+ MHz and 80 MHz respectively).

GSAS Micro Systems provides the Aardvark alongside the I2C/SPI Activity Board and SPI Flash Demo Board for teams learning SPI flash programming workflows across India.

Interested in Total Phase tools?

Talk to our application engineers for personalized tool recommendations.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.

Related Articles

Storage sizing ladder for automotive data logging: four rungs stepping from an aggregate link rate of 1 Gbit/s to 125 MB per second, then 450 GB per hour, then 3.6 TB per eight-hour shift, then 18 TB per five-day week, in decimal units, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

Automotive Data Loggers: Capture Without Loss

Search for an automotive data logger and the results split into cheap OBD dongles at one end and enterprise ADAS recorders at the other, with nothing in between explaining the engineering that decides whether you lose frames. This is the loss budget end to end: mirror oversubscription upstream of the logger, encapsulation overhead on the capture path, sustained write rate against burst rate, rotation stalls, and storage arithmetic worked in full so you can redo it with your own numbers instead of trusting ours. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 13 min read
Split panel diagram comparing one control message on a shared multidrop CAN bus with one sensor stream on a switched point to point Ethernet link, labelled shared bus arbitration, node, point to point link, switch, control message and sensor stream, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

CAN vs Automotive Ethernet: When to Use Each

CAN and automotive Ethernet answer different questions, so the useful comparison is a decision table rather than a winner. This guide from GSAS Micro Systems sets CAN and CAN FD figures from CAN in Automation next to the IEEE 802.3bw objectives for 100BASE-T1, covers arbitration against switch queues, cost and harness consequences, failure modes on both sides, and what changes on an India bench team's setup when a project adds Ethernet next to the CAN it already runs.

29 Aug 2026 · 14 min read
The AUTOSAR network management state ring: Bus Sleep, Repeat Message, Normal Operation, Ready Sleep and Prepare Bus Sleep, with the wake transition marked; the governing timers for each exit are named in the article's sourced state table, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

ECU Testing over Ethernet: Startup, Shutdown and Wake

A bench that powers the ECU, waits for it to settle and then starts capturing has already skipped three of the four phases where integration defects live. This is the lifecycle version of ECU testing over Ethernet: what a ping does not prove, the AUTOSAR network management state set and the timers that govern it read out of the public specifications, why one node holds a whole cluster awake, and a phase-by-phase table of stimulus, observable, pass criterion and capture method you can write test cases from this week. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 13 min read