Hi rjo . Thanks for the reply.

The problem mentioned here was also not solved in the post you attached. But it seems the initial voltage on the power-up of the crate is solely controlled by the version of the DAC and could not be physically or programmatically changed. Is it correct?

    No. The issue proposes to start with disabled AFE, then set the DAC. Worst case there could still be rail ramp transients (which will always be be a (hardware) problem) but it would then immediately go to a well-defined voltage.

      Ah, thanks rjo .

      I will try it in a few weeks after I am back in the lab. So as far as I got it, I should flash modified gatewere.

      I have never done the modification of the gatewere. So far I only flashed kasli with the newer artiq version and expanded cards list.
      Is there some tutorial on how to prepare and send a flash image for cards themself? So far I found this, with which I can create a flash image for the card (?) but I am not sure where could I modify the afe_power. Is it this line or that?

      Or should I just modify this line in the init function?

        To do it yourself you'll need to learn how this all works, how to set it up and how to write gateware. Explaining that is out of scope here.
        Or contract somebody else to do it. The latter is how these things are developped.

          a month later

          I observed a similar problem: When calling the method init from the class Fastino (doc: https://m-labs.hk/artiq/manual-beta/_modules/artiq/coredevice/fastino.html) the voltage of channel 0 (maybe all channels, but only channel 0 tested) changes to -10V. The documentation, however, states:

          It does not change set channel voltages and does not reset the PLLs or clock domains

          The following code line in Fastino.init is to blame (link to line on github: https://github.com/m-labs/artiq/blob/master/artiq/coredevice/fastino.py#L84):
          self.apply_cic(0xffffffff)

          The behavior is unexpected and caused us a few days of work and destroyed two of our chips. It would be nice to either fix the documentation or change the behavior of Fastino.init().

          As the note below the line you quote says, that transient is related to the firmware version. Do try updating it.

          18 days later

          Hi rjo

          I managed to flash the Fastino with newest gatewere. This, as expected, didn't solve my problems.
          Then I modified the fastino_phy.py (line 199)
          platform.request("en_afe_pwr").eq(cfg.afe_pwr_n),
          I remover ~ to invert the signal.
          Then I created new gatewere (fastino.bin).
          I have successfully flashed it to the card and now the card outputs 0.62V (acceptable for us) on startup. And after initialization with startup kernel (basic one) the voltage goes to 0.7V.

          Unfortunately, I couldn't figure out how to make the afe_pwr back on in the script. I tried
          self.set_cfg(reset=0, afe_power_down=0, dac_clr=0, clr_err=0)
          But this did not have any effect.

          During startup of the crate 2 LEDs are shining on the Fastino: FD and ER. After startup kernel it is only one LED FD.

          Do you have some ideas? Am I missing something?

            As you inverted it, do afe_power_down=1.

              rjo
              This I also tried, but, unfortunately, no effect.
              I tried putting it in both build and run sections of the code (as separate attempts).

              Or should I do it twice as in the init:
              self.t_frame = int64(14*7*4)
              self.set_cfg(reset=0, afe_power_down=1, dac_clr=0, clr_err=1)
              delay_mu(self.t_frame)
              self.set_cfg(reset=0, afe_power_down=1, dac_clr=0, clr_err=0)

                This may also require changes in the RTIO PHY.

                  21 days later

                  Hi rjo. After a few weeks of the system being off (disconnecting the power supply) everything works as it should with:
                  afe_power_down=1
                  Don't know what was the problem directly after flashing.
                  The problem with the initial voltage is solved (still need to check for transients with the oscilloscope)

                  • rjo likes this.
                    10 months later

                    Hi. I will ask my question here as it is similar to the discussion above:
                    I am using a kasli-soc v1.2 and a Fastino v1.2.1
                    After reading it, the simplest solution is to have a code to initialize everything, as you say (which is what I was going to do anyway). However, imagine that my channel output 1 is connected to something that only accepts 5V and by default the channel starts with 10V. I can set the outputs to 0 before connecting the device. Imagine that during the night the power goes off and then on. Then this channel will output 10V again and damage my device.

                    Having said this, I would like to know how the community faces this potential issue. Maybe, there is a way to launch a code automatically right after the device turns on or maybe, the new artiq release allows an extra line in the configuration .json file used to generate the boot.bin to solve the issue.

                    a month later

                    Hi,
                    could someone who succeeded in following the steps explained in post 8 explain them a bit more? I could not find fastino_phy.py in the artiq package nor artiq-zynq.

                    So far I used the instructions to flash on a microSD card the firmware and gateware for the kasli-soc. I have not much knowledge on this topic, so I do not know how to connect these two points. Any tip on how to start?

                    16 days later

                    Hi,
                    I have the same issue and I'm also using SD card to flash my kasli-soc. Does someone know how to do it or the first step?