Probleme mit MCP25625

zum Code kann ich dir nicht helfen. Aber ich würde zw. 10kOhm und 
Resetpin noch einen 100nF Kerko gegen Masse reinmachen.

Hallo,

habe es nur kurz überflogen aber ich sehe nicht das Stby an dem Can Chip 
negiert ist, dh Du hast ihn mit Gnd
auf aus geklemmt.

Lg Sven

Ps ok vergiss es Du schriebst die Spi Kommunikation ist in Ordnung.

Pps: ich habe jetzt noch mal im DB gelesen,
ich verstehe das so, das das Spi Interface weiter läuft,
nur die Module Tx Rx werden abgeschaltet.
Das würde ja genau Dein Problem beschreiben.

Sven K. schrieb:
> Pps: ich habe jetzt noch mal im DB gelesen,
> ich verstehe das so, das das Spi Interface weiter läuft,
> nur die Module Tx Rx werden abgeschaltet.
> Das würde ja genau Dein Problem beschreiben.

Hallo Sven, danke fürs schauen.
Das stimmt auch, aber der STBY Pin ist active high. Wenn ich auf Masse 
ziehe, dann dürfte er ja nicht im Standby sein, oder?

Ich würde keinen LM317 als Spannungsversorgung nehmen, zumindest nicht 
so, dass er auf 1,25V regelt...

J. W. schrieb:
> Ich würde keinen LM317 als Spannungsversorgung nehmen, zumindest nicht
> so, dass er auf 1,25V regelt...

äähhm sorry, mein Fehler..Da ist ein LD1117 5V drinne

dunno.. schrieb:
> Die Werte die du per SPI in die Register schreibst, kannst du auch
> wieder rücklesen?

jepp

dunno.. schrieb:
> Grade noch gesehen, was macht der 120r in canh? Das soll nicht die
> Terminierung sein, oder...?

Doch, das ist die Terminierung. CANH und CANL gehen noch an JP2

dunno.. schrieb:
> Dann schau dir nochmal an, wie man CAN terminiert. die 120r werden nicht
> in reihe, sondern zwischen H und L geschalten.

Ist er doch auch! Mit gesetztem JP2 wird R3(120Ohm) parallel zu CANH und 
CANL geschaltet.

JP2 ist ein Jumper

In den jeweiligen error Registern sind bits gesetzt. Das konnte ich noch 
auslesen.
Der tx hat bit 7 und rx keins bei der ersten Platine.
Rx zeigt einen Überlauf des Empfang Buffers an und tx kein Fehler Bit 
bei der zweiten.
Das ist merkwürdig.

Was aber sicher ist, das ich hier mehrere Probleme habe.. Das 
offensichtlichste ist, das das Interrupt handling wohl nicht sauber 
funktioniert, anders kann ich mir den Überlauf des read Buffers nicht 
erklären.

Es wird eine schwierige Geburt...

Uli schrieb:
> Tut mir leid für die harsche Kritik
Dafür tue ich ja das Layout hier ins Forum..

Uli schrieb:
> Y-Abzweiger und Kreuzungen
> vermeiden.

Sollte ich da lieber 'T' Verbindungen nutzen, wo sich drei Leiterbahnen 
treffen?

Leider ließen sich kurze Leiterbahnen nicht vermeiden.

Das mit dem Quarz habe ich schon öfters gehört hier.. Was genau ist 
nicht ok?


Ich mache jetzt eh ein neues Layout mit einem SSOP28 anstelle dem 6x6 
QFN28 des MCP25626.
- Als Quarz werde ich jetzt mal ein 7x5mm nehmen.
- An den Reset PIN tue ich noch ein 47nF Kerko gegen Masse, oder wären 
100nF besser?

Gibt es noch weitere Verbesserugsvorschläge?

in den Atmel Application Notes habe ich schon 10nF und 47nF gesehen. Ich 
benutze immer 100nF da ich eigentlich nur solche Kerkos für alle µC's 
und IC's nehme.

