Check timestamp writes against the clock lock

[glopesdev]

Two checks cover the CLK_UNLOCK and CLK_LOCK bits of R_CLOCK_CONFIG against R_TIMESTAMP_SECOND, closing the two remaining clock boxes in #28. Each sets the bit, asserts it reads back, and then asserts that the timestamp takes the written value while unlocked and keeps its value while locked.

The v1 specification text already carries both obligations, including the read-back requirement: "it will reject any new timestamp values" and "The bit is read as 1 if the timestamp register is locked", so these run as part of the default baseline rather than prerelease.

What the checks deliberately do not assert

The reply form. The specification says a locked device rejects a write, without saying whether it answers with an Error or acknowledges and ignores it, and the tagged document has no error model at all. Asserting an Error would invent a requirement, so the assertion is that the timestamp value did not change, and the message reports which form the refusal took. A clarification for this is worth raising separately.

Anything about clock routing. CLK_REP ends with "Setting this bit also enables writing on the timestamp register", which contradicts CLK_LOCK disabling the same writes, and nothing says which wins. Both checks skip when CLK_REP or CLK_GEN is set, so they run only where both readings agree. That also avoids overriding clock routing, since the lock bits are written as a whole-register value.

Whether an unimplemented lock is a defect. Implementing R_CLOCK_CONFIG is only RECOMMENDED, so a device that refuses the write, or takes it with no effect, is skipped rather than failed. Both are treated the same because an unimplemented optional register is required to answer a write by reporting no effect, which makes the two indistinguishable by design. core.pico refuses the write today, so this is what keeps the checks meaningful on a Pico.

Verified on hardware

Behavior device on firmware 3.2, which implements the lock fully: 26 passed, 0 failed, 4 skipped of 30, exit 0, and the device left at 0x40 with CLK_UNLOCK set.

The undefined encodings were probed separately from known starting states, and the results are why the checks are shaped this way rather than asserting more. A locked timestamp write is answered with an Error and the value is unchanged. Writing both lock bits at once resolves as lock wins. Writing neither is a no-op preserving the current state. Every write is acknowledged, and the device never reports an invalid encoding.

Documentation

The warning gets one additional sentence, stating that an interrupted run can leave the timestamp register locked until the device is power cycled.