RX65N CAN Bit/Stuff Errors

[Erik F. (mc_fresh)]

Guten Tag

Ich habe einen RX65N (R5F565NEDDFP) mit einem TJA1051T/3 
Transceiver(läuft mit 5 Volt, aber 3,3 Volt Eingangssignal) und so ein 
USB-CAN Reader (von sysWORXX). Der uC soll Zyklisch Nachrichten raus 
senden. Leider bekomme ich Stuff Errors und Rezessive Bit Errors (selten 
auch ACK). Der physische CAN-Bus funktioniert, da andere Nodes keine 
Errors aufweisen.

Zu den Fakten:
- Bus weist 60 Ohm Widerstand auf
- Baudrate ist 500kbit/s
- Zyklus von 100 Nachrichten/Sek wird im großen und ganzen eingehalten 
--> Fehler ist eher spontaner Natur
- Bit Timings habe ich schon oft angeguckt und kann selber keinen Fehler 
finden. Wenn Sie etwas finden wäre ich echt dankbar :)
fCAN: 60MHz
Prescaler: 8  --> f=7,5MHz -->15tq(für 500kbit) --> Samplepoint~=13 
(SS+TSEG1)
SS=1tq
TSEG1:12tq
TSEG2:2tq
SJW:2tq
Passt das?

Habe ich irgenwas übersehen? Wenn mir jemand Tipps geben kann woran es 
liegen könnte, würde ich mich sehr freuen.

Mit freundlichen Grüßen

Erik

[minifloat (Gast)]

Erik F. schrieb:
> Samplepoint~=13 (SS+TSEG1)
> SS=1tq
> TSEG1:12tq
> TSEG2:2tq
> SJW:2tq

Bei maximal negativ genutzter SJW würde deine Samplezeit auf das Bitende 
fallen. Denk noch mal drüber nach...

Normal nimmt man eine Samplezeit bei ca. 60%...75% der Bitzeit. Also 
grob 9tq...11tq

mfg mf

[Erik F. (mc_fresh)]

Hallo und danke für die schnelle Antwort.
Ich habe bezüglich des Sampling Points etwas von 87,5% gelesen, aber mit 
dem SJW hast du recht.

Ich habe jetzt alle möglichen Timings mit allen möglichen SJW von BRP 5 
bis 15 durchprobiert und leider kommt immer noch Rezessive Bit und Stuff 
Error. Könnte es sein, dass der Transciever die Spannung nicht stark 
genug ändert dass das die anderen registrieren? (die anderen Nodes haben 
einen PCA82C251 verbaut)
Ich bin mit meinem Latein bald am ende. Und da es sicherlich nicht am 
CAN Controller im uC liegt, sitzt das Problem wahrscheinlich vor dem uC.

Kann ein solcher Fehler überhaupt durch die Software passieren? Bis auf 
die Timings regelt der CAN Controller ja das senden und empfangen.

Mfg

Erik

[minifloat (Gast)]

Wie ist der V_io bei dem TJAxxx beschaltet?
Ist Ground der Knoten miteinander verbunden?
Überall schön Kabel verdrillt, keine sternförmige sondern lineare 
Verdrahtung mit 120Ω an den Enden?

Hast du ein Oszi, das CAN spricht, dekodieren kann und auf Stuff Errors 
triggern kann?
mfg mf

[minifloat (Gast)]

Erik F. schrieb:
> Kann ein solcher Fehler überhaupt durch die Software passieren

Nein, weil Software für Acknowledge und die Checksumme zu lahm wäre. 
Zumindest war das 1983 so, daher hat man das als deterministische 
Automaten in Hardware.

[Erik F. (mc_fresh)]

V_io ist auf 3,3 Volt geschalten und alles hängt an einer Masse.
Mein Testbus ist ca 50cm lang und an beiden enden sind 120Ohm 
Widerstände. eine Verdrillung ist mehr oder weniger vorhanden. Aber da 
andere Nodes auf dem Bus fehlerfrei funktionieren schließe ich das aus.

Ich werde in den nächsten Tage ein Oszi zur Hand haben, dann kann ich 
weitere Einblicke geben.

[Dave (Gast)]

Kannst du testweise den BUS auf 250k umstellen?

Das ist der Code der bei mir zuletzt auf 250k (60Mhz PCLKB) gelaufen 
ist, dann weißt du zumindest es liegt nur an deinen Teilern.
Nützt du das "Software component configuration" (FIT) vom e2Studio? Das 
ist bei neuen Chips meist ziemlich buggy, würde nochmal genau die 
Register überprüfen wenn die CPU läuft und das PortMux ob wohl alles so 
initialisert ist wie gewünscht.

