Stabilizer + Pounder panics on bootup

[ryan-summers]

If the Pounder+Stabilizer combination is flashed and rebooted, it has been reported that it will panic without the debugger attached (as indicated by the red LEDs powered)

Upon using a debugger reset, the panic is resolved.

First reported by @jordens

[ryan-summers]

The panic appears to be occurring because the AD9959 register CSR readback is mismatching the configured value. This reminds me of #101, and I'll continue investigating what's happening here.

[ryan-summers]

Here, you can see captures from signals to the DDS including MASTER-RESET, IO_UPDATE, CSn, and the output of OSC1 on pounder. OSC1 is used to source the DDS system clock. As can be seen, the master reset and IO update occurs before the OSC1 output enables, which means that these signals are not actually registered by the DDS. Similarly, register writes without the DDS clock input do not stick.

It appears that the DDS initialization procedure is occurring before the oscillator actually turns on, which is why register configurations aren't sticking until the device is power cycled. We likely need to implement a detection mechanism to tell if the oscillator is actually powered. Perhaps we could repeatedly execute the configuration process until the CSR value sticks... I'll investigate part specifications.

[jordens]

Pretty sure the SPI interface works fine without the refclk input as it's a bootstrap requirement for e.g. xtal setup. I don't see the requirement for clock to be up before talking SPI. Also can't find it in the datasheet.
The only thing is the master reset vs sysclk requirement. Maybe just moving the reset after the identification is enough. But that's fragile as the register we use isn't just some identification register.
If that doesn't help, at boot we always use the internal oscillator. Just waiting for it to come up should do it then. I.e. increase the reset delay to 1 ms.

[ryan-summers]

The IO_Update and MASTER_RESET signals require a minimum 1 sync clock period:

Without I/O update, the register configurations do not become active:

Thus, if we have no SYNC-CLK (which is derived from REF_CLK), there is no way to modify internal registers.

[ryan-summers]

Additionally, the clock selection is not done over the SPI interface, it's done via an external CLK_MODE_SEL pin:

Thus, if we have this driven low permanently, we always use an external oscillator, which may not be fully on.

[jordens]

Clock configuration is done through FR1. If that's not configured it's somewhat unclear that a useful sysclk is available, ergo the SPI interface should work without clock. My guess is that we're actually running into the reset pulse timing issue.
CLK_MODE_SEL isn't relevant here as there is no safe way to have that high. There is no other reference oscillator.

[ryan-summers]

There are two oscillators that we are concerned about:

• The external OSC1 output (input through REFCLK)
• The internal AD9959 oscillator

The CLK_MODE_SEL is used to select between the internal oscillator of the AD9959 and the external REFCLK inputs:

If we have CLK_MODE_SEL driven permanently low, the on-chip oscillator is disabled and the AD9959 is clocked entirely through REFCLK inputs (which is not oscillating)

FR1 does not control selection between the internal clock and the external clock, it only allows powering down the REFCLK input pins (but they are powered up by default)

[jordens]

No. There is no internal reference oscillator. What you are referencing is an external passive quartz.

[ryan-summers]

Ah you're correct here. However, the point stands that there is no clock input on REF-CLK. And the data sheet explicitly says that there has to be a single SYNC-CLK cycle to register the I/O_Update signal (because it is synchronous). Thus, without input on REF-CLK, there is no SYNC-CLK, and the I/O_Update signal will never be registered.

FR1 configuration is not required to generate a SYNC-CLK source - there just has to be any type of oscillation on REFCLK (either via crystal or oscillator, as selected by CLK_MODE_SEL) to generate a SYNC-CLK which can then be used to access and modify registers

[jordens]

FR1 is definitely required! It's not like anything always generates a valid sysclk of sync clk. Imagine having it configured to use the PLL. Then the refclock frequency changes which can make FR1 invalid such that the PLL doesn't lock or isn't stable. Then you want to change FR1 but you don't have a valid clock.
The only hope would be that master reset is robust and works well enough and in absolutely every situation to set the clocking circuitry to pass-through to do the rest of its reset machinery (which then again needs a clock).

[ryan-summers]

FR1 is definitely required! It's not like anything always generates a valid sysclk of sync clk. Imagine having it configured to use the PLL. Then the refclock frequency changes which can make FR1 invalid such that the PLL doesn't lock or isn't stable. Then you want to change FR1 but you don't have a valid clock. The only hope would be that master reset is robust and works well enough and in absolutely every situation to set the clocking circuitry to pass-through to do the rest of its reset machinery (which then again needs a clock).

While my assessment of your statements agrees that there could be problems if you change your refclk, there's nothing in the datasheet (or observed behavior) that indicates that you can modify registers without a REFCLK. Attempting to access and modify device registers while the REFCLK inputs are idle does not appear to result in registers sticking. I can try larger I/O_Update periods, but I doubt that would resolve the issue (since there's no clock at all)

[jordens]

We should definitely just make sure we have (a) the oscillator up, (b) selected and (c) clocking before the reset. The rest shouldn't need changes AFAICS.