dsPIC33 ECAN Sendeprobleme

[Gast-n (Gast)]

Hallo,

ich kämpfe gerade etwas mit dem ECAN-Modul des dsPIC33F...

Als Grundlage dient die AN1249 von Microchip (hier Beschreibung und 
Code)
http://ww1.microchip.com/downloads/en/AppNotes/01249A.pdf
http://ww1.microchip.com/downloads/en/AppNotes/AN1249%20Source%20Code.zip

Die AN beschreibt die Konfiguration für 4 ECAN-Buffer: 1x Sendepuffer 
(buffer-0) und 3x Empfangspuffer (buffer-1..3).


Für meine Anwendung möchte ich mehrere Sendepuffer haben, also wurde die 
Anzahl der Buffer auf 8 geändert:
'ecan.h'

#define ECAN1_MSG_BUF_LENGTH  8

und 'ecan.c' Funktion 'initECAN'

C1FCTRLbits.DMABS = 0b010; // 8 CAN Messages to be buffered in DMA RAM
...
_TXEN4 = 1; // ECAN1 Buffer 4 is a Tx Buffer
_TXEN5 = 1; // ECAN1 Buffer 5 is a Tx Buffer
_TXEN6 = 1; // ECAN1 Buffer 6 is a Tx Buffer
_TXEN7 = 1; // ECAN1 Buffer 7 is a Tx Buffer

(Die Prioritäten für die Sendepuffer seien mal vernachlässigt)

Jetzt tritt nun folgender Effekt auf:
- Sende ich eine Botschaft mit Buffer-0 ('ursprünglicher' Tx-Buffer) 
dann funktioniert die Geschichte wunderbar

- Sende ich jedoch mit einem meiner 'neuen' Buffer senden, also Buf4..7, 
dann funktioniert dies NICHT zuverlässig.
Es wird nur etwa jede 5te Botschaft richtig abgesendet - bei den 4 
fehlerhaften stimmt zwar die Länge und die Nutzdaten, jedoch wird ein 
standard Identifier (11-bit) mit 0x00 0x00 0x00 0x00 verschickt und 
NICHT die eigentliche Msg-ID der Nachricht.

So, nun die eigentliche Frage;
Ist das ein generelles Problem, oder habe ich 'nur' eine wichtige 
Konfiguration vergessen?

Was mich an der Sache so stört ist, dass es mit der ID ja ab und zu 
funktioniert, dann wieder nicht - jedoch DLC und Nutzdaten IMMER passen.

Gruß

[manuel (Gast)]

Hoi
Ich bin in exakt dasselbe Problem reingerasselt. Hast du inzwischen eine 
Lösung gefunden?
Gruss,
Manuel

[manuel (Gast)]

habe gerade noch folgendes gefunden:
http://ww1.microchip.com/downloads/en/DeviceDoc/80306E.pdf

[C. H. (_ch_)]

Hallo Manuel,
nein, Lösung habe ich leider keine gefunden.
Als workaround verwende ich halt nur einen Tx Puffer (0) und mache meine 
Sende-queue unsinnigerweise wieder im RAM als FiFo Ringpuffer...

Das Errata-Sheet kannte ich noch gar nicht, danke der Info! Scheint ja 
echt ein Hardware-Bug zu sein.

Gruß
Christian

[Franz (Gast)]

Moin,

Habt Ihr auch brav im CiFCTRL ECAN FIFO Control Register
die FSAbits angepasst? (FIFO Start Area bits)?

Evtl ziegen die noch auf die vorherigen Buffer!

MfG,
Franz

[Ruslan K. (idrisk)]

Gibt es eine Lösung für das Problem von oben, denn ich bin genau an der 
selben stelle angekommen und es geht net weiter!

Gruß

[Ruslan K. (idrisk)]

Hi,

hab die Lösung schon selber gefunden!

die fkt. sendECAN am ende anpassen z.B.

  /* set the message for transmission */
  if(message->buffer == 0)
    C1TR01CONbits.TXREQ0=1;
  else if(message->buffer == 2)
    C1TR23CONbits.TXREQ2=1;

[Salmolin (Gast)]

Hast du das File CO_CANDRV.c angepasst , damit man dies auf einen 
dspic33 bringt!?
oder wie hast du das gelöst?

Gruss
salmolin

[vorgon (Gast)]

Falls jemand braucht kann ich ne Lib posten die Auf AN1249 basiert und 8 
Sendebuffer sowie 16 Empfangsbuffer benutzt.

[kopeika (Gast)]

Hallo vargon,

das wäre super, ich stehe momentan auch vor dem gleichen Problem

Grüße
kopeika