Thomas O. schrieb:
> in den Atmel Application Notes habe ich schon 10nF und 47nF gesehen. Ich
> benutze immer 100nF da ich eigentlich nur solche Kerkos für alle µC's
> und IC's nehme.

Ok, eigentlich spielt es keine Rolle, ob 10, 47 oder 100nF Kerko, nur 
dürfte er nicht zu groß sein..Von den 100nF Kerkos habe ich auch 
reichlich da.
Zur Sicherheit werde ich noch eine Diode gegen VCC schalten 
(antiparallel), um bei einem Abfall des VCC (abschalten) den Kerko 
schneller entladen zu können.

und vor den Kerko zw. VCC und GND kannst du nen kleinen 10µF Elko rein 
machen falls deine Stromversorgung über deine Platine nicht so stark 
dimensioniert ist

ok, das layout ist nicht ganz optimal und wird optimiert, aber ich denke 
nicht, das das der eigentliche Grund ist, warum die CAN Kommunikation 
nicht funktioniert. Zumal ja die SPI Kommunikation läuft.

Aber dein CAN Problem beschreibst Du nicht wirklich, oder übersehe ich 
etwas?

Hast Du JP2 geschlossen?
Da Du die Register zurücklesen kannst:
Initialisiere den CAN und gehe Buson.
Lies den Status zurück, ob er wirklich Active gegangen ist.

Weise eine Nachricht zum Senden an.
Lass die Interrupte erstmal aus.
Kurz warten, nicht dass Du einem Passive oder Busoff zuvorkommst.
Status relevante Register auslesen.

Ohne Gegenstelle müßte der CAN ständig senden und Error Passive melden.

Was siehst Du?

Steffen Rose schrieb:
> Aber dein CAN Problem beschreibst Du nicht wirklich, oder übersehe ich
> etwas?

Weiter oben hatte ich die Register Einträge gepostet

>
> Hast Du JP2 geschlossen?
Ja

> Da Du die Register zurücklesen kannst:
> Initialisiere den CAN und gehe Buson.
> Lies den Status zurück, ob er wirklich Active gegangen ist.
done
>
> Weise eine Nachricht zum Senden an.
done
> Lass die Interrupte erstmal aus.
Das ist fest verankert in der LIB. Daher habe ich keinen großen Einfluss 
darauf.
> Kurz warten, nicht dass Du einem Passive oder Busoff zuvorkommst.
> Status relevante Register auslesen.
done
>
> Ohne Gegenstelle müßte der CAN ständig senden und Error Passive melden.
>
> Was siehst Du?
Der tx hat bit 7 und rx keins bei der ersten Platine.
Rx zeigt einen Überlauf des Empfang Buffers an und tx kein Fehler Bit
bei der zweiten.


Für eine bessere Analyse, was auf dem MCP25625 passiert, muss ich ihn 
mal direkt und ohne die LIB ansprechen.

dunno.. schrieb:
> Bülent C. schrieb:
>> Das mit dem Quarz habe ich schon öfters gehört hier.. Was genau ist
>> nicht ok?
>
> Nachdem ich hier den Lothar schon erwähnt hatte:
> http://www.lothar-miller.de/s9y/categories/33-Quarz
>
> lothar miller + quartzlayout bringt von google auch nen haufen treffer
> hier. ziemlich spannend zu lesen, wenns interessiert. ;)

Das sieht sehr gut aus. Danke für den Hinweis.

Bülent C. schrieb:
> Steffen Rose schrieb:
>> Aber dein CAN Problem beschreibst Du nicht wirklich, oder übersehe ich
>> etwas?
>
> Weiter oben hatte ich die Register Einträge gepostet

Das war mir durch die Lappen gegangen, da du nicht direkt die 
Registerwerte gepostet hast.


>>
>> Hast Du JP2 geschlossen?
> Ja
>
>> Da Du die Register zurücklesen kannst:
>> Initialisiere den CAN und gehe Buson.
>> Lies den Status zurück, ob er wirklich Active gegangen ist.
> done
>>
>> Weise eine Nachricht zum Senden an.
> done
>> Lass die Interrupte erstmal aus.
> Das ist fest verankert in der LIB. Daher habe ich keinen großen Einfluss
> darauf.

Du kannst nicht einmal den globalen Interrupt sperren/gesperrt lassen?
OK, solange dies nicht dein eigentliches Problem ist. Du hattest nur 
selbst die Vermutung geäußert.

>> Kurz warten, nicht dass Du einem Passive oder Busoff zuvorkommst.
>> Status relevante Register auslesen.
> done
>>
>> Ohne Gegenstelle müßte der CAN ständig senden und Error Passive melden.
>>
>> Was siehst Du?
> Der tx hat bit 7 und rx keins bei der ersten Platine.
> Rx zeigt einen Überlauf des Empfang Buffers an und tx kein Fehler Bit
> bei der zweiten.

Wieder erwähnst Du nicht die Register oder SPI Kommandos, auf die Du 
dich beziehst.

EFLG
CANSTAT

RX und TX sind die Bezeichner für zwei Platinen?

Wenn RX überläuft:
Was meinen die Register:
CANINTE
CANINTF
auf diesem System?

Häufiges Problem: Der Interrupt wird in der CPU häufig per 
Flankenwechsel ausgelöst. Mit dieser Einstellung kann man schnell auch 
mal einen Interrupt verpassen. In diesem Fall wäre ein Level Interrupt 
besser.
Doch das könntest Du auch schnell auf der Platine nachmessen - ob die 
Interruptleitung dauerhaft aktiv ist.

Mal was anderes: Was willst Du mit T1 und T2 bezwecken? High Side Switch 
und Low Side Switch? Low Side ginge ja noch, High Side (mit dem PNP) 
definitiv nicht, der Transistor wird immer durchgeschaltet sein.

fchk

Hallo,

anbei das überarbeitete Layout.
Ist das so besser?


VG,
Bülent

Steffen Rose schrieb:
> Wieder erwähnst Du nicht die Register oder SPI Kommandos, auf die Du
> dich beziehst.

Wie schon oben geschrieben, ich muss mal auf den MCP25625 direkt per SPI 
zugreifen. Das mache ich noch.

Layout Feedbacks bitte unter 
Beitrag "MCP25625 Platine Feedback"

Anbei ein alternativer Schaltungsvorschlag, den ich eben mal so in einer 
Stunde gemacht habe. Denke mal darüber nach...

Deine beiden Transistorausgänge habe ich erstmal weggelassen, weil mir 
unklar ist, wofür die sind, und außerdem wird das ohnehin nicht so 
gehen, wie Du es da im Schaltplan hast.

fchk

Frank K. schrieb:
> Anbei ein alternativer Schaltungsvorschlag, den ich eben mal so in einer
> Stunde gemacht habe. Denke mal darüber nach...

Ich nutze aber keinen PIC...Aber worüber genau soll ich nachdenken?

Bülent C. schrieb:
> Die SPI Kommunikation zwischen dem Atmega168 und dem MCP25625
> funktioniert.
Und was funktioniert nicht?
Wie stellst du das fest?
Hast du ein Oszilloskop?

Lothar Miller schrieb:
> Und was funktioniert nicht?
Mit CAN1 schicke ich eine Nachricht an CAN2, der empfängt diese, 
inkrementiert die ID und schickt sie zurück an CAN1, der wiederum tut 
das gleiche....CAN1 kann die Message nicht schicken, bzw CAN2 erhält 
diese nicht. Das weiß ich im Moment garnicht.
> Wie stellst du das fest?
Debug ausgabe am LCD bzw. UART. Register der MCP25625 auf den jeweiligen 
Platinen kann ich lesen und beschreiben. Daher gehe ich mal davon aus, 
das die SPI Kommunikation funktioniert.
> Hast du ein Oszilloskop?
Noch nicht. Aber ein Analyzer ist schon auf dem Weg. Oszi folgt.

