MAX31855 antwortet nicht

[DrGonzo (Gast)]

Hallo Leute,

ich möchte einen MAX31855 über SPI mit einem Atmega8 auslesen. Der 
Atmega sowie der MAX laufen auf 3,3V. Angeschlossen ist der MAX mit

CS an PB2(SS)
SO an PB4(MISO) über einen 1,2k Widerstand
SCK an PB5(SCK)  über einen 1,2k Widerstand

Der SPI wird auch zur Programmierung (ISP) genutzt, deswegen die 
Widerstände in der MISO und SCK Leitung. Der ISP Programmer (STK500) ist 
direkt verbunden.

Wenn ich CS auf LOW ziehe und der Atmega einen Takt an SCK erzeugt 
sollte der MAX ja eigentlich anworten, wozu er sich allerdings nicht 
überreden lässt. Mit dem DSO lässt sich auch keine Reaktion erkennen. 
Ist der MAX vllt. kaputt, wie lässt sich das testen?

Mein SPI Routinen:

void SPI_init(void)
{
  SPI_DDR |= (1 << SPI_MOSI) | (1 << SPI_SCK) | (1 << SPI_SS); // MOSI, SCK an SS as output
  SPI_DDR &= ~(1 << SPI_MISO); // MISO as input

  SPI_PORT |= (1 << SPI_SS); // deselect slave
  _delay_ms(220);

  SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << SPR1) | (1 << CPHA); // enable SPI, master, set clock rate fck/128  = 31,25kHz, clock phase
}

uint8_t SPI_recvByte(void)
{
  SPDR = 0;
  while(!(SPSR & (1 << SPIF))); // wait for reception complete 

  return(SPDR); // return data register
}

uint8_t SPI_getTemp(void)
{
  unsigned long value = 0;
  uint8_t temp = 0;
  uint8_t index = 0;
  uint8_t byte = 0;
  uint32_t buffer = 0;

  SPI_PORT &= ~(1 << SPI_SS); // select slave  
  _delay_ms(1);

  for(index = 3; index >= 0; index--)
  {
     byte = SPI_recvByte();  
     buffer |= (uint32_t)(byte << (8 * index));
  }

  SPI_PORT |= (1 << SPI_SS); // deselect slave

  value = (buffer >> 18);
  temp = (((value * 0.25) * 9) / 5) + 32;

  return(temp);
}

Wenn ich das Programm auf den µC schreibe führt er dieses vermutlich nur 
bis

while(!(SPSR & (1 << SPIF))); // wait for reception complete

aus, dann hängt er sich auf.

[DrGonzo (Gast)]

Hat keiner eine Idee?

[jo (Gast)]

Der 31855 spuckt eigentlich sofort wenn er nen CS und Clock-Signal 
bekommt Daten aus. Evtl. einfach mal mit Bit-Banging CS niedrig ziehen, 
32 Clock-signale rausschreiben und dabei MISO scopen.

[DrGonzo (Gast)]

Hmm, also könnte man davon ausgehen das der MAX defekt ist. Ich habe 
beim verbinden des STK500 mit dem Breadboard (auf dem ich die Schaltung 
aufgebaut habe) für kurze Zeit den VTARGET Jumper des STK500 gesteckt 
gehabt. Warscheinlich hat dann das STK500 (5V) die Schaltung (3,3V) 
kurzzeitig hochgezogen.  Was meinst du mit Bit-Banging?

[DrGonzo (Gast)]

Ich hab den MAX mal durch einen neuen ersetzt. Da zeigt sich allerdings 
das selbe Problem, er Antowortet einfach nicht. Das ich beide beim 
Einlöten zerstört habe, schließe ich einfach mal aus.

[DrGonzo (Gast)]

Hmm, ich hab den Sensor mal so wie du es beschrieben hast angesteuert, 
also Bit Banging methode. Da scheint er etwas rauszuwerfen.

[DrGonzo (Gast)]

Tatsächlich, wenn ich den MAX wie folgt ansteuere:

_delay_ms(220);
SPI_PORT |= (1 << SPI_SS);
_delay_ms(1);
SPI_PORT &= ~(1 << SPI_SS);

for(uint8_t index = 0; index < 32; index++)
{
  _delay_us(100);
  SPI_PORT |= (1 << SPI_SCK);
  _delay_us(100);
  SPI_PORT &= ~(1 << SPI_SCK);
}

SPI_PORT |= (1 << SPI_SS);

Bekomme ich von ihm eine Antwort, erkennbar auf dem Oszi.

Warum geht das nicht mit dem Hardware SPI des Atmegas?
Ist die Taktrate zu hoch? Eig. nicht grenze liegt bei 5MHz.

Wann wird den SPIF gesetzt, im Datenblatt steht immer nur wenn die 
Übertragung beendet ist. Was heißt das explizit?

[DrGonzo (Gast)]

Keiner irgendwelche Tipps?

[jo (Gast)]

Am besten mal die CS/Clock Leitung am Oszi während des Bit-Bangings 
aufnehmen und dann mit dem HW-SPI output vergleichen. Evtl auch komplett 
ohne Slave... Die HW SPI vom Atmega ist zeitweise etwas zickig, da man 
durchaus z.B. bei der "Flanken-Triggerung" usw gern mal wo nen Config 
Bit falsch setzt.