Mega324A and SPI problem

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

What am I doing wrong, guys?

I have some SPI code lifted from Dharmani's micro-SD card (and hopefully modified correctly for the different port and control register names) which compiles without error but hangs waiting for completion of the first transmitted character through SPI.

The code appears identical to both the generic AVR SPI application note and that included in the 324A documents - however, the documents appear to be incorrect in that while the specification indicates two SPI units (possibly one of these is one of the UARTs) using the names suggested by those fails compilation: AVR studio 5 with the GCC compiler. To achieve compilation it is necessary to suffix '0' (zero) at the places one would expect if there were two SPIs, 0 and 1.

//SPI initialize for SD card
//clock rate: 125Khz
void spi_init(void)
{
	// first enable the thing via PRR0 - we want everything active, so
	PRR0 = 0x00;								// which is probably how it wakes up anyway!
	// ddrb = out in out in in in out in
	DDRB = 0xA2;								// ss is on PB1
	
	SPCR0 = (1 << SPE0) | (1 << MSTR0) | (1 << SPR10);
	SPSR0 = 0x00;
}

unsigned char SPI_transmit(unsigned char data)
{
	// Start transmission
	SPDR0 = data;

	// Wait for transmission complete
	while(!(SPSR0 & (1<<SPIF0)))
		usb_out ('.');
	data = SPDR0;

	return(data);
}

'usb_out' is a serial character transmit just to test... all I get is a permanent spin in this loop. I'm obviously doing something stupid but after looking at this all day I'm going blind - any offers?

Ta,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
   DDRB = 0xA2;                        // ss is on PB1

You have not got SS (PB4) as an output.
Which pin you use for /CS on your SDCard is up to you.

David.

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

Yeah, I followed PB1 per the original code. That's where it's wired... but either way it shouldn't stop it outputting the byte, no?

Wait... there's something about it dropping into slave mode if it sees a low on ~SS in input. Damn. Will investigate tomorrow, maybe later tonight (back in linux for a while at present!)

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

Yes, well (blush) it helps no end if you actually include the routine you're trying to debug...

It still doesn't work, but it no longer hangs waiting for the transmission to end. Now I need to slap a scope on it and see what's happening.

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

B4 (master /SS) needs to be an output to keep the microcontoller from going into slave mode.
If B1 will be used to control the LCD slave select,
B1 will need to be an output.
The tradition is to connect the master /SS (B4) to the slave (LCD) slave select.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

Yep, got that, thanks. I'm using Dharmani's code and diagrams; it turns out that the two are not strictly compatible!