Bülent C. schrieb:
>> Hast du ein Oszilloskop?
> Noch nicht. Aber ein Analyzer ist schon auf dem Weg. Oszi folgt.
Gut. Denn wenn du nicht mal weißt, ob überhaupt was aus die Leitung 
rausgeht, bzw. wie das aussieht, ist es wie Stochern in der Suppe: mit 
ein wenig Glück findest du einen Brocken Fleisch...

Lothar Miller schrieb:
> Gut. Denn wenn du nicht mal weißt, ob überhaupt was aus die Leitung
> rausgeht, bzw. wie das aussieht, ist es wie Stochern in der Suppe: mit
> ein wenig Glück findest du einen Brocken Fleisch...

Eben..Deswegen habe ich auch in der zwischenzeit das Layout optimiert, 
um eventuelle harwarebedingte Fehler auszumerzen. Auch benutze ich kein 
6x6 QFN28 mehr, wo ich die Befürchtung habe, das ich es evtl. nicht 
richtig verlöten konnte. Die Paste hatte ich zwar sauber auf die 
einzelnen Pads angebracht, aber 100%'ig bin ich mir nicht sicher ob da 
Kontakt ist.

Bülent C. schrieb:
> Frank K. schrieb:
>> Anbei ein alternativer Schaltungsvorschlag, den ich eben mal so in einer
>> Stunde gemacht habe. Denke mal darüber nach...

> Ich nutze aber keinen PIC...
Ich weiß wohl, dass Dein Horizont begrenzt ist.

> Aber worüber genau soll ich nachdenken?
genau darüber. Siehe Teil 1 Deiner Antwort.

Du siehst ja, dass mein Vorschlag einfacher ist, weniger Bauteile 
braucht, billiger ist, und obendrein schneller ist, weil kein SPI 
dazwischen ist und der ECAN im PIC eine Weiterentwicklung des MCP2515 
ist und mehr Buffer und andere kleine Verbeserungen und Bugfixes hat.

Ich kann Dir den Weg zeigen, gehen musst Du ihn selber.

fchk

PS: Es gäbe noch den LPC11C14, bei dem auch der Transceiver intern ist 
(zwei Dies in einem Package). Ich habe aber immer gerne den Transceiver 
extern, weil das immer das erste ist, was kaputt geht, und ein SO08 ist 
einfacher getauscht als ein QFN32 mit Exposed Pad. Außerdem brauchts 
manchmal andere Transceiver, zB für SIngle Wire Can, FT CAN, Low Speed 
Busse etc.

Frank K. schrieb:
> Bülent C. schrieb:
>> Frank K. schrieb:
>>> Anbei ein alternativer Schaltungsvorschlag, den ich eben mal so in einer
>>> Stunde gemacht habe. Denke mal darüber nach...
>
>> Ich nutze aber keinen PIC...
> Ich weiß wohl, dass Dein Horizont begrenzt ist.
Was soll denn dieser Unsinn???? gehts noch?
>
>> Aber worüber genau soll ich nachdenken?
> genau darüber. Siehe Teil 1 Deiner Antwort.
Siehe meine Antwort oben!

>
> Du siehst ja, dass mein Vorschlag einfacher ist, weniger Bauteile
> braucht, billiger ist, und obendrein schneller ist, weil kein SPI
> dazwischen ist und der ECAN im PIC eine Weiterentwicklung des MCP2515
> ist und mehr Buffer und andere kleine Verbeserungen und Bugfixes hat.
>
Biller ist es ganz gewiss nicht, eher teurer als die Kombi ATMega168 und 
MCP25625..40 Cent sogar!! Ok, SPI ist ein Flaschenhals...aber für die 
vorliegende Anforderung reicht es allemal.


