spi mosi always make first bit hi.

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an spi interface set up on my stmega328 that works well for the most part.  In one case when using it with a device the first bit is held hi in every case.

 

 

 

So sending 0x01, 0x42 comes across as 0x01, 0xC2

 

This is my spi set up:  SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1)|(1<<SPR0)|(1<<DORD)|(1<<CPHA)|(1<<CPOL);//needed for psx, could try without (1<<SPR0)
   

implementation like so:

SPDR = podatek;
while(!(SPSR & (1<<SPIF)));
_delay_us(100);

 

I'm pretty sure its hardware related as the device is designed to communicate to a play station controller and does so for all but one I have. In this one case I get the above effect. I'm more curios in what would cause that? Maybe a week pullup? I added the schematic (this was for an atmega8 board) .

 

 

 

 

 

 

 

 

 

 

 

 

 

Attachment(s): 

Last Edited: Sun. Oct 8, 2017 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SPI, unlike TWI/I2C, is pulled hard high or hard low, on the MOSI and MISO pins. MISO in slave devices then goes float state when the device is not selected. On MOSI, there is no such thing as "soft pull-up". 

 

Thus, if this is happening on MOSI, it "must" be the master that is causing this to happen. What is different about the software in the failure cases vs the good ones?

 

Have you looked at the lines with a logic analyzer? THAT should show you what is really happening.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem was discovered form an analyzer. I think I miss-labeled my slave/master pins. Because the Miso in this case shows the sending data.  Ill attach a shot here.

 

The bottom row is what I'm sending 0x01,0x42,0x00,0x00,0x00

but shows as 0x01,0xc2,0x00,0x00,0x00 in the analyzer output.

 

So naming aside, the pin that shows 0x01,0xc2,0x00,0x00,0x00  is incorrect based on the software sending the byte.

 

What is different about the software in the failure cases vs the good ones?

 

Nothing, same software. The only thing that has changed is the slave device.

Attachment(s): 

Last Edited: Sun. Oct 8, 2017 - 11:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
The only thing that has changed is the slave device.

If you trying to simulate PS2 controller with AVR then you have to connect the SS.
.
MG

I don't know why I'm still doing this hobby

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Understood but it is connected, per my schematic. I do not have issue with most all the ps2 controllers I have available. The issue is just one of them and the issue is explained above. What I'm more so interested in, is what would cause the data sent from the master to change. I'm clearly sending 0x42 but the analyzer shows as a 0xC2. The device agrees with the analyzer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cut off the MISO and see what happen using analyzer. Both at master and slave side simultanously.
.
MG

I don't know why I'm still doing this hobby

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried a few experiments and it seem that strangely holding the MISO lo causes the MOSI to change. I didn't think that was possible? Also only the second  byte changes.

 

Normal :

0x01, 0xC2, 0x00, 0x00 MOSI

0xFF, 0x83, 0x6C, 0xFD MISO

 

holding lo:

0x01, 0x86, 0x00, 0x00 MOSI

0x00, 0x00, 0x00, 0x00 MISO

 

 

 

 

Last Edited: Sat. Oct 21, 2017 - 05:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at the cock line I see something like bouncing. At first I thought it was a ground issue with the analyzer but it's very consistent. Only happens on the second and 3rd byte.  At the fall it wais .12us then  rises for .32 us and falls again.  This is causing the analyzer protocol to give a faulty read and quite possibly the SPI interface as well. It is very odd that this only happens with this particular controller.

 

 

Last Edited: Sat. Oct 21, 2017 - 05:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using the right mode?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can lower my analyzer to 2 MS/s and the data is as is should be. So yes I do believe so. I also have disabled my interrupts during the send and read time.

 

    while(!(SPSR & (1<<SPIF)));
DISABLE_INT()
    _delay_us(100);
ENABLE_INT()    

 

but this apparently is not the issue.

Last Edited: Sat. Oct 21, 2017 - 06:00 AM