<GitHub78>
artiq/master 6b7e6a5 Sebastien Bourdeauducq: firmware: ad9154 timeouts and logging
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined #m-labs
<sb0>
oh and the reason I need the RTIO PLL operating for the JESD ready to come high is "AsyncResetSynchronizer(self.cd_jesd, ResetSignal("rio_phy"))"
<sb0>
so this is explained
<sb0>
is it the best way to generate that reset though? i'd rather put that on the system reset
<rjo>
cd_jesd is not valid until very late.
<rjo>
only after clock_setup()
<sb0>
okay, so it should probably have its own CSR
<sb0>
also, shouldn't there be some delay after the AD9516 is set up?
<sb0>
or busy-waiting on its lock status
rohitksingh has joined #m-labs
<rjo>
until what? the ad9516 needs no locking.
<rjo>
csr is fine.
<sb0>
how much time does it take to generate valid clocks after UPDATE_ALL_REGISTERS?
<sb0>
we're configuring a VCO divider before, it sounds like that would need locking
<rjo>
should be "instantly".
<sb0>
ok...
<rjo>
divider for some external vco.
<rjo>
external or internal but we don't use the internal one.
<whitequark>
ok, trying to use xargo was a mistake.
<sb0>
rjo, btw, running demo.py causes "artiq.coredevice.exceptions.RTIOBusy: RTIO busy on channel 22", and it breaks demo_2tone.py with "artiq.coredevice.exceptions.RTIOBusy: RTIO busy on channel 16" until the device is rebooted
<whitequark>
the Rust core implements quite a few of features for freestanding, and which it doesn't, it ignores completely
<whitequark>
whereas 3rd party crates that are supposed to "provide" that are full of bugs
<whitequark>
I'm just going to fix the Makefile we have.
<rjo>
sb0: that's already done. the wishbone wrapper is in artiq. one could move that to misoc as well if there is need.
rohitksingh has quit [Quit: Leaving.]
<cr1901_modern>
I thought the reason the wishbone wrapper was in artiq in the first place was due to chained xfers (which CSR by design can't really support)
<sb0>
okay so phaser still works on master
<sb0>
how the fuck did my code changes cause the busy errors...
<cr1901_modern>
rjo: Did you have anything to do w/ the JTAG lm32 feature, such as implementing OpenOCD support?
<cr1901_modern>
cc: mithro ^^
<sb0>
cr1901_modern, that was mwalle
<cr1901_modern>
Ahhh. At least two boards I have are crashing after a few iterations of any loop (printf, uart, dummy loop) during firmware boot using lm32
<sb0>
rjo, what does the busy signal depend on? the sawg logic doesn't get any feedback from jesd, right?
<sb0>
if the ad9516 clock frequency was off, everything would get scaled down and this wouldn't cause busy errors either
<bb-m-labs>
build #1197 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1197 blamelist: whitequark <whitequark@whitequark.org>, Sebastien Bourdeauducq <sb@m-labs.hk>
<sb0>
whitequark, building locally fails with or1k-linux-ld: cannot find cargo-ksupport/or1k-unknown-none/debug/libksupport.a: No such file or directory
<whitequark>
sb0: can you post the entire verbose log