DebugProbe SPI Flash Result Codes

Verdicts only the SPI NOR flash library (debugprobe/SpiFlash.hpp, the spiFlash* methods and their C entries) can decide. They are CosmicSDK codes in the SPI block, 0x0320 onward (after FW_SPI_TARGET_* at 0x0310); the debug plane’s codes are 0x1E01 onward (group 0x1E). Both are named by debugprobe::resultName().

DEBUGPROBE_FLASH_NO_DEVICE: JEDEC ID answered all 00 or all FF — no flash on the bus (wiring, power, or chip select). Refused even with a parameter override: an override cannot paper over a dead bus.

DEBUGPROBE_FLASH_NEEDS_OVERRIDE: No SFDP signature or no BFPT header, and the JEDEC ID is not in the table — supply a FlashParams override.

DEBUGPROBE_FLASH_BAD_PARAMS: The parameters cannot drive the part as given: more than 16 MiB with 3-byte addressing (v1 drives 3-byte parts).

DEBUGPROBE_FLASH_BOUNDS: [addr, addr + n) falls outside the part.

DEBUGPROBE_FLASH_ALIGNMENT: An erase address that is not aligned to the granularity it names.

DEBUGPROBE_FLASH_PAGE_CROSS: A page program that would cross a page boundary (NOR wraps inside the page instead of advancing).

DEBUGPROBE_FLASH_WRITE_PROTECTED: WREN did not set WEL — the part is write-protected (or absent).

DEBUGPROBE_FLASH_BUSY_TIMEOUT: The part stayed busy past its datasheet-order deadline — a wedged operation, not a slow one.

DEBUGPROBE_FLASH_NO_HASH: The probe does not advertise the on-probe hash (SPI_GET_STATUS byte 11); use read-back.

DEBUGPROBE_FLASH_NOT_DETECTED: A flash operation was asked for before spiFlashDetect() succeeded.

DEBUGPROBE_FLASH_SHORT_RESPONSE: The wire answered fewer bytes than the transfer asked for, or a digest of the wrong shape.

DEBUGPROBE_FLASH_EMPTY: An empty span where one was required.

DEBUGPROBE_FLASH_SESSION_WIDTH: The open SPI session is not 8-bit. The sequencer pads nothing, so a 16-bit session would clock every command header pair-swapped: the part sees opcode 0x00 and answers zeros AS flash contents – read, verify and blank-check would all report a wrong part, not a wrong session. Reopen with SPI_DATA_WIDTH_8_BITS.

Debug codes

Verdicts of the debug plane (debugAttach … debugCallFunction and their C entries), in their own group, 0x1E01 onward. Group 7 is GROUP_ONE_WIRE, so the block stays clear of the firmware’s bus groups.

DEBUGPROBE_DEBUG_NOT_ATTACHED: A debug verb before a successful attach. Caller-side ordering error.

DEBUGPROBE_DEBUG_NO_TARGET: Line reset + DPIDR read got no ACK: nothing answers on SWDIO. An unpowered target is electrically identical — the caller should quote the rail.

DEBUGPROBE_DEBUG_FAULT: The target ACKed FAULT (sticky error): bad address, access fault.

DEBUGPROBE_DEBUG_WAIT: WAIT retries exhausted: the target is busy. Retry is the caller’s call.

DEBUGPROBE_DEBUG_TIMEOUT: A status poll (S_HALT, S_REGRDY, power-up ACK) did not complete in time.

DEBUGPROBE_DEBUG_NOT_HALTED: Register access or step needs a halted core, and it is running.

DEBUGPROBE_DEBUG_NO_COMPARATOR: Every FPB comparator is in use.

DEBUGPROBE_DEBUG_UNSUPPORTED: The probe lacks SWD, the core lacks an FPB, or the reset flavour does not exist on this architecture (VECTRESET on ARMv8-M).

DEBUGPROBE_DEBUG_PROBE: The CMSIS-DAP transport itself failed: empty transfer, DAP_ERROR, wrong command echo. The probe, not the target.

DEBUGPROBE_DEBUG_STEP_STALLED: step() disarmed every FPB comparator matching the halted pc, single- stepped, and rearmed them, and the pc still did not move. The disarm and rearm both succeeded — this is a distinct failure, not a reason to retry: looping burns the caller’s step budget the way the pre-fix bug did (see bug_atira_step_off_breakpoint_never_retires).

DEBUGPROBE_DEBUG_CALL_FAULTED: callFunction() ran the target and it halted somewhere other than the return trap it was given — or never halted, and once halted after the timeout was found in an exception handler (IPSR != 0): the routine faulted and the target’s handler ran on. An algorithm that hard-faults halts too, and a fault’s r0 is whatever was in the register — reporting success with that number is how a failed erase gets read as a clean one. The caller gets the halted pc through the state it can read afterwards. First cause seen on a bench: an MPU marking RAM execute-never on a booted target (start from a reset-halted core, where it is still off).