spi always recived the same data I send out.

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

I wrote some simple SPI slave code a while back that has worked fine for some time. I use an atmega32u4 and have it wired to a harness. This Harness connects to a master SPI device. I had to remake my harness as I lost the old one. Now the pair will not communicate.  So logically, I broke out my analyzer to have a look. I have attached a screen shot showing this.

 

The code I run matches what we see here..

	command=Spi_read(1, 0xff);
	Spi_read(1, 0x41);
	Spi_read(1, 0x5a);
	Spi_read(1, 0xF1);
	Spi_read(0, 0xF2);

 

Here is the SPI function for reference.


unsigned char Spi_read(char ack, unsigned char data)
{
    SPDR = data;
    while(!(SPSR & (1<<SPIF)))
    if (ack)
    {
        ATT_ON();
        _delay_us(1);
        ATT_OFF();
    }
    return SPDR;
}

 

When I debug out my command I get 0xff. If I put my command= on the next line

i.e.     command=Spi_read(1, 0x41);

I get 0x41 and same for the other 3 lines of code. Command should not be the data I'm sending. It should be the reply but it for some reason is showing the data sent to the mater.  I verified the SPI function is waiting for the communication to end. So the SPI function seems to be running successfully. I can see its sending the right data so the miso/mosi are not swapped and I have checked that harness many times over. From a practical sense it almost has to be the code, but it never changed. I reverted from my SNV....  What on earth would make it echo back what I send where the analyzer clearly shows that's not what comes back? IS there anything that would make the SPDR register not load the data from the temporary register?

 

 

 

 

 

 

 

 

 

 

Attachment(s): 

This topic has a solution.
Last Edited: Tue. Jan 5, 2021 - 12:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps I'm wrong about the returned data, it appears to always be 0xff. I was sure it was echoing the data sent in... Still confused, but possibly easier this to track down. This tells me the mcu pin is held high, so back to checking the harness again...

 

EDIT: once again harness looks good, I even forced the line low on mosi and its still getting 0xff. 

Last Edited: Tue. Jan 5, 2021 - 01:15 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Crap, break out board had a bad via. Never was connected to the MCU.

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

S_K_U_N_X wrote:
break out board had a bad via

If that's it, then please mark the solution - Tip #5 in my signature:

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...