<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1067: Can you try by using the startup kernel? Likely there is intermittent memory/gateware corruption (did you rework the HMC7043 reset?) and running the whole TCP/IP stack is more likely to crash than running simpler code. Also disconnect Ethernet during the test so that the CPU doesn't have to process network broadcasts. https://github.com/m-labs/artiq/issues/106
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1067: Can you try by using the startup kernel? Likely there is intermittent memory/gateware corruption (did you rework the HMC7043 reset?) and running the whole TCP/IP stack is more likely to crash than when running simpler code. Also disconnect Ethernet during the test so that the CPU doesn't have to process network broadcasts. https://github.com/m-labs/artiq/issue
sb0 has joined #m-labs
sb0 has quit [Quit: Leaving]
<_florent_>
sb0: i'll fix the reset/init of low speed serwb
sb000 has joined #m-labs
<sb000>
but low speed serwb is still quite complex for what it does. and aren't there still unexplained bugs with it?
<_florent_>
sb000: except the reset/initialization issue, i'm not aware of others bugs
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #1065: @hartytp We'll check without RTM tommorow. We used the same build on several boards and only two showed such issues so it's more likely to be some kind of hardware failure. https://github.com/m-labs/artiq/issues/1065#issuecomment-396281132
<GitHub-m-labs>
[artiq] hartytp commented on pull request #1068 2621782: Extra reviews are always welcome. However, in this case I don't think it's necessary. I've checked this all through against the data sheet carefully and tested it on my hardware. I'm inclined to say that if it works reliably on other HW as well then further review isn't worth the time it would take (but if you have spare time then go for it!). htt
<GitHub-m-labs>
[artiq] hartytp commented on issue #1068: @marmeladapk @jbqubit @sbourdeauducq it would be great if one or more of you could check that this works on your boards before we merge this. Thanks! https://github.com/m-labs/artiq/pull/1068#issuecomment-396360368
<hartytp>
master (10b87ac) which combines my two PRs
<hartytp>
without SAWG
<_florent_>
hartytp: interesting, i'll look at taht
<hartytp>
but, of course, that bricks Sayma
<hartytp>
no uart
<hartytp>
sigh
<_florent_>
hartytp: but these are firmware changes only no?
<hartytp>
yes
<hartytp>
we've seen this before
<hartytp>
the UART death seems to be a build-build variation where the code differences between builds have no connection whatsoever with anything UART related
<hartytp>
I'm wondering if it's a vivado bug, but can't test that atm because Sayma doesn't meet timing on 2017.x
<hartytp>
well, I can fix that by changing ethernet clock constraints, but I haven't done that yet
<hartytp>
we're definitely rooting out Sayma bugs, but it's bloody slow
<hartytp>
need to confirm this, but I'm pretty sure that the build can be fixed by rebuilding only the fw
<hartytp>
with a slightly different version of ARTIQ
<hartytp>
i.e. no recompile gateware
<hartytp>
anyway, will look at that in the morning
<hartytp>
actually, I don't want to wake up to this...
<hartytp>
will investigate a little
<hartytp>
hmm rebuilding from master didn't fix it this time, so maybe something has happened to my hw. will have to check in the morning
hartytp has quit [Quit: Page closed]
<GitHub-m-labs>
[artiq] hartytp commented on issue #1064: Resetting artiq to current master (0b86225) and rebuilding gateware and firmware fixed this. Rebuilding just the firmware (with `--no-comiple-gateware`) did not seem to (although I will double check those observations tomorrow.... https://github.com/m-labs/artiq/issues/1064#issuecomment-396405861