Reset value of XOSC STARTUP register?

[dhalbert]

The bootrom code starts the XOSC, and waits for a startup delay, but does not set the STARTUP register beforehand (at least I can't find it).
https://github.com/raspberrypi/pico-bootrom/blob/00a4a19114195e20fb817bdfbca1165e157eef37/bootrom/bootrom_main.c#L137-L146

    // Try to get the crystal running. If no crystal is present, XI should be
    // grounded, so STABLE counter will never complete. Poor designs might
    // leave XI floating, in which case we may eventually drop through... in
    // this case we rely on PLL not locking, and/or resuscitate counter.
    //
    // Don't touch range setting: user would only have changed if crystal
    // needs it, and running crystal out of range can produce glitchy output.
    // Note writing a "bad" value (non-aax) to RANGE has no effect.
    xosc_hw->ctrl = XOSC_CTRL_ENABLE_VALUE_ENABLE << XOSC_CTRL_ENABLE_LSB;
    while (!(xosc_hw->status & XOSC_STATUS_STABLE_BITS));

But there is not a reset value given in the datasheet:

Is the bootroom code expecting and depending on a particular reset value for STARTUP? Thanks.

This may be relevant to raspberrypi/pico-sdk#401 (comment).

[aallan]

@Wren6991 thoughts?

[dhalbert]

@eightycc says an empirical measurement shows it's 47: raspberrypi/pico-sdk#401 (comment)

[lurch]

Just out of curiosity I had a quick look at the source for the XOSC register-block, and the reset values for the X4 and DELAY fields are set by (external) params rather than having an internally-defined reset value (which is why their reset values aren't shown in the datasheet). And I dunno the structure of the rest of the chip source well enough to know where these param values get set.

[Wren6991]

X4 resets to zero. We have the ability to change this with a silicon rev (which is its purpose really)

DELAY resets to 0xc4, which is a nominal 1 ms delay at the maximum XI frequency of 50 MHz, in units of 256 cycles.

The empirically-determined 47 sounds like it would be the correct value for 12 MHz (47 * 256 ~= 12000 cycles) so perhaps that has not been read directly after reset? 47 would also be the value written by xosc_init() in xosc.c

[Wren6991]

The bootrom code starts the XOSC, and waits for a startup delay, but does not set the STARTUP register beforehand (at least I can't find it).
Is the bootroom code expecting and depending on a particular reset value for STARTUP? Thanks.

It's handling two cases:

1. XOSC is not running, registers are untouched -- rely on the reset value
2. XOSC is running, registers may be dirty -- register write sequence chosen so that it should have no effect on the already-running XOSC, and following delay loop drops straight through.

The XOSC digital controls will preserve the last valid value written to the RANGE field when an invalid value (no 0xaa) is written, and this decode logic is registered before being presented to the XOSC PHY itself, so there should be no glitching of the XOSC's range input caused by the write to xosc_hw->ctrl.

All that being said, it's interesting that the bootrom has a ~4x longer startup delay than the SDK code, because it's using the maximum XI frequency of 50 MHz for the range calculation (in hw source), rather than the nominal 12 MHz.

I'll see if I can get those reset values to appear in the datasheet like they should.

[Wren6991]

The live datasheet has the reset values now