> Ich kann Dir den Weg zeigen, gehen musst Du ihn selber.
Danke, aber den von Dir vorgeschlagenen Weg kann ich nicht gehen!
Wie kannst Du denn eigentlich einen Vorschlag machen, wenn Du nicht mal 
die Anforderungen kennst?!?!

>
> fchk
>
> PS: Es gäbe noch den LPC11C14, bei dem auch der Transceiver intern ist
> (zwei Dies in einem Package). Ich habe aber immer gerne den Transceiver
> extern, weil das immer das erste ist, was kaputt geht, und ein SO08 ist
> einfacher getauscht als ein QFN32 mit Exposed Pad. Außerdem brauchts
> manchmal andere Transceiver, zB für SIngle Wire Can, FT CAN, Low Speed
> Busse etc.

Der LPC11C14 nicht, sondern der LPC11C22 und LPC11C24 haben den 
Transceiver inne.

Frank K. schrieb:
> Du siehst ja, dass mein Vorschlag einfacher ist, weniger Bauteile
> braucht, billiger ist, und obendrein schneller ist, weil kein SPI
> dazwischen ist und der ECAN im PIC eine Weiterentwicklung des MCP2515
> ist und mehr Buffer und andere kleine Verbeserungen und Bugfixes hat.

....oder willst Du hier eine PIC vs. AVR Diskussion anzetteln...so ala :
Beitrag "Re: AVR gegen den Rest der Welt"

war ja nur ein Vorschlag

Frank K. schrieb:
> war ja nur ein Vorschlag
Ja, danke dafür, aber ich habe die Vorgabe so günstig und einfach wie 
möglich. Auch wenn es mit einem Pic günstiger wäre müsste ich mich in 
pic einarbeiten und das geht aus zeitlichen Gründen nicht.

Woher weißt Du, ob die SPI Kommunikation funktioniert, wenn Du nicht 
einmal die Fehlerregister auslesen kannst?

Steffen Rose schrieb:
> Woher weißt Du, ob die SPI Kommunikation funktioniert, wenn Du nicht
> einmal die Fehlerregister auslesen kannst?

Wo habe ich denn sowas geschrieben???
Sagtmal, ließt Ihr mal richtig die Beiträge?
Die Lib die ich nutze hat Funktionen, die über SPI die Register auslesen 
und den Inhalt zurückgeben. Diese Funktionen haben mir Werte 
zurückgegeben, und auch mal keine, wenn ich den CS untebrochen hatte 
(hatte mir auch eine Breakout Platine für den MCP25625 gebaut)...ergo 
funktioniert die SPI Kommunikation.
Das einizge was ich noch nicht gemacht habe ist, das ich "noch" nicht 
selbst direkt auf die Register zugegriffen habe.

Du schriebst, dass die Lib die Zugriffe durchführt und suggerierst mit 
deiner Aussage

> Wie schon oben geschrieben, ich muss mal auf den MCP25625 direkt per SPI
> zugreifen. Das mache ich noch.

dass es dir bisher nicht möglich ist, aus deiner Applikation heraus auf 
die Register zuzugreifen.

Wo also schreibst Du, dass Du weißt, dass die Daten auch richtig vom MCP 
interpretiert wurden? Dafür wäre ein Rücklesen notwendig.

Um deine Aussagen als sicher oder unsicher einzustufen, wäre es auch 
wichtig zu wissen, wie du zu deiner Erkenntnis gekommen bist.
(z.B. beschreibst du deinen SPI Test erst in deiner letzten Aussage)


> char Buffer[1];
> itoa(error,Buffer,10);

Müßte der Buffer nicht 4 Zeichen groß sein? (0..255 und '\0').
Ich wäre mir unsicher, welches Bit im error register nun eigentlich 
wirklich gesetzt ist. Und dein Stack dürfte auch durcheinander sein(?).

