<rjo>
note that there is no error in the startup_kernel.
<rjo>
could you try dac_setup.py now?
<jbqubit>
yes...
<rjo>
i got two more minutes. then i'll have to leave for a while.
<jbqubit>
refresh the gist
<jbqubit>
for output of dac_setup.py
<jbqubit>
ConnectionResetError: [Errno 104] Connection reset by peer
<rjo>
that's new.
<rjo>
and you definitely didn't change anything from when you first filed that issue report to now?
<rjo>
your commands have shown three different outcomes so far.
<rjo>
ip address is definitely that very board?
<jbqubit>
Not true. I disconnected things to confirm stuff like phase lock of clocks. The reconnected .
<rjo>
phase lock of which clocks?
<jbqubit>
The KC705 responds to ping.
<rjo>
sure. and there is exacly one kc705 on that network?
<jbqubit>
2 GHz clock to J1 and clock to KC705 on USER_CLK_N and _P.
<rjo>
and there is exacly one kc705 on that network?
<rjo>
jbqubit: you should not see anything on user_clk_n or p.
<jbqubit>
125 MHz to KC705
<rjo>
anyway. gotta go. see you later.
<rjo>
jbqubit: don't do that.
<jbqubit>
I'm sending differential clock to KC705.
<rjo>
why?
<rjo>
it doesn't use that.
<jbqubit>
Not sure if you're automatically switching to external clock.
<jbqubit>
Based on previous system I expected FGPA clock and DAC clock needed to be phase synchronous
<rjo>
don't assume things or speculate about how this works. it's not helpful.
<rjo>
the fpga rtio clock is derived from the what the fpga gets from the clock distribution chip.
<jbqubit>
Do FGPA clock and DAC clock need to be phase synchronous?
<rjo>
there is no fpga clock.
<jbqubit>
ok
<rjo>
no clock coming from you anyway.
<rjo>
anyway. gotta go.
<rjo>
bbl
<jbqubit>
OK. I'll be here if you're available after your dinner.
kuldeep has quit [Ping timeout: 256 seconds]
sandeepkr_ has quit [Read error: Connection reset by peer]
sandeepkr_ has joined #m-labs
jbqubit has quit [Ping timeout: 260 seconds]
jbqubit has joined #m-labs
<jbqubit>
ok
<jbqubit>
miraculously is started to work then stopped again
<rjo>
exactly what worked?
<jbqubit>
dac_setup.py
<jbqubit>
test_ad9154_prbs.py
<jbqubit>
test_ad9154_status.py
<jbqubit>
test_ad9154_stpl.py failed
<rjo>
jbqubit: please read the readme and observe the note on prbs testing.
<jbqubit>
yes.
<rjo>
are you trying to say you did that?
<rjo>
and what does "stopped working" mean?
<jbqubit>
the failures I observe are occasional. They include a) socket.timeout: timed out b) ConnectionResetError: [Errno 104] Connection reset by peer
<rjo>
you will get an a) after each b) because you crashed the core device.
<jbqubit>
OK
<rjo>
i don't know how you do that. are you absolutely sure you used the correct toolchain to compile runtime, bios, startup_kernel, and the other kernels?
<rjo>
how does _stpl fail.
<rjo>
i.e. always be specific. "fail" is not something anyone can debugs. does it crash, does it say "FAIL"?
<jbqubit>
You've already observed that I am capable of poor python library hygiene.
<rjo>
well. which do you prefer: learn how to do it or receive instructions and follow them blindly?
<jbqubit>
My understanding improves with our every interaction Robert.
<rjo>
i will take that as a "neither" then ;)
<jbqubit>
OK. Just rebooted the KC705. Then ran dac_setup.py. It was returned without error.
<jbqubit>
What would you like me to try now.
<jbqubit>
?
<rjo>
then run the demo.py and look at ch1 and ch2 on a scope
<jbqubit>
running demo.py... it doesn't return... KC705 LEDs 4...7 are blinking at about 1 Hz
<rjo>
i.e. keep demo.py running. it won't end by itself.
<jbqubit>
No output on scope.
<rjo>
all good.
<jbqubit>
OK. What's next.
<rjo>
ctrl-c on demo.py and run that *_status.py
<rjo>
test_ad9154_status.py
<rjo>
paste the output, preferrably _not_ in a comment on a gist.
<jbqubit>
No output... ConnectionResetError
<jbqubit>
$ artiq_run repository/test_ad9154_status.py Traceback (most recent call last): File "/home/britton/anaconda3/envs/artiq-phaser/bin/artiq_run", line 11, in <module> load_entry_point('artiq==3.0.dev0+159.gbf942fc.dirty', 'console_scripts', 'artiq_run')() File "/home/britton/artiq-dev-phaser/artiq/artiq/frontend/artiq_run.py", line 221, in main return run(with_file=True) File "/home/britton/artiq-dev-phaser/artiq/artiq/f
<rjo>
yeah.
<rjo>
don't pase that here!
<rjo>
*paste
<jbqubit>
You prefer pastepin?
<jbqubit>
bin
<rjo>
use pastebin, hastebin, a gist, anything.
<rjo>
no. if the error is connetion reset, you need to restart, and run dac_setup.py again.
<rjo>
then run *_status.py
<jbqubit>
did reset
<jbqubit>
but dac_setup.py fails with Connection reset by peer
<jbqubit>
trying again
<jbqubit>
now dac_setup.py returns
<jbqubit>
_status successful
<jbqubit>
creating gist
<rjo>
that artiq/phaser commit that you are using is not the current one. it should not work.
<jbqubit>
ommit bf942fc22858370dd378343aa5b36e6ec8fb39e6 Author: Robert Jordens <rj@m-labs.hk> Date: Tue Oct 18 11:37:27 2016 +0200 ksupport: adapt to dyld_load()
<jbqubit>
is what I'm using
<rjo>
good. run demo.py and look athe dac channels.
<rjo>
yes. ok. that one should work.
<rjo>
but do a git diff and paste the result. there should be only the ip change in device_db.pyon
<jbqubit>
before proceeding please explain how I should interpert "that artiq/phaser commit that you are using is not the current one. it should not work."
<rjo>
just did.
<rjo>
there is one more current but that's irrelevant for this.
<rjo>
by the way. user_sma_n is used as an output (!). if you put stuff into there, i could imagine problems in the worst case.
<jbqubit>
Yes. There are still many many crashes.
<rjo>
good.
stekern has joined #m-labs
<rjo>
yeah. the crashes are not something i have seen ever.
<rjo>
i'd still suspect a broken toolchain somewhere.
<rjo>
if you get a crash, there should be something (that looks a bit like a windows bluescreen or linux kernel panic, i.e with hexadecimal numbers... on the console. please paste.
<jbqubit>
Where should I be looking?
<rjo>
for what?
<jbqubit>
"if you get a crash..."
<rjo>
"on the console" that's that flterm command
<jbqubit>
OK
<jbqubit>
Rebooting with flterm connection.
<rjo>
do a "reboot, dac_setup.py, demo.py" iteration a few times.
<jbqubit>
I observe Connection reset by peer error... but no output on serial port to flterm
<jbqubit>
the last characters on serial connection are "Accepting network sessions."
<jbqubit>
ping 192.168.1.71
<rjo>
hmm. the comms cpu crashing hints to broken runtime. could you flash the three binaries from the conda package referenced above?