2009-05-28 17:53:18     SPI corrupting data

Document created by Aaronwu Employee on Aug 15, 2013
Version 1Show Document
  • View in full screen mode

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.

Attachments

    Outcomes