Pages: 1 2 [3] 4   Go Down
Author Topic: Bizzare SPI issue. 3 engineers stumped!  (Read 3768 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

One thing I do notice....

On the Arduino capture, mode 0, the data pin is going high to idle on the falling edge of the clock. This would result in a 1 at the end of the byte that isn't suppose to be there. Is there some config option to make the data pin idle low? This is the case on the NETMF target.
Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 152
Posts: 6190
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Look at the timing diagram by "clock polarity and phase" on the link below.
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Mode_Numbers

If you used mode 1 (CPOL=0, CPHA=1), the data would be valid on the capture (blue lines).
The same goes for mode 2 (CPOL=1, CPHA=0). The data would be valid on the capture (red lines).
Logged

Global Moderator
Melbourne, Australia
Offline Offline
Brattain Member
*****
Karma: 511
Posts: 19350
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

The photo was so blurry it was useless. And most of the wires being the same colour don't help.

Look, with the scope, if you see a certain set of signals going in from one processor in terms of timing, relationship to each other and so on, and it works with one board, then the exact same set must work with another. The DAC doesn't know what board it is connected to.

You need to identify what is different between what works, and what doesn't. Clock polarity, timing, relationships, gaps between bytes, whatever it is. There must be something.

Quote
On the Arduino capture, mode 0, the data pin is going high to idle on the falling edge of the clock. This would result in a 1 at the end of the byte that isn't suppose to be there. Is there some config option to make the data pin idle low? This is the case on the NETMF target.

Ah, there's a good thought. I noticed something similar when trying to do VGA timings. The data line does indeed tend (or always) idle high. I don't think you can change that.

You can "bit bang" the SPI, something I normally try not to do. However I had to do it in another project where I needed two SPI (and also async serial). Here is the code I used:


Code:
// bit banged SPI pins
const byte MSPIM_SCK = 4;  // port D bit 4
const byte MSPIM_SS  = 5;  // port D bit 5
const byte BB_MISO   = 6;  // port D bit 6
const byte BB_MOSI   = 7;  // port D bit 7

// for fast port access (Atmega328)
#define BB_MISO_PORT PIND
#define BB_MOSI_PORT PORTD
#define BB_SCK_PORT PORTD
const byte BB_SCK_BIT = 4;
const byte BB_MISO_BIT = 6;
const byte BB_MOSI_BIT = 7;

// control speed
const byte BB_DELAY_MICROSECONDS = 4;

...

// Bit Banged SPI transfer
byte BB_SPITransfer (byte c)
{       
  byte bit;
   
  for (bit = 0; bit < 8; bit++)
    {
    // write MOSI on falling edge of previous clock
    if (c & 0x80)
        BB_MOSI_PORT |= _BV (BB_MOSI_BIT);
    else
        BB_MOSI_PORT &= ~_BV (BB_MOSI_BIT);
    c <<= 1;
 
    // read MISO
    c |= (BB_MISO_PORT & _BV (BB_MISO_BIT)) != 0;
 
   // clock high
    BB_SCK_PORT |= _BV (BB_SCK_BIT);
 
    // delay between rise and fall of clock
    delayMicroseconds (BB_DELAY_MICROSECONDS);
 
    // clock low
    BB_SCK_PORT &= ~_BV (BB_SCK_BIT);
    }
   
  return c;
  }  // end of BB_SPITransfer

In your case you might want to set the data bit back to off just before the "return" to make sure it idles low.

Of course, you also need to manually set up the pin modes for all lines (data, clock, ss) and set up your default state for them as you want it to be. eg.

Code:
 
  pinMode (MSPIM_SS, OUTPUT);
  digitalWrite (MSPIM_SCK, LOW);
  pinMode (MSPIM_SCK, OUTPUT);
  pinMode (BB_MOSI, OUTPUT);

Note the pins in this example are different from the normal SPI ones (see the comments).
Logged

http://www.gammon.com.au/electronics

Please post technical questions on the forum - not to me by personal message. Thanks a lot.

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

An update...

I got ahold of a Salae Logic analyzer and double checked my data. I even left another engineer totally oblivious to the issue to interpolate what I was doing to the DAC from only the transmitted data. Sure enough, he decoded it exactly correctly. It's not an issue of my packet or the wiring, it's got to be something in the configuration of the port, but I have tried all the SPI modes without success. Hmm... 
Logged

Global Moderator
Melbourne, Australia
Offline Offline
Brattain Member
*****
Karma: 511
Posts: 19350
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

The output is exactly correct, but you want to change the configuration? Why?
Logged

http://www.gammon.com.au/electronics

Please post technical questions on the forum - not to me by personal message. Thanks a lot.

Global Moderator
Melbourne, Australia
Offline Offline
Brattain Member
*****
Karma: 511
Posts: 19350
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Tell you what, use the logic analyzer to capture the output from the other board, the one that works. Then capture the one that doesn't work. Try to get the mode so it is as close as possible to what it should be. Post both pictures.
Logged

http://www.gammon.com.au/electronics

Please post technical questions on the forum - not to me by personal message. Thanks a lot.

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm having this done right now. I have to get my friend with the logic analyzer testing the NETMF board.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Go figure. My scope did an FW update and now it can do logic!!
http://files.chrisseto.com/THe

Now for the fun part, "sample clock on..." is set ti rising edge. It doesn't work properly on falling edge. This is totally backwards to the datasheet, I think.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Sorry for the triple post, yet another shot.

NETMF:
http://files.chrisseto.com/NIo

So, now I am going to take the scope, and without changing any settings, I am going to transfer it to the Arduino and see under what conditions I can match this data.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quad post!

Arduino:
http://files.chrisseto.com/JA8
Logged

Global Moderator
Melbourne, Australia
Offline Offline
Brattain Member
*****
Karma: 511
Posts: 19350
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I am hoping for quality shots, along these lines:



Data, clock, slave select lines all nicely brought out. Plus timings.

Near enough may not be good enough in this case.
Logged

http://www.gammon.com.au/electronics

Please post technical questions on the forum - not to me by personal message. Thanks a lot.

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 152
Posts: 6190
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The phase is incorrect on the Arduino capture.
edit: Actually, according to the timing diagram for the DAC, the NETMF phase is incorrect.

The NETMF is changing the data line on the falling edge for capture on the rising edge. (mode 0)
The Arduino is changing the data line on the rising edge for capture on the falling edge. (mode 1)

The voltage levels are different also as mentioned in a previous post. (3.3v on the NETMF and 5v on the Arduino).

add: What is the data line pulse you marked as "led" on the Arduino capture?
« Last Edit: June 16, 2012, 06:09:50 am by SurferTim » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Tim,

I noticed that too, neither capture looks right, but the NETMF one does work. Putting the Arduino into Mode 1 doesn't make it work, though.

The pulse I saw was what I thought was the board LED (on pin 13) I realized after I posted that image that if it was the board LED blinking for some reason, it'd be on clock, not data.
Logged

Global Moderator
Melbourne, Australia
Offline Offline
Brattain Member
*****
Karma: 511
Posts: 19350
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I got ahold of a Salae Logic analyzer and double checked my data.

Well? We are waiting for you to post it.

And as for the "LED" blink, perhaps you can investigate that.
Logged

http://www.gammon.com.au/electronics

Please post technical questions on the forum - not to me by personal message. Thanks a lot.

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm having a friend post the data. I did see that the data coming out the SPI port was correct in that the binary representation was correct. It won't be until Monday when everyone gets back to the office when I get the data... This is a school research project, I work on it at home a few hundred miles away and then drive down every few weeks for research meetings. I was there for a few days a few days ago, so that's when I got the data.
Logged

Pages: 1 2 [3] 4   Go Up
Jump to: