MCP2515 sendet kein SO Signal an MISO (SPI)

[Ti Jay (Gast)]

Hallo Leute,

ich bin derzeit beschäftigt eine CAN-Schnittstelle aufzubauen und 
benötigt mehr als ein CAN-Controller. Ich habe 3 MCP2515 an einen AVR 
angeschlossen und spreche diese über SPI an. Das funktioniert auch 
soweit ganz gut, da es sich um zyklische abflogen handelt.

Ich arbeite wie viele, viele andere auch mit der Ansteruerungshilfe von 
kreatives-chaos.com und habe Erfolg mit dem versenden von CAN-Frames. 
Nun ist mir aber aufgefallen, dass der MCP2515 im SPI keine Daten 
zurücksendet, sprich MOSI läuft, MISO ist tot. Ich habe die Anschlüsse 
akribisch durchgemessen und von der Platine her ist alles einwandfrei. 
Die SPI Initialisierung habe ich sowohl selber geschrieben, als auch 
jedes Beispiel aus dem Internet ausprobiert, ohne Erfolg.

Hat jemand eine Idee warum der SO pin keine Daten sendet? Muss ich ein 
Bit in einem register setzen? Ich verzweifel hier regelrecht. Bitte 
helft mir.

Verwendeter AVR: AT90can128

[Lutz (Gast)]

Code?

[Ti Jay (Gast)]

Im wesentlichen ist es die SPI-Schnittstelle die Arger macht, deshalb 
beschränke ich mich mal auf diese Funktionen.

zusammen mit:

#define F_CPU 16000000

////////////////////////////////////////////////////////////////////////
// SPI config
#define PORTSPI PORTB
#define DDRSPI  DDRB

#define PINSCK  PB1
#define PINMOSI  PB2
#define PINMISO PB3

#define PORTCS  PORTB
#define DDRCS  DDRB

#define CAN0  PB0
#define CAN1  PB4
#define CAN2  PB5

////////////////////////////////////////////////////////////////////////
enum CANchannel
{
  Tester,
  ECU1,
  ECU2
};


Dazu sei vielleicht noch gesagt, die switch (CANchannel)- Funktion 
funktioniert tadellos.

Ich habe mittlerweile auch gelesen das jemand dieses wegen dem IC-Sockel 
hatte. Bei der Durchgangsprüfung war alles in Ordnung, könnte es dennoch 
so banal sein?

Ich bin für jeden Tipp und jede Anregung dankbar.

[holger (Gast)]

>Ich habe mittlerweile auch gelesen das jemand dieses wegen dem IC-Sockel
>hatte. Bei der Durchgangsprüfung war alles in Ordnung, könnte es dennoch
>so banal sein?

Alles klar, deine drei IC Sockel haben alle am gleichen Pin
ein Kontaktproblem. Das ist so wahrscheinlich wie jeden Tag
ein Sechser im Lotto.

[holger (Gast)]

>Hat jemand eine Idee warum der SO pin keine Daten sendet?

Zeig mal einen Schaltplan.

[holger (Gast)]

>MISO ist tot. Ich habe die Anschlüsse
>akribisch durchgemessen und von der Platine her ist alles einwandfrei.

Nur auf Verbindung von MISO zu den MCPs?
Check mal auf Kurzschluss zu GND oder VCC.

[Ti Jay (Gast)]

>Alles klar, deine drei IC Sockel haben alle am gleichen Pin
>ein Kontaktproblem. Das ist so wahrscheinlich wie jeden Tag
>ein Sechser im Lotto.

ja, das war auch mein Gedanke

>Nur auf Verbindung von MISO zu den MCPs?
>Check mal auf Kurzschluss zu GND oder VCC.

schon geschehen. ich hab auch den entsprechenden Pin herausgebogen um zu 
schauen, ob da überhaupt was kommt. Da ist nichts.

zum Pic:
ich Fahnen gehen alle direkt an den MCP keine Widerstände mehr und keine 
Pull-Ups oder Pull-Downs, die nicht eingezeichnet sind.

[Björn B. (elmo)]

Was für einen Takt legst Du denn an OSC1 an?

[Ti Jay (Gast)]

#define F_CPU 16000000

die gebe ich vom AVR an die MCP weiter...

[Ti Jay (Gast)]

Hat sonst keiner mehr eine Idee?

Ich habe mich gestern abend nochmal hingesetzt und die Kommunikation mit 
MCP2515 neu geschrieben. Hab alle Dateien des Programms angehängt.
wie gesagt, der AVR sendet über die SPI. Ich kann nur vermuten, dass der 
Fehler in der mcp2515.c liegt, wobei ich die Initalisierung diesmal 
komplett von kreatives-chaos.com übernommen habe.

Danke schonmal an alle, die bereits geschreiben haben.

[dummy (Gast)]

Ich sehe nicht eine einzige Read Instruction in deinem Programm.
Kein Wunder das an MISO nix kommt.
Mach doch mal ein read_status() in deine Mainloop.

[Ti Jay (Gast)]

>Ich sehe nicht eine einzige Read Instruction in deinem Programm.
>Kein Wunder das an MISO nix kommt.
>Mach doch mal ein read_status() in deine Mainloop.

ich kann den Gedanken nachvollziehen, aber das darf bei SPI nicht der 
fehler sein, oder???
wie dem auch sei, ich habs grade getestet und es hat noch immer keine 
Wirkung

 data = mcp2515_read(0x28);

uint8_t mcp2515_read(uint8_t address)
{
  cs_enable(CAN0);
  
  spi_transceive(SPI_READ);
  spi_transceive(address);
  
  uint8_t data = spi_transceive(0xaa); //Dummy Byte
  
  cs_disable(CAN0);
  return data;
}

[dummy (Gast)]

>ich kann den Gedanken nachvollziehen, aber das darf bei SPI nicht der
>fehler sein, oder???

Na dann schau noch mal ins Datenblatt wie oft
"High Impedance" bei SO steht.
Häng doch mal einen Pullup an SO.
Dann kannst du sehen wann der Ausgang aktiviert
oder deaktiviert wird.

[Ti Jay (Gast)]

ES LÄÄÄÄÄÄÄÄÄÄÄÄUFT !!!!!!!!!!!!!!!!!!!

An alle die sich beteiligt haben und mir ihr hilfe geboten haben: VIELEN 
VIELEN DANK.

Den Fehler hab ich nicht gefunden, ich nehme an, das es während der JTAG 
Übertragung zu fehlern kam.

@dummy: Trotzdem noch eine Frage: Der Pull-Up im AVR ist doch das gleich 
wie ein Pull-Up an der äußeren Leitung, oder? Denn der zusätzliche 
Pull-Up brachte auch keinen Erfolg.

Noch einmal TAUSEND DANK.

[Falk B. (falk)]

Man braucht keinen Pull-Up, der MCP hat einen normalen Push-Pull 
Ausgang.

[bropp (Gast)]

Ti Jay schrieb:
> Der Pull-Up im AVR ist doch das gleich
>
> wie ein Pull-Up an der äußeren Leitung, oder?

Nein. Hältst du den ATmega im Reset (nRST auf GND) sind alle Portpins 
auf Hi-Z, bis das Programm losläuft und sie initialisiert.
bropp