#define CAN_BRP     (5)
#define CAN_TSEG1   (15)
#define CAN_TSEG2   (8)
#define CAN_SJW     (2) /* Re-synchronization Control (SJW) should be 1-4 Tq (must be <=TSEG2). */

void R_CAN_SetBitrate(const uint32_t ch_nr)
{
    volatile struct st_can R_BSP_EVENACCESS_SFR * can_block_p;

    if (ch_nr < MAX_CHANNELS)
    {
        can_block_p = CAN_CHANNELS[ch_nr];
    }
    else
    {
        return;
    }

    /* Set CAN clock select to be either PLL (default) or crystal direct. */
    can_block_p->BCR.BIT.CCLKS = 0; /* 0 = PLL. */

    /* Set TSEG1, TSEG2 and SJW. */
    can_block_p->BCR.BIT.BRP = CAN_BRP - 1;
    can_block_p->BCR.BIT.TSEG1 = CAN_TSEG1 - 1;
    can_block_p->BCR.BIT.TSEG2 = CAN_TSEG2 - 1;
    can_block_p->BCR.BIT.SJW = CAN_SJW - 1;
} /* end R_CAN_SetBitrate() */

[Erik F. (mc_fresh)]

Hallo Dave.

Ich habe mit den FIT Modulen angefangen, bin jedoch dazu übergegangen 
die Register "von Hand" zu beschreiben in einem eigenen Programm. Deine 
Timings sehen ziemlich gut aus. Leider registriert der CAN-USB Reader 
weiterhin Stuff, Bit und andere Errors. Kannst du mir sagen, was du für 
ein Transceiver verwendest?

Mit 250kbit/s sieht es leider auch nicht besser aus :/

Habe jetzt ein Oszi da und werde dem morgen auf den Grund gehen.

[Dave (Gast)]

Erik F. schrieb:
> Kannst du mir sagen, was du für
> ein Transceiver verwendest?
SN65HVD233DG4

Erik F. schrieb:
> Habe jetzt ein Oszi da und werde dem morgen auf den Grund gehen.

Ist wohl das einzig richtige..

[Erik F. (mc_fresh)]

So

Es hat sich etwas verzögert, aber hier habe ich eine "tolle" Aufnahme 
vom Fehler.

Habe ein Tektronix TDS2002B, die Qualität ist also dem geschuldet.
das Datagramm sieht wie folgt aus:

Gelb ist TX Pin vom uC (TX<->GND)
Blau ist CAN-BUS (CANL<->CANH)

0|000020000100|000|21000[01010010|000020000|0200000200|0002000002|000002000|0020000020|000020000|02!0000000][15x CRC]

! = hier tritt der Fehler auf, dass der Bus nicht auf rezessiv geht;
| = trennt die abschnitte - zur Übersichtlichkeit;
[Data];
2 = Stuffbit;
--> ID=4;DLC=8;data[1]=0x52; rest 0;

die verschiedenen CAN-Bus Spannungen ergeben sich durch die 
verschiedenen Nodes:
Höchste Spannung = "Referenz" Nodes
Mittlere Spannung = RX65N uC, der nicht geht <--
Niedrigste Spannung = USB-CAN-Reader

Ehrlich gesagt kann ich nicht verstehen, wieso der USB-CAN-Reader ein 
Dominantes Bit schreibt, obwohl der uC rezessiv sagt. Die Dominanten 
Bits danach (vor der Pause vor dem erneuten Senden des uC) sind von 
einem "Referenzteilnehmer", der denke ich, den Fehler auch sieht und 6x 
dominant schreibt.

Kann damit jemand etwas anfangen?

[Erik F. (mc_fresh)]

Hallo.
Weiter ist mir aufgefallen, dass die Menge an Fehlern mit der Nachricht 
an sich zusammenhängt.
0x00 --> viele Fehler
0x81 --> wenig Fehler (war zum besseren lesen des Datagramms gedacht)
0xFF --> viele Fehler

Auf dem angehangen Bild sieht man auch, dass nach dem ACK (Blaue Spitze 
zwei bits vor dem ersten Cursor) mein USB-CAN-Reader (niedrige blaue 
CAN-Differenzspannung) ein Dominantes Bit sendet, wo eigentlich 
EndOfFrame sein müsste.

Könnte das ein Indiz sein, dass der CAN-Reader vielleicht eine Störung 
hat? Nur dann müsste er bei meinem "Referenzknoten" auch Fehler 
"streuen".

Kann ich sonst etwas liefern, was euch nutzen könnte?