Slowing down (single-stepping) SPI?

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

I am trying to use the SPI interface on an 8515 to talk to a TI TLC2543 ADC chip. Curiously, TI does not describe the ADC's interface as "SPI", but rather they just call it a three-wire interface. From the timing diagrams, however, it appears to conform fully to my understanding of the SPI protocol.

So it didn't work on the first try - probably because I got something wrong in the SPI control register set-up. Debugging it really isn't easy, though. The obvious solution would be a fast four-channel scope or logic analyzer to see what's actually on the SPI bus. Only problem is, I don't have the needed test equipment.

Is there some way to slow down the SPI interface (i.e. single-step the SPI clock) so that I could diagnose the problem using a logic probe or single-channel scope? I thought about manufacturing my own (slow) clock signal manually, but it seems that for SPI to work, one device or the other must be configured as master, and that device will then expect to generate the (full speed) serial clock signal.

Any suggestion on how to single-step the SCK output, or other general advice on how to debug an SPI interface without a logic analyzer would be much appreciated!

Thanks

Erik

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

Hmm, I don't know about Single-Stepping it, doubtful, but you could use some very slow crystal. You can time SPI at f/128, so I guess at something like 10kHz, you could get down to about 80Hz on the SPI, and even slower.

Granted, its going to be a pain to use, but according to the datasheet it should be possible (I stand to be corrected).

I use SPI on some custom hardware, but this code works for me (explanation of the configuration included):

int
spi_init(void)
{
unsigned int i;

cli();
/*
* Set SS to be general output pin. If it was configured as * input, it might be driven down, and then the SPI would go * into slave mode, for which we are not prepared.
*/

outp((inp(DDRB) & 0x0f) | 0xb0, DDRB);
outp(inp(DDRD) | 0x04, DDRD);

/* pin 2 on portD controls the master/slave on the "slave"
* side, so if I pull it low, the other chip will go to slave * mode.
*/
sbi(PORTD, 2);

/* Set the SPI Control Register to: enable, master, ck/16 */
outp(0x51, SPCR);

for(i=0;i<256;i++);

// set the other chip to slave by driving its SS down
cbi(PORTD, 2);

return 0;
}

int
spi_send(char c)
{
int i; /* delay counter */

/* check that we are in master mode, write data, wait for
completion, reset*/

// after spi_init, we should be in master mode, if not. flag an // error with a led
if(!(inp(SPCR) & 0x10)) {
LED_YELLOW_ON();
return -1;
}

/* write */
outp(c,SPDR);
/* for now, ignore collisions */
/* delay until tranmission is complete */
while(!(inp(SPSR) & 0x80));

// waits until End-of-transmission is set

/*
*
* Delay for 128 CK
* our slave polls data, so we need to delay a bit to let it * read the data register befor next write.
*/
for(i=0;i<128;i++);

return 0;
}

Hope this helps.

Cheers,
Marcin

admin's test signature
 

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

test

admin's test signature
 

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

Hi Erik,

you can easy make SPI as slow as you want. Also you can wait on a key to execute the next clock.

Solution:
Disable the SPI hardware and make it fully in software. Then you can insert unlimited delay loops or waiting for a key on every step.

Following an example originally used to control the AD7890.
Please watch, its written for the 8051. So the port pin definitions (MISO, ...) and its usage may be different on the AVR.

#pragma cd
#include

sbit MISO = P1^0;
sbit MOSI = P1^1;
sbit SCK = P1^2;

char spi_io( char d )
{
char i;
for( i = 8; i; i-- ){
SCK = 1;
MOSI = d & 0x80; // data out, MSB first
SCK = 0;
d += d;
if( MISO ) // data in
d++;
}
return d;
}

Peter

P.S.:
I'm still interest on comparison 8051 / AVR.
The routine above need 20 bytes on the 8051.
Please can anybody tell me the code consumption on the AVR and the generated assembler code ?

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

I do not have an ICE200, but have been thinking I need one. Does that device offer any sort of SPI debugging assistance?

I realize the opportunity to bit-bang the SPI interface in software then single-step the software on the ICE200. What I am asking is whether the ICE200 (or any other development tool/accessory) offers the ability to diagnose the hardware SPI interface without having to re-implement SPI in software.

On another related note: I have been trying to make this work on a breadboard, and I am wondering if that is the problem (i.e. non-soldered jumper wires not being adequate for the high frequency signals). I've been using a 4MHZ crystal on an 8515, and have the SPI clock set to fCLK/128, but that's still a 32khz SPI clock rate. Anyone out there tried using the hardware SPI with a breadboard jumpered SPI bus, and were there problems with it? (My symptoms are apparently-random result data, leading me to suspect a timing problem).

Thanks!

Erik

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

Hi,

The ICE200 will be ablel to monitor a SPI interface communication. I've attached an example file for a simple SPI master and slave interface. Sorry I didn't have time to review your code. The problem sounds to me like one of connections, but there are far better designer than me on this forum.

What do you think?

Best regards,

Morten, AVR tech. support, Atmel FAE

admin's test signature