power sequencing

[hartytp]

@gkasprow can you remind me how the power sequencing is supposed to work please?

It's not obvious to me that the hardware actually implements that sequence. AFAICT, the first thing that happens is that EN_BIAS goes high, which stops pulling OUT_BIAS to the minimum possible value (pinch off). This occurs before the 29V rail is enabled.

Correct me if I'm wrong, but aren't we relying on the firmware to implement the sequencing:

• set DAC to max value (pinch off)
• set PWR_ON high
• wait for rails to stabilize
• increase OUT_BIAS to desired level

However, that's not what the firmware actually does right now:

bool rf_channel_enable_procedure(uint8_t channel)
{
    int bitmask = 1 << channel;

    if (channels[channel].error) {
        ucli_log(UCLI_LOG_ERROR, "Enabling channel %d with error condition!\r\n");
        led_bar_or(0, 0, (1UL << channel));
        return false;
    }

    // disable enabling power while DAC's are set to 0
    if (lock_take(I2C_LOCK, portMAX_DELAY))
    {
        i2c_mux_select(channel);
        i2c_dac_set(4095);

        lock_free(I2C_LOCK);
    }

    rf_channels_control(bitmask, true);
    vTaskDelay(10);

    if (lock_take(I2C_LOCK, portMAX_DELAY))
    {
        i2c_mux_select(channel);
        i2c_dac_set(4095);
        vTaskDelay(50);

        // input interlock removed, setting to 4095 for compatibility with older hardware
        i2c_dual_dac_set(0, channels[channel].cal_values.input_dac_cal_value);
        vTaskDelay(10);

        // set calibration values
        i2c_dual_dac_set(1, channels[channel].cal_values.output_dac_cal_value);
        vTaskDelay(10);

        // set calibrated bias current
        i2c_dac_set(channels[channel].cal_values.bias_dac_cal_value);
        vTaskDelay(10);

        lock_free(I2C_LOCK);
    }

    rf_channels_sigon(bitmask, true);
    vTaskDelay(5);
    rf_channels_sigon(bitmask, false);
    vTaskDelay(5);
    rf_channels_sigon(bitmask, true);
    vTaskDelay(50);

    // update struct information
    channels[channel].enabled = true;
    channels[channel].sigon = true;

    return true;
}

[hartytp]

@gkasprow my questions are:

• how bad is it if we don't follow the FET power sequencing on the data sheet? What is the downside of this?
• why do you enable the 5V rail before the 30V rail?
• generally, shouldn't the connections be:
  • FLAG 1: 30V rail enable
  • FLAG 2: bias en
  • FLAG 3: 5V rail

[hartytp]

Note to self, we have 60ms delays between each flag going high. The RC time constant on OUT_BIAS is 10nF||5k=50us, so that all seems about right.

[hartytp]

Well, maybe it doesn't really matter in our case, since we pre-calibrate the gate voltage required to give the recommended current.

Anyway, at the very least, we should make sure that the sequencing annotation reflects what we actually do...

[gkasprow]

The HW power sequencing is implemented to make sure that with broken firmware one won't be able to destroy the power stage. That's why bias wakes up first. Before enabling signal, T5 is on and IC22 output is tied to -5V rail. Here we assume that CPU set maximum positive DAC value before setting PWR_On signal. The IC22 output should be -3.3V Then sequencer enables 5V rail that powers the preamplifier. Then it enables 29V And here the CPU should set desired DAC voltage. When the amplifier power is switched off, the 5V0 and 3V3 rails are supplied by 4.7mF cap for some time. The C16 detects that power off started and pulls PGOOD to zero. This is connected to FORCE_OFFn which starts off sequence. The 29V rail is disabled first, then 5V and then bias.

[hartytp]

And here the CPU should set desired DAC voltage.

Okay, but that's not what the fw I posted above does...

[hartytp]

@gkasprow if you're happy with the current situation, please close this.

[hartytp]

(although I would have thought that you don't want to enable the 5V until after the PA stage is ready...)

[gkasprow]

I don't want. It would generate a huge spike at the output.

[hartytp]

aah, ok, makes sense