2009-05-28 17:53:18 SPI corrupting data
Ulisses Montenegro (BRAZIL)
Message: 74737
I am trying to adapt spi_bfin5xx.c to work in slave mode. I have decided to change the bare minimum: instead of adapting the SPI core to support slave controller drivers, spi_bfin5xx interfaces with the core as a master would, but internally handles the specifities of slave mode operation (clearing MSTR from the CTL register, etc, etc).
Then I built a simple app using spidev, wired two EZKIT boards together (one using the original spi_bfin5xx and the other using the modified slave-enabled one) and start experimenting. The application stays on a while(1) loop doing 8-bits-per-word full-duplex transfers (ioctl() with SPI_IOC_MESSAGE) where the tx and rx buffers have both 16 bytes. One side sends 'Testing A' and the other sends 'Testing B' and both print whatever they receive at each loop iteration. This is part of the output from the slave side:
Rx: Te9s:ting B
Rx:54 65 39 73 3a 74 69 6e 67 20 42 00 00 00 00 00
Rx: Te9sting B
Rx:54 65 39 73 74 69 6e 67 10 20 42 00 00 00 00 00
Rx: Testing B
Rx:54 65 73 74 69 6e 67 20 42 00 00 00 00 00 00 00
Rx: Testing B
Rx:54 65 73 74 69 6e 67 10 20 42 00 00 00 00 00 00 <--- Notice the 0x10 byte
About 60% of the transfers arrive with something wrong in them.
Now, for the master side:
Rx:
Rx:00 65 72 e8 6e 40 41 00 00 00 00 00 00 00 00 00 <--- Printing doesn't work because first byte is 0x00
Rx:
Rx:00 65 e6 e8 6e 20 41 00 00 00 00 00 00 00 00 00
Rx:
Rx:00 65 00 74 6e ce 20 00 00 00 00 00 00 00 00 00
Rx: Testing A
Rx:54 65 73 74 69 6e 67 20 41 00 00 00 00 00 00 00
I'd guess 80% of the transfers come with 0x00 as the first byte (and most have other deformities as well). My ideas as to the root cause of this error have run out. Can anyone help me?
Some relevant info:
1) The app on the slave side sleep for 2 secs between each iteraction, while the master sleeps for 3 seconds. It seems that when they were both set to sleep for 2 secs the master would arrive to bfin_spi_u8_duplex() a bit sooner, reading a round full of zeroes (the last word sent by the slave) before reading the real data (or the corrupted version of it).
2) The slave blocks on bfin_spi_u8_duplex() until the master raises the chip select - Good!
3) Current configuration on the slave side is:
chip->ctl_reg &= ~MSTR;
chip->ctl_reg |= EMISO;
chip->ctl_reg |= PSSE;
4) bfin_spi_u8_duplex() was modified to test for SPIF after testing for RXS
Both 3 and 4 were tested with many different variants.
Help?
QuoteReplyEditDelete
2009-05-28 18:21:12 Re: SPI corrupting data
Mike Frysinger (UNITED STATES)
Message: 74738
i dont think what you're doing is a good idea at all. the SPI framework is designed as a push framework -- it only does what drivers tell it to. it is certainly not designed to respond to interrupts which would occur from a SPI slave scenario.
it would probably be a lot saner to create a simple char device that registers the SPI slave interrupt and append the results to a local circular buffer. then userspace can consume that buffer.
QuoteReplyEditDelete
2009-05-29 09:25:13 Re: SPI corrupting data
Ulisses Montenegro (BRAZIL)
Message: 74764
The design of the solution surely isn't optimal, but I wonder if it makes any difference here, since the problems seems much more related to the device operation than to the flow of the code. That is, if I opted for the new char device solution, I'd still have to set the CTL register as above and offer read/write interfaces that have to be available independently from the device status.
Having that said, is there such thing as a 'SPI slave interrupt'? (Which I'm assuming to be different from the DMA irq)
QuoteReplyEditDelete
2009-05-29 09:32:45 Re: SPI corrupting data
Mike Frysinger (UNITED STATES)
Message: 74765
the issue might be unrelated to the device operation, but buffer management in the bus master assumes the buffers are given to it, not the other way around. it'll also be a lot easier to debug a simple char device that operates on a dedicated in kernel buffer than try to follow things through the SPI framework.
there is a SPI data interrupt for input data ready (TIMOD = 00) that our driver doesnt use currently
QuoteReplyEditDelete
2009-06-02 09:12:44 Re: SPI corrupting data
Ulisses Montenegro (BRAZIL)
Message: 75022
Any ideas on how I should proceed with that? The manual doesn't make much reference to this interrupt. I'll be guessing and experimenting in the next hours.
QuoteReplyEditDelete
2009-06-02 14:55:21 Re: SPI corrupting data
Mike Frysinger (UNITED STATES)
Message: 75037
the HRM has a page about the interrupt. it seems pretty clear to me. grab the IRQ, set TIMOD to 10, and wait to get an interrupt when the slave has data ready.