> In den jeweiligen error Registern sind bits gesetzt. Das konnte ich noch
> auslesen.
> Der tx hat bit 7 und rx keins bei der ersten Platine.
> Rx zeigt einen Überlauf des Empfang Buffers an und tx kein Fehler Bit
> bei der zweiten.
> Das ist merkwürdig.

> error = can_read_error_register().tx
Das EFLG Register gibt es nicht getrennt nach TX und RX.
Insofern erscheint mir deine Interpretation fehlerhaft.

1

can_error_register_t mcp2515_read_error_register(void)

2

{

3

  can_error_register_t error;

4

5

  error.tx = mcp2515_read_register(TEC);

6

  error.rx = mcp2515_read_register(REC);

7

8

  return error;

9

}

Dein Sender ist im Error Passive oder möglicherweise im Busoff. Der 
Counter läuft dann nicht weiter.

Ja ok..evtl. etwas unglücklich formuliert.

1

if (can_init(BITRATE_125_KBPS))

2

    lcd_printlcc(2,1,"CAN geht");

3

4

  else

5

    lcd_printlcc(2,1,"CAN geht net");

Der Aufruf der can_init bekommt ein bool aus dieser Funktion hier 
zurück:

1

#if ((BUILD_FOR_MCP2515 + BUILD_FOR_AT90CAN + BUILD_FOR_SJA1000) <= 1)

2

  #if (BUILD_FOR_MCP2515 == 1)

3

4

    #define mcp2515_init(...)          can_init(__VA_ARGS__)

1

bool mcp2515_init(uint8_t bitrate)

2

{

3

  if (bitrate >= 8)

4

    return false;

5

6

  SET(MCP2515_CS);

7

  SET_OUTPUT(MCP2515_CS);

8

9

  // Aktivieren der Pins fuer das SPI Interface

10

  RESET(P_SCK);

11

  RESET(P_MOSI);

12

  RESET(P_MISO);

13

14

  SET_OUTPUT(P_SCK);

15

  SET_OUTPUT(P_MOSI);

16

  SET_INPUT(P_MISO);

17

18

  // SPI Einstellung setzen

19

  mcp2515_spi_init();

20

21

  // MCP2515 per Software Reset zuruecksetzten,

22

  // danach ist er automatisch im Konfigurations Modus

23

  RESET(MCP2515_CS);

24

  spi_putc(SPI_RESET);

25

26

  _delay_ms(1);

27

28

  SET(MCP2515_CS);

29

30

  // ein bisschen warten bis der MCP2515 sich neu gestartet hat

31

  _delay_ms(10);

32

33

  // CNF1..3 Register laden (Bittiming)

34

  RESET(MCP2515_CS);

35

  spi_putc(SPI_WRITE);

36

  spi_putc(CNF3);

37

  for (uint8_t i=0; i<3 ;i++ ) {

38

    spi_putc(pgm_read_byte(&_mcp2515_cnf[bitrate][i]));

39

  }

40

  // aktivieren/deaktivieren der Interrupts

41

  spi_putc(MCP2515_INTERRUPTS);

42

  SET(MCP2515_CS);

43

44

  // TXnRTS Bits als Inputs schalten

45

  mcp2515_write_register(TXRTSCTRL, 0);

46

47

  #if defined(MCP2515_INT)

48

    SET_INPUT(MCP2515_INT);

49

    SET(MCP2515_INT);

50

  #endif

51

52

  #ifdef RXnBF_FUNKTION

53

    SET_INPUT(MCP2515_RX0BF);

54

    SET_INPUT(MCP2515_RX1BF);

55

56

    SET(MCP2515_RX0BF);

57

    SET(MCP2515_RX1BF);

58

59

    // Aktivieren der Pin-Funktionen fuer RX0BF und RX1BF

60

    mcp2515_write_register(BFPCTRL, (1<<B0BFE)|(1<<B1BFE)|(1<<B0BFM)|(1<<B1BFM));

61

  #else

62

    #ifdef MCP2515_TRANSCEIVER_SLEEP

63

      // activate the pin RX1BF as GPIO which is connected 

64

      // to RS of MCP2551 and set it to 0

65

      mcp2515_write_register(BFPCTRL, (1<<B1BFE));

66

    #else

67

      // Deaktivieren der Pins RXnBF Pins (High Impedance State)

68

      mcp2515_write_register(BFPCTRL, 0);

69

    #endif

70

  #endif

71

72

  // Testen ob das auf die beschreibenen Register zugegriffen werden kann

73

  // (=> ist der Chip ueberhaupt ansprechbar?)

74

  bool error = false;

75

  if (mcp2515_read_register(CNF2) != pgm_read_byte(&_mcp2515_cnf[bitrate][1])) {

76

    error = true;

77

  }

78

79

  // Device zurueck in den normalen Modus versetzten

80

  // und aktivieren/deaktivieren des Clkout-Pins

81

  mcp2515_write_register(CANCTRL, CLKOUT_PRESCALER_);

82

83

  if (error) {

84

    return false;

85

  }

86

  else

87

  {

88

    while ((mcp2515_read_register(CANSTAT) & 0xe0) != 0) {

89

      // warten bis der neue Modus uebernommen wurde

90

    }

91

92

    return true;

93

  }

94

}

