sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
ylamarre has joined #m-labs
<sb0> _florent_, in litesata, RXLPMEN is not a "RX Margin Analysis port"
sandeepkr has quit [Read error: Connection reset by peer]
sandeepkr has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 258 seconds]
rohitksingh has joined #m-labs
kuldeep_ is now known as kuldeep
rohitksingh has quit [Quit: Leaving.]
balrog has quit [Ping timeout: 246 seconds]
balrog has joined #m-labs
ylamarre1 has joined #m-labs
balrog has quit [Ping timeout: 276 seconds]
balrog has joined #m-labs
ylamarre has quit [Ping timeout: 272 seconds]
ylamarre1 has quit [Quit: ylamarre1]
mumptai has quit [Remote host closed the connection]
mumptai has joined #m-labs
bhamilton has joined #m-labs
bhamilton has quit [Remote host closed the connection]
bhamilton has joined #m-labs
<cr1901_modern> sb0: In migen, if I decorated a combinational Case statement with a CEInserter, and if chip-enable was not asserted, the signals affected by the case statement would take on their reset values. Is this correct?
bhamilton has quit [Remote host closed the connection]
<attie> cr1901_modern: clock enable only affects sync statements, I don't think decorating a case would change anything at all
<cr1901_modern> Oh I thought CE meant Chip enable... ._.
<cr1901_modern> but yes, that makes more sense
<cr1901_modern> In any case, I'll just use a Mux to force a default case if conditions aren't met
<cr1901_modern> attie: ^^ Thanks. Basically I screwed up lol
<sb0> you can encapsulate the "case" in a "if" for doing that
<cr1901_modern> okay, thanks
FelixVi has joined #m-labs
sandeepkr_ has joined #m-labs
sandeepkr has quit [Ping timeout: 240 seconds]
kuldeep has quit [Ping timeout: 252 seconds]
ylamarre has joined #m-labs
kuldeep has joined #m-labs
kuldeep_ has joined #m-labs
sandeepkr__ has joined #m-labs
kuldeep has quit [Ping timeout: 244 seconds]
sandeepkr_ has quit [Ping timeout: 260 seconds]
<FelixVi> Hi, would anybody have suggestions why jtagspi can't enable write on a LX45 in openocd? Loading bitfiles as well as writing to a flash on an LX9 works fine
<FelixVi> In xilinx_bscan_spi.py, what's the purpose of *pullups in the package definitions? Can those cause problems if not configured properly?
<FelixVi> Signals to the flash are there, but I'm still getting the same error
stekern has quit [*.net *.split]
acathla has quit [*.net *.split]
cyrozap has quit [*.net *.split]
cyrozap has joined #m-labs
stekern has joined #m-labs
acathla has joined #m-labs
<FelixVi> rjo, I went through jtagspi.c and uncommented some of your debug output statements and ran it again
<FelixVi> this is the output with some of the repetitive outputs deleted
<FelixVi> could you please take a look? Maybe you can spot what's going wrong there
<FelixVi> it looks like it's actually writing fine, but runs into a problem at 0x00024000
<FelixVi> it looks like the page is protected and that's causing trouble
<FelixVi> Debug: 15567 39972 jtagspi.c:207 jtagspi_read_status(): status=0x000000ff <- this is confusing because I'd think status should never be 0xFF
FelixVi has quit [Remote host closed the connection]
FelixVi has joined #m-labs
sandeepkr_ has joined #m-labs
<FelixVi> rjo, when I write to flash with an offset, the error moves with the offset
<FelixVi> so something happens that causes the error at the end of the bin file
<FelixVi> do you use promgen to generate bin files?
kuldeep_ has quit [Ping timeout: 258 seconds]
sandeepkr__ has quit [Ping timeout: 244 seconds]
kuldeep_ has joined #m-labs
sandeepkr__ has joined #m-labs
sandeepkr_ has quit [Ping timeout: 252 seconds]
<rjo> FelixVi: generating bin from bit is a trivial extraction. https://github.com/m-labs/artiq/blob/master/artiq/frontend/bit2bin.py
<FelixVi> rjo, that's what I figured - so there should be no problem there
<FelixVi> I find it puzzling that it always fails close to the end of the procedure
<FelixVi> rjo, do you have any thoughts what the status 0xff might be about?
<FelixVi> that always happens right before it crashes
<rjo> flash status register?
<rjo> it doesn't crash
<FelixVi> yeah
<FelixVi> it really shouldn't be 0xff
<rjo> status=0 when it crashes.
<rjo> 'crashes'
<rjo> ... when it exits
<FelixVi> yeah, and status 0xff always happens right before status 0x00 in the write_enable function
<FelixVi> so I think they are connected
<rjo> when is status=0xff read?
<FelixVi> I was just wondering if you've seen that before when you were troubleshooting jtagspi.c
<rjo> and if you suspect it's related to the bitstream: try another one.
<FelixVi> when trying to write the last but one page
<rjo> i wrote jtagspi.c there was no troubleshooting. it was really straight forward as there was similar code already in other files.
<rjo> point me to the line.
<FelixVi> line 493 is the 0xff status
<FelixVi> and line 500 is when it can't enable the write anymore
<rjo> there is no line 493 in jtagspi.c
<rjo> give me a link to the file.
<FelixVi> oh, I was looking at the pastebin
<FelixVi> that's the log of when the error occurs
<FelixVi> in jtagspi.c, line 237 is where it checks for status after sending the write_enable command
<FelixVi> I get the same error when using a different bin file, too
<FelixVi> in ISE, all checkmarks are green for the bitfile generation
<rjo> no. the status after write_enable is 0. that's why it exits
<rjo> i never really used the graphical tools.
<rjo> try flashing the bin of the proxy bitstream. generate it with e.g. bit2bin.py
<rjo> i don't even know what those checkmarks are or mean.
<FelixVi> they mean that the bitfile was generated without any errors or warnings
<FelixVi> and loading that directly checks out as well
<FelixVi> so I am confident about that part at least
<rjo> do the differntial test. it is independent of any beliefs.
<FelixVi> ok, converting the bit with bit2bin and trying to flash it gives me the same error
<FelixVi> and the bit file loads just fine with pld load
<FelixVi> I'm not sure where else to look at this point
<rjo> try flashing the bin of the proxy bitstream. generate it with e.g. bit2bin.py
ylamarre has quit [Ping timeout: 250 seconds]
<FelixVi> rjo, OK, the problem is the pagesize - it wasn't set correctly
<FelixVi> it's working fine now
<rjo> which pagesize?
<FelixVi> for the flash
<FelixVi> apparently you set those to 0x100 by default - but it needs 0x20
<FelixVi> rjo, see here https://github.com/FelixVi/openocd
mumptai has quit [Quit: Verlassend]
<rjo> FelixVi: what does "apparently" mean here?
FelixVi has quit [Ping timeout: 250 seconds]
ylamarre has joined #m-labs
FelixVi has joined #m-labs
<FelixVi> rjo, that's what is in your openocd branch
<FelixVi> I'm not sure what you were doing when you wrote the config for different ics, but it looks like you started with 0x100 for all of them and then edited the ones you ended up using
<FelixVi> it was just a bit confusing because there's no note that page size is a parameter that the user needs to change