In SPI protocol design, timing between control and data signals plays a crucial role in reliable communication, especially in multi-slave, high-speed, or sensitive analog peripheral systems. Two often overlooked but critical timing parameters are:
- Master SS Idleness
- Inter-Data Idleness
These parameters are available in modern SPI controllers and are vital for ensuring proper synchronization between the master and slave devices — yet they are also frequent sources of subtle, hard-to-debug issues. This article explains both in SPI-generic terms, shows how different hardware platforms implement them, and compiles known bugs and best practices engineers must consider.
What is Master SS (Slave Select) Idleness?
🧠 Definition:
Master SS Idleness is the intentional delay inserted between the assertion of SS (Slave Select) and the start of the first SPI clock (SCK) when the master initiates a transfer.
✅ Why It Matters:
Many slave devices — especially older analog or discrete logic ICs — require a setup time after SS goes low before they can interpret the clock or MOSI signals. Starting SCK too soon can cause:
- Corrupted first bit
- MISO line not ready
- Missed command/response
🔍Generic Timing View:
Let’s consider the most common case:
- SS is active-low
- MasterSSIdleness is set to 2 clock cycles
- CPOL = 0, CPHA = 0 (clock idle low, data valid on first edge).
🖼️ ASCII Timing Diagram: markdown:
Time → → → →
SS : ───────┐ ┌──────────────
└───────┐──────────┘
↑
MasterSSIdleness (2 cycles)
SCK : ────────┐¯‾¯‾┐¯‾¯‾┐
↑
Data starts
🔍 Explanation of the above example:
🔸 SS (Slave Select) Line:
SS : ───────┐ ┌──────────────
└───────┐──────────┘
- SS starts HIGH: the slave is not selected.
- Then it goes LOW (└───────┐) — slave is selected.
- This moment marks the start of SS active period.
- The slave is now expecting communication — but may need some setup time.
- After the transmission ends, SS goes HIGH again.
🔸Master SS Idleness:
- After SS goes LOW, the master waits for 2 SCK cycles before sending the first clock edge.
- This delay ensures the slave is ready to interpret data and avoids miscommunication.
🔸 SCK (Clock) Line:
SCK : ────────┐¯‾¯‾┐¯‾¯‾┐
- SCK remains LOW (idle) during Master SS Idleness.
- Then it starts toggling to clock in the first data word.
- Each ¯‾ pair represents one clock cycle.
- Data bits are transferred during these cycles.
🧠 When is This Important?
Devices like:
- Analog front ends
- Digital potentiometers
- Slow EEPROMs or Flash ICs
- Low-speed sensors
may all need a few microseconds or clock cycles of delay between SS falling and the first clock.
What is Inter-Data Idleness?
Inter-Data Idleness is the delay (in clock cycles) between consecutive data frames (bytes/words) during a single SPI transfer without toggling the SS (Slave Select) line. This matters when you are transmitting multiple bytes or words in a single SS session.
This is especially useful when:
- The slave device needs processing time between bytes.
- You are transmitting continuous frames with SS held LOW.
- Some protocols expect a delay between commands/data bursts.
- ADC or DAC latch timing.
🖼️ ASCII Timing Diagram (Active-Low SS, CPOL=0/CPHA=0):
Time → → → →
SS : ─────────────────────────────────────────────── ← Held LOW (active)
MOSI : [Byte 1] (idle) [Byte 2]
┌────────┐ ┌────────┐
│ 0xA5 │ │ 0x5A │
SCK : ─┐¯‾¯‾┐¯‾¯‾┐───(idle)───┐¯‾¯‾┐¯‾¯‾┐
↑ ↑
Inter-Data Idleness (e.g., 2 SCK cycles)
🔍 Line-by-Line Explanation:
SS (Slave Select):
SS : ───────────────────────────────────────────────
- SS remains LOW throughout the whole multi-byte transfer.
- This is common when using DMA or software-controlled chip select.
- No SS toggling means all data belongs to a single transaction.
MOSI (Master Out, Slave In):
MOSI : [Byte 1] (idle) [Byte 2]
- Master sends Byte 1 (e.g., command or first data byte).
- Then there’s an intentional gap (idle state).
- Then it sends Byte 2.
- The data could be 8-bit, 16-bit, etc., depending on the SPI configuration.
SCK (Serial Clock):
SCK : ─┐¯‾¯‾┐¯‾¯‾┐───(idle)───┐¯‾¯‾┐¯‾¯‾┐
- After Byte 1 completes, the SPI controller inserts an idle period (SCK stays LOW).
- This gap is defined by Inter-Data Idleness, in clock cycles.
- After the idle time, the next byte is clocked out.
🎯 When Do You Need Inter-Data Idleness?
| Scenario | Why Use Inter-Data Delay |
|---|---|
| Slave has slow internal logic | Needs time to process previous byte |
| Multi-frame SPI protocols | Expect spacing between frames |
| SPI Flash with page boundary write | Must pause between bytes for address latching |
| Avoiding metastability at high SPI clk | Insert delay to reduce timing errors |
Hardware Abstraction (MCU-agnostic View):
🛠️ Modern SPI peripherals may offer:
| Feature | Description |
|---|---|
| SS Idleness | Delay after SS becomes active, before clock starts |
| Inter-Data Idleness | Delay between bytes or words within a transfer |
| SS Hold Delay | Delay after the last clock edge before SS goes inactive |
| SS Pulse Mode | Whether SS is pulsed per byte or held across the transfer |
These features can often be configured in units of SPI clock cycles.
✅ Implementations in Real Hardware:
| Platform | SS Idleness | Inter-Data Idleness | Registers / Config |
|---|---|---|---|
| STM32 (HAL) | MasterSSIdleness |
MasterInterDataIdleness |
SPI_CFG2, HAL init |
| Renesas RSPI | SPCKD, SSLND |
SPND |
RSPIx delay regs |
| NXP LPSPI | PCS-to-SCK Delay |
Between Transfer Delay |
TCR, CCR registers |
| TI MSP430 | Manual using timers | Manual using timers | GPIO control |
🐞 Known Bugs & Precautions:
Despite being a relatively simple protocol, SPI communication can still be vulnerable to subtle, timing-related bugs, especially when operating at high speeds or when interfacing with analog or legacy peripherals. Engineers often overlook the role of SS (Slave Select) timing and inter-frame delay, leading to unexpected and hard-to-reproduce issues.
Below are some common bugs observed in real-world SPI implementations, along with root causes, effect, and fix.
🔴 Bug #1: First Bit Missing or Corrupted:
- Cause: SCK starts immediately after SS assertion.
- Effect: Slave misses first bit or misaligns internal shift register.
- ✅ Fix: Add SS Idleness of 1–2 clock cycles minimum.
🟠 Bug #2: Data Shifted / Misaligned Across Frames
- Cause: Inter-data delay not sufficient for slave to latch.
- Effect: Slave latches wrong command or partial data.
- ✅ Fix: Set Inter-Data Idleness based on slave datasheet; even 1 cycle can help.
🟡 Bug #3: SS Pulse Glitches
- Cause: Using SS pulse mode with a slave expecting continuous low SS.
- Effect: Slave resets communication or enters wrong state.
- ✅ Fix: Disable SS pulse; manually control SS for complex protocols.
🔵 Bug #4: DMA + SPI Timings Clash
- Cause: In fast DMA SPI transfers, delays are too short for slave to respond.
- ✅ Fix: Use inter-data delay + check if DMA supports frame-based triggering.
🟣 Bug #5: Hardware Abstraction Layer Hides Settings
- Cause: CubeMX or FSP does not expose advanced timing in UI.
- ✅ Fix: Manually set registers (e.g., SPI_CFG2, SPND) or extend HAL/FSP drivers.
🧪 Best Practices for Engineers
- Always read the slave device’s timing diagram (especially tCSS, tSU, tH).
- Avoid assuming “fast is better” — SPI needs synchronization, not just speed.
- Test SPI at full speed with real hardware + logic analyzer.
- Use SS Idleness ≥ 1 clock cycle unless slave explicitly says 0 is safe.
- Use Inter-Data delay when:
- Slave datasheet recommends it.
- Transfer fails at higher speeds.
- DMA mode is used with burst data.