<_florent_>
you have to use with_uart=False for the SoC
<ysionneau>
ah ok
<_florent_>
and share_uart=True on the Uart2Wishbone bridge
<ysionneau>
ah right and then you instantiate the uart with the shared_pads
<_florent_>
yes
<ysionneau>
so I can still communicate with my application, to trigger my spiflash command, and meanwhile have the miscope dump the signals
<ysionneau>
awesome!
<ysionneau>
thanks will try that
<_florent_>
no, you can't do both at the same time... :(
<ysionneau>
ah :o
<ysionneau>
so basically if I add miscope in the design, I won't be able to have the BIOS prompt?
<ysionneau>
well, I guess I can do without it, if I put my command at boot time
<_florent_>
in fact UART2Wishbone has an internal mux for the UART controlled by a CSR register
<ysionneau>
ah ok!
<ysionneau>
so I can use UART to trigger my command, then before sending my command I put the uart into "miscope" mode
<_florent_>
yes you can do that
<ysionneau>
super cool
<ysionneau>
first, let's fetch some food :'
<ysionneau>
thanks!
<_florent_>
by default mux UART is connected to the CPU
<_florent_>
mux UART --> UART..
<ysionneau>
ok
nicksydney has quit [Ping timeout: 244 seconds]
nicksydney has joined #m-labs
<ysionneau>
_florent_: humm I think miscope does not work with newer misoc versions
<ysionneau>
uart code has changed a bit
<ysionneau>
I get an issue line 106 of uart2wishbone.py
<ysionneau>
AttributeError: 'Source' object has no attribute 'd'
<ysionneau>
let's see if I can fix that
<_florent_>
ah ok, I'll fix that
<ysionneau>
maybe now it's rx.source.payload.d
<ysionneau>
same for tx.sink.payload.d
<sb0>
ysionneau, is there a problem with the external LA or are you just trying out miscope?
<_florent_>
it should be ok now
<ysionneau>
sb0: I see correct external signals but I don't understand why my CSRStorage does not sample correctly the dq.i line
<ysionneau>
I can see on my external LA the dq.i line being correct but in software I don't read it
<ysionneau>
_florent_: ok thanks!
<ysionneau>
so now trying miscope to have a look at internal signals
<ysionneau>
to explain more precisely : I am now able to send the "Read Status Register" command to the spiflash to poll the "Write In Progress" bit, I can see everything is correct on my external LA
<ysionneau>
but it's just the latching of dq.i in my CSR reg which is wrong I guess
<sb0>
CSRStorage is CPU to logic. to sample an input, you'd rather use CSRStatus....
<ysionneau>
ah, I was using CSR (not CSRStorage), is that also wrong,
<ysionneau>
?
sj_mackenzie has quit [Remote host closed the connection]
<_florent_>
with only CSR, there is no memorization
<sb0>
CSR would work too, if you drive its "w" signal
<sb0>
the advantage of CSRStatus is it can be automatically split if it's wider than the bus
<ysionneau>
yes I am doing self.miso.w.eq(dq.i)
<ysionneau>
(it's just 1 bit wide)
<sb0>
when you do self.miso.w.eq(1) do you read 1 from the sw?
nicksydney_ has joined #m-labs
<ysionneau>
ah indeed let's try that
<sb0>
if so, it's probably a tristate issue
<ysionneau>
ah yes maybe, because the line is really 1, but yes maybe I'm not in input or something like that
<ysionneau>
the printed "sr" by the wait_for_device_ready() function is always 00
<ysionneau>
sb0: yes all my slices are kind of ugly, I will rewrite them
<sb0>
dq.i looks fine
<ysionneau>
12:35 < sb0> [-1] also works, and you should create another register for the mux < so that I don't need to repeat the ' | BITBANG_ENABLED' each time?
<sb0>
yes
<ysionneau>
ok
<sb0>
the clock is broken when div == 1
<sb0>
you should use a comb mix
<sb0>
*mux
<sb0>
at least for the clock
<ysionneau>
ah yes
<ysionneau>
you mean I have metastability issues on my clock for div == 1 ?
<ysionneau>
because some part is comb and the rest is synchronous?
<sb0>
no, when div == 1 you are registering the clock signal, which is not going to work
<ysionneau>
ah right
<ysionneau>
ok
<ysionneau>
I will put the clock entirely in a comb statement then ok
<sb0>
the metastability stuff is only in case the flash has a very long clock-to-output delay. which is very unlikely... you could even ignore.
<ysionneau>
sb0: ok now the sw goes into infinite loop saying "sr == ff"
<ysionneau>
so tristate then
<sb0>
also, you should use CSRStatus, for consistency with other cores
<ysionneau>
ok
<_florent_>
for bitbang_width, I'm not sure you have to take care spi_width since I think you are using the slow 1 mosi/ 1 miso mode
<_florent_>
so it can be bitbang_width = 5 and you just have to set the others dq lines to 1 in bitbang mode
<sb0>
CSR is only used for special features, e.g. trigger some action when written to
<ysionneau>
_florent_: here I only have 2 dq lines : MISO and MOSI
<sb0>
yeah, 1-bit SPI is fine for writing
<sb0>
as I said it can be slow
<ysionneau>
so far that's what I'm doing, 1-bit spi writes
<ysionneau>
since all my commands anyway are only 1-bit
<ysionneau>
makes me think .. here dq.i are 2 bits, right?
xiangfu has quit [Ping timeout: 255 seconds]
<ysionneau>
it's not just the MISO
<ysionneau>
maybe I'm reading the wrong one
<_florent_>
but then with spi_width = 4, you then have to set the 3 others dq lines to 1 when you are writing--> it will be easier to do it directly in the gateware than in the software
<ysionneau>
12:48 < _florent_> so it can be bitbang_width = 5 and you just have to set the others dq lines to 1 in bitbang mode < ah yes
<ysionneau>
ok I think the issue was : 12:52 < ysionneau> maybe I'm reading the wrong one
<ysionneau>
now instead of having a 1 bit CSRStatus I made it a 2-bits one so that I read the whole dq.i
<ysionneau>
and now I read 0x6 (instead of 0x3)
<ysionneau>
so I guess dq.i == {MISO, MOSI}
<ysionneau>
(in verilog syntax)
<ysionneau>
I will just put self.miso.status.eq(dq.i[-1])
<ysionneau>
my logic analyzer cannot sample for as long as a sector erase but it works now :)
<ysionneau>
the do {} while(sr & SR_WIP) does run, and I can see the signals of the status redister read returning 0x3 each time
<ysionneau>
and eventually the page program which is done after the sector erase works, which means the erase was really finished when I issued it
<ysionneau>
I think the polling therefore works
<ysionneau>
let's try on a platform where spi_width=4
<_florent_>
if fact you will always have: dq0 = mosi, dq1 = miso, dq2=wp, dq3=hold
<_florent_>
so you can simply connect your CSRStorage to dq0, and dq1 to your CSRStatus, and when you are sending commands to the flash assign dq1..3 to 1.
<ysionneau>
roger that
<ysionneau>
hum I don't have any supported board with spi_width=4
<ysionneau>
I thought the M1 was like that but it's a parallel flash
<ysionneau>
I could buy a lx9 microboard
<_florent_>
the only difference is that you have to drive dq2 and dq3 while writing commands, so it it works for spi_width=2, don't worry for spi_width=4 :)
<ysionneau>
well, ok
elaforest has joined #m-labs
elaforest has quit [Ping timeout: 255 seconds]
elaforest has joined #m-labs
elaforest has quit [Changing host]
elaforest has joined #m-labs
<ysionneau>
sb0: you want a high level API like write_to_flash(u32 addr, const char *buff, u32 len) with no restrictions on len and addr ?
<ysionneau>
or you are fine with sector aligned only writes?
<ysionneau>
I can write by pages (256 bytes) but I can only erase by sectors (4 kB)
<sb0>
can you do byte writes?
<ysionneau>
I can write from 1 byte up to 256 in one "Page Program" command
<ysionneau>
in fine, it's not so hard to implement the high level api
<sb0>
one of the use cases will be rewriting small configuration values. for this, I ideally need to write a single byte anywhere
<ysionneau>
it's very easy to write a single byte at the start of a sector
<ysionneau>
it's a bit more messy to write a single byte in the middle of a page, in the middle of a sector
<ysionneau>
but it's almost implemented anyway
<ysionneau>
so let's finish it
<sb0>
we will need it
<ysionneau>
ok
<sb0>
rjo, your transport experiment plays back a longer and longer portion of the waveform? why?
<sb0>
u = self.data["u"][:stop] with stop increasing at each scan
<sb0>
rjo, also, I'd pass the in-use frames to pdq2.prepare(), since there isn't really a way to determine what they are automatically
<sb0>
rjo, we could clear the frame list in Transport.prepare before electrodes.open_frame, but there's a risk that this clear call gets forgotten and frames keep accumulating
<sb0>
if a frame is forgotten in pdq2.prepare, there will be a compilation error when a kernel tries to use it
<GitHub88>
[artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/CgVGhw
<GitHub88>
artiq/master 00a6de2 Robert Jordens: examples/transport.py: refine syntax
<GitHub88>
artiq/master 4943cce Robert Jordens: examples/transport.py: add pdq2 api suggestion
elaforest has quit [Remote host closed the connection]
_whitelogger_ has quit [Ping timeout: 260 seconds]
_whitelogger_ has joined #m-labs
mumptai has joined #m-labs
_whitelogger_ has joined #m-labs
_whitelogger__ has joined #m-labs
_florent_ has quit [Quit: Page closed]
rjo_ has joined #m-labs
rjo has quit [Ping timeout: 246 seconds]
siruf has quit [Ping timeout: 246 seconds]
siruf has joined #m-labs
wpwrak has quit [Ping timeout: 246 seconds]
wpwrak has joined #m-labs
bentley` has joined #m-labs
mumptai has quit [Quit: Verlassend]
_whitelogger__ has quit [Ping timeout: 260 seconds]