Ultra slow clock for debugging
JRoark
Posts: 1,215
in Propeller 1
Back in the heyday of the Z80 we would occasionally need to single-step the chip to chase odd bugs. After booting at a normal speed, the clock would then be switched-over to a bounceless pushbutton or a (very slow) oscillator. As long as the RAM was static RAM, this worked fine. The chip didnt care.
Can this same strategy be used on the Prop1 (assuming we dont care about upsetting any timing-critical external components and we use a direct/non-pll clock mode)? I know the Prop1 works fine at 32khz, but will the internals hold-up to very long pauses between clock pulses? What about the Prop2?
Can this same strategy be used on the Prop1 (assuming we dont care about upsetting any timing-critical external components and we use a direct/non-pll clock mode)? I know the Prop1 works fine at 32khz, but will the internals hold-up to very long pauses between clock pulses? What about the Prop2?
Comments
Yes, you can clock the P1 as slow as you like.
Cronk: here is what I’m doing. YMMV. Make yourself a bounceless pushbutton (BPB) circuit and wire it to the Prop clock_in pin via a couple of gates. What you want is basically a data selector circuit that allows switching between the “fast” external clock and the “slow” BPB clock using a single input as control. Tie the control line to any free Prop pin. At boot time the Prop deasserts the pin output and the “data selector” logic routes the fast external clock to the Props clock_in. When you hit the part of your code where you need to slow the clock, assert the pin. Now the “data selector” switches to feed the BPB input to the Props clock_in and you can single-step it. When you exit the function where the slow clock is needed, simply deasserting the pin puts the Prop back up to full-speed.