Hi Jonathan On Sat, May 8, 2021 at 4:45 AM Jonathan Lemon <jonathan.lemon@xxxxxxxxx> wrote: > > On 7 May 2021, at 17:46, Jonathan Lemon wrote: > > > On 7 May 2021, at 16:02, Ricardo Ribalda Delgado wrote: > > > >> Hi Jonathan > >> > >> Thanks for your patch. > >> > >> On Fri, May 7, 2021 at 11:53 PM Jonathan Lemon > >> <jonathan.lemon@xxxxxxxxx> wrote: > >>> > >>> Contrary to the comment in xilinx_spi_txrx_bufs(), the transmitter > >>> was not disabled on entry. On my particular board, when sending a > >>> PP > >>> sequence, the first address byte was clocked out 3 times, writing > >>> data > >>> into the wrong location, and generally locking up the chip. > >> > >> Sorry, what do you mean by PP sequence? > >> > >> By clocked out 3 times you mean that the sequence is sent like > >> B0........B1.........B2 > >> instead of: > >> B0B1B2 > > > > PP: Page program. When I’m trying to write to the flash, the > > sequence > > [opcode 02][A1 A2 A3][D1 D2 ..] is sent. The result is a flash write > > at location [A1 A1 A1] = [A2 A3 D1 D2 ...] > > > > In other words, the first byte of the address appears to have been > > sent to the chip 3x. > > > > > >> If your hardware supports IRQ. can you try forcing use_irq to true? > > > > Will try this in a bit. The hw does have an irq registered, but it > > it isn't always set, as it depends on how many how many bytes the > > spi_transfer sets. So sometimes it will set use_irq, and sometimes > > not. > > So I tried the following change: > > - if (xspi->irq >= 0 && remaining_words > xspi->buffer_size) { > + if (xspi->irq >= 0) { > > And that also allows writes to to through successfully. Perhaps > this is a simpler change that would work? It was just a test... we do not want to disable the non-irq mode, because for small operations it is much faster. I think this probes that it might be a timming issue. I would really like to see the output from your logic analyser/chipscope/ Thanks :) > -- > Jonathan