Die SPI Funktionen werde ich jetzt nicht reintun.

Und wenn ich von dieser Funktion einen true bekomme, dann kann ich doch 
davon ausgehen, das die SPI Kommunikation funktioniert?!?!

1

if (mcp2515_read_register(CNF2) != pgm_read_byte(&_mcp2515_cnf[bitrate][1])) {

dürfte als SPI Test passen.

Die Reset-Behandlung finde ich etwas unglücklich. Aber wird schon 
passen.

Nun sollte aber auch deinerseits Zugriffe der Art:
mcp2515_read_register(EFLG)
möglich sein.

Ich nehme an, dass dieses Passive anzeigt, was bedeutet, dass dein 
zweites Board nicht mithört oder der Abschlusswiderstand fehlt. (Ja, du 
schriebst, er ist aktiv.)

Senden beide Boards die gleichen Daten? Wenn es genau die gleichen Daten 
sind, ist es kein Problem. Wenn Du jedoch die gleiche CAN ID mit 
unterschiedlichen Datenbytes nutzt, weil du zum Testen variiert hast, 
geht dies schief.

Steffen Rose schrieb:
> if (mcp2515_read_register(CNF2) !=
> pgm_read_byte(&_mcp2515_cnf[bitrate][1])) {
>
> dürfte als SPI Test passen.
Eben :-)

>
> Die Reset-Behandlung finde ich etwas unglücklich. Aber wird schon
> passen.
Sehe ich genauso...
>
> Nun sollte aber auch deinerseits Zugriffe der Art:
> mcp2515_read_register(EFLG)
> möglich sein.
Ja, sollten Sie. Aber ich will die LIB komplett weglassen und mit 
eigenen Funktionen per SPI die Register auslesen...Das mache ich mit den 
neuen Platinen(Habe ja das Platinen Layout ein wenig optimiert) Wenn ich 
Morgen  wieder zuhause bin, dann ist der Logikanalyzer auch schon 
bestimmt da, und ich kann besser analysieren. nur so ist es derzeit nur 
ein rumgestochere.
>
> Ich nehme an, dass dieses Passive anzeigt, was bedeutet, dass dein
> zweites Board nicht mithört oder der Abschlusswiderstand fehlt. (Ja, du
> schriebst, er ist aktiv.)
>
> Senden beide Boards die gleichen Daten? Wenn es genau die gleichen Daten
> sind, ist es kein Problem. Wenn Du jedoch die gleiche CAN ID mit
> unterschiedlichen Datenbytes nutzt, weil du zum Testen variiert hast,
> geht dies schief.
Mit CAN1 schicke ich eine Nachricht an CAN2, der empfängt diese,
inkrementiert die ID und schickt sie zurück an CAN1, der wiederum tut
das gleiche....CAN1 kann die Message nicht schicken, bzw CAN2 erhält
diese nicht. Das weiß ich im Moment garnicht, und darin liegt mein 
Problem. CAN2 zeigt mir einen überlauf des Buffers an...Ich tippe hier 
darauf, das der Interrupt nicht ausgelöst wird... Wie gesagt, ich 
stochere gerade nur rum...Wenn der Analyser da ist, dann weiß ich mehr

Ich gehe davon aus, dass CAN1 und CAN2 zwei deiner Boards sind und dass 
Du entsprechend deiner Aussage das Programm modifiziert hast.

Desweiteren zur Erinnerung:
can_read_error_register().rx
ist der Error counter, nicht das EFLG. Den Buffer Overflow würdest Du 
aber im EFLG sehen. Diese Erkenntnis ist falsch, wenn du die angegebene 
Funktion genutzt hast.

Steffen Rose schrieb:
> Desweiteren zur Erinnerung:
> can_read_error_register().rx
> ist der Error counter, nicht das EFLG. Den Buffer Overflow würdest Du
> aber im EFLG sehen. Diese Erkenntnis ist falsch, wenn du die angegebene
> Funktion genutzt hast.

Stimmt! Ich hatte zwischendurch aber auch mal das EFLG gelesen.. Wie 
gesagt, anscheinend habe ich mich unglücklich ausgedrückt.
Danke für Deine Hilfe.

Wenn ich die neue Platine geätzt, gebohrt, durchnietet und bestückt 
habe, werde ich nochmal testen und hier die Ergebnise berichten.

So, nach langer Zeit konnte ich mich wieder an diese Platine setzen.
Folgende Angaben kann ich nun machen.
Im EFLG Fehlerregister ist kein bit gesetzt, alle stehen auf 0 (Auf 
beiden Boards)
Was mir aber merkwürdig vorkommt, ist das auf dem CANL Aktivität 
vorhanden ist, aber auf CANH nicht (steht permanent auf 1.

CAN-L sieht mir aber auch nicht so ganz richtig aus.

Miß erstmal nur ein Board statisch durch.

CAN-TX sollte auf High stehen (rezessiv).
Damit dann CAN-H und CAN-L rezessive sein.
Daraus folgt dann, dass an CAN-RX auch ein High anliegt.

Um den Transceiver zu testen lege ich als nächstes von außen per CAN 
Analyzer ein Signal an und prüfe CAN-RX.
(So kann mir keiner Einreden, meine Software hätte einen Fehler.)

Das ist doch zum Mäusemelken mit dem MCP25625, so langsam aber sicher 
fliegen die Platinen gleich aus dem Fenster.
Habe nochmal folgende Sachen überprüft:
- SPI funktioniert
- INT funktioniert
- Der MCP25625 ist sauber beschaltet. TX geht auch an TXCan und RX an 
RXCan
- Der Quarz schwingt
- Der Abschlußwiderstand ist auch richtig beschaltet
- VDD, VIO und VDDA werden sauber mit 5V versorgt (Abblockkerkos sind 
dran)
- Beide Platinen haben den selben Masse Bezugspunkt
- CANL an CANL, und CANH an CANH angeschloßen
- Im Fehlerregister sind keine Fehler vermerkt
- Reset ist mit einem PULL-UP hochgezogen


Ich bin mir ziemlich sicher, das ich etwas ziemlich offensichtliches 
übersehe.

Besorge Dir einen definitiv funktionierenden CAN-Knoten. Besser ist das. 
Ich habe mir für mein erstes CAN-Projekt das hier besorgt:

http://www.peak-system.com/PCAN-USB.199.0.html

Das sind zwar auch Kosten, aber Du musst zwischen Arbeitszeit und 
Entwicklungskosten abwägen, und in einer 4ma kostet Deine Arbeitszeit 
auch Geld.

fchk