SPI Flash CRC Errors During ADC DMA Bursts
A battery-powered data logger uses a 32-bit MCU at 80 MHz. A 12-bit ADC streams at 200 kS/s over SPI0 using DMA. A separate SPI1 bus accesses a flash chip at 12 MHz. During continuous logging, about 1 in 10,000 flash reads returns a CRC error; errors vanish when ADC DMA is disabled. The board has separate chip selects, a shared 3.3 V rail, and no bus arbiter. A logic analyzer shows SPI1 SCLK has occasional extra clock pulses near DMA burst completion, and the flash CS line deasserts about 300 ns later than expected. The product must sustain 200 kS/s and cannot afford a board spin. Firmware currently drives flash CS as a GPIO in the SPI1 ISR. The ADC and flash share the same 3.3 V regulator, but not the same SPI bus.
1. What is the most likely mechanism for the CRC errors, and why does disabling ADC DMA make them disappear?
Read the worked answer
The extra SCLK pulses while flash CS is still asserted are the key symptom. If CS is driven by software in the SPI1 ISR, the DMA burst-complete interrupt can delay that ISR long enough for the SPI1 peripheral to emit additional clocks before CS deasserts. The flash then sees extra bits, so the returned word or CRC no longer matches. Disabling ADC DMA removes the burst-complete interrupt and much of the bus contention, so the CS timing returns to normal and the errors disappear. This is a timing/architecture problem, not a flash defect. Confirm by triggering the scope on DMA completion and measuring CS-to-last-SCLK delay across many events; also verify the extra pulses are real and not a probe artifact.
2. Compare three possible fixes: hardware-controlled CS, lowering SPI1 to 6 MHz, and adding CRC retry. Which is lowest risk while still sustaining 200 kS/s?
Read the worked answer
Hardware-controlled CS is lowest risk because it removes the software timing dependency that creates the extra clocks. The SPI peripheral asserts and deasserts CS in step with the clock, so interrupt latency no longer changes the frame boundary. Lowering SPI1 to 6 MHz may reduce the error rate but does not fix the root cause; if CS still deasserts late, extra clocks can still occur, and flash throughput falls. CRC retry hides errors but does not prevent corrupted writes or lost time, and repeated retries can violate logging latency. Choose hardware CS first, keep CRC as a diagnostic, and only lower SPI1 clock if signal integrity also proves marginal.
3. What verification would demonstrate that the chosen fix is effective?
Read the worked answer
Run the ADC DMA at full 200 kS/s while performing continuous flash reads and writes. Capture CS, SCLK, MOSI, and MISO on a logic analyzer with a trigger on DMA completion, and confirm CS never deasserts before the final intended clock edge. Inject worst-case interrupt load, including the DMA completion and other high-priority ISRs, and repeat for at least 10^6 flash transactions. Track the CRC error counter for 24 hours over temperature and supply variation. Also verify that flash throughput and ADC sample timing still meet specification, so the fix has not simply moved the failure to another timing path.