Probleme mit CAN

ada · Sep 2nd 2008

Hallo,

Für unser Projekt wurde auf dem NETDCU8 ein DOS-Programm so angepasst, dass die Kommunikation mit
unserer Hardware über die CAN-Schnittstelle ohne Probleme funktionierte. Beim Umstieg auf den PicoCom1
wurden zwar CAN-Telegramme ausgegeben (HW reagierte) aber die Antworttelegramme wurden nicht eingelesen (Timeout).
Für Testzwecke habe ich das folgende vereinfachte Testprogramm auf Basis der bestehenden Funktionen geschreiben (NetDCU ok, Picocom1 mit Timeout beim Empfang)
Aufgefallen ist mir, dass beim Aufruf des Programms die Meldung: 'ETH: LookupRxBuffers : Error BNA!!' mehrfach auf der Debugschnittstelle
(COM3) ausgegeben wird. Besteht evtl. damit ein Zusammenhang und wie kann ich diesen Fehler beheben?
Wenn sie mir weiterhelfen könnten wäre ich ihnen sehr dankbar

aktuelle PICOCom1 Firmware:
Boot Loader, Version 1.1
PicoCOM1 V1.03 Build: Jul 30 2008/08:12:04

Sourcen

Code

int WINAPI WinMain( HINSTANCE hInstance,HINSTANCE hPrevInstance,LPTSTR lpCmdLine,int nCmdShow)
{
test_can();
return 0;
}
int test_can()
{
DWORD dwCount = 1000;
OBJEKT obj_ptr;
BYTE b[8]={0,0,0,0,0,0,0,0};
DWORD dwBaud = 1000000;
if(!CanADR[0].Init(_T("CID1:"),dwBaud))
return(0);
obj_ptr.id = 0x380;
obj_ptr.dlc = 1;
memcpy(obj_ptr.daten,b,8);
write_bcan(0,&obj_ptr);
do
{
if (read_bcan(1,0,&obj_ptr) == BCAN_OK)
{
obj_ptr.dlc = 1;
memcpy(obj_ptr.daten,b,8);
write_bcan(0,&obj_ptr);
}
Sleep(100);
}while(dwCount--);
return(0);
}
can_fun.c:
CCAN CanADR[CAN_MAX];
DWORD ErrorStatus[CAN_MAX]; //Fehlerspeicher
OBJEKT objecT; //Zwischenspeicher für einkommende message
char objectReceived = FALSE; //Zwischenspeicher gefüllt?
/*----------------------------------------------------------------------
**
** @func unsigned char | read_bcan | Objekt aus dem Controller auslesen und dabei den Timeout in ms abwarten<nl>
**
** @parm unsigned short | timeout | Timeout in ms<nl>
** @parm unsigned char | net | Nummer des Netzwerks<nl>
** @parm OBJEKT * | obj_ptr | Zeiger für die Daten<nl>
**
** @rdesc BCAN_ERR_ERROR - bei Fehler<nl>
** BCAN_OK - Daten eingelesen<nl>
** BCAN_ERR_OVER - event over run<nl>
**
*/
unsigned char read_bcan(unsigned short timeout,unsigned char net,OBJEKT *obj_ptr)
{
unsigned char status;
CANMSG pcm;
if (objectReceived) //zwischengespeicherte Daten?
{
obj_ptr->dlc = objecT.dlc; // Anzahl der Datenbytes
obj_ptr->id = objecT.id; // Identifier
obj_ptr->rtr = objecT.rtr; // RTR-Bit eintragen
memcpy(obj_ptr->daten,objecT.daten,obj_ptr->dlc);
objectReceived = FALSE;
status = BCAN_OK;
}
else
{
status = BCAN_ERR_TIME;
timer_1ms_start( timeout );
do
{
switch (CanADR[net].ReadMessage(&pcm))
{
case CANBUS_EVENT_RECEIVED:
obj_ptr->dlc = (unsigned char)(pcm.byDatalength); // Anzahl der Datenbytes
obj_ptr->id = (unsigned short)(pcm.dwIdentifier); // Identifier
obj_ptr->rtr = 0; // RTR-Bit eintragen
memcpy(obj_ptr->daten,pcm.byContent,obj_ptr->dlc);
status = BCAN_OK;
break;
case CANBUS_EVENT_OVERRUN:
CanADR[net].ClearOverrun();
status = BCAN_ERR_OVER;
break;
case CAN_ERROR:
status = BCAN_ERR_ERROR;
break;
default:
break;
}
}
while( timer_1ms_laeuft() && (status == BCAN_ERR_TIME));
}
return(status);
}
/*----------------------------------------------------------------------
**
** @func unsigned char | write_bcan | ein Objekt verschicken<nl>
**
** @parm unsigned char | net | Nummer des Netzwerks<nl>
** @parm OBJEKT * | obj_ptr | Zeiger für die Daten<nl>
**
** @rdesc Status<nl>
**
*/
unsigned char write_bcan(unsigned char net,OBJEKT *obj_ptr)
{
unsigned char status;
CANMSG cm;
timer_1ms_start( 10u ); // Timeout 10 ms
do
{
switch (ReadTxStatus(net))
{
case 0 : // daten können gesendet werden
memcpy(cm.byContent,obj_ptr->daten,8);
cm.byDatalength = obj_ptr->dlc;
cm.dwIdentifier = obj_ptr->id;
CanADR[net].Write(&cm);
status = BCAN_OK;
break;
case 1 : /* sendevorgang noch nicht beendet */
case 2 : /* daten im empfangspuffer */
status = BCAN_ERR_TIME;
break;
case 3 : /* BC-Error */
status = BCAN_ERR_ERROR;
break;
default : /* overrun flag gesetzt ? softi stp */
status = BCAN_ERR_OVER;
CanADR[net].ClearOverrun();
break;
}
}
while( timer_1ms_laeuft() && (status != BCAN_OK));
return(status);
}
/*----------------------------------------------------------------------
**
** @func BYTE | ReadTxStatus | Die Funktion 'ReadTxStatus' liefert den Status über 'TransmitBCan'
** Wird ein BasicCan-Error zurückgeliefert, so kann das Statusregister aus
** der globalen Variable 'ErrorStatus[can_nr]' ausgelesen werden.<nl>
**
** @parm unsigned char | can_nr | Nummer des angewählten CAN im Array CanADR[..]<nl>
**
** @rdesc 0 --> Daten dürfen eingetragen/gesendet werden<nl>
** 1 --> Daten können noch nicht eingetragen werden, da Zugriff auf Transfer-Buffer gesperrt<nl>
** 2 --> Daten können nicht gesendet werden, da Receive-Buffer nicht frei<nl>
** 3 --> BasicCan-Error aufgetreten<nl>
** 4 --> nicht definiert<nl>
**
*/
BYTE ReadTxStatus( BYTE can_nr )
{
CANMSG pcm;
BYTE nret;
switch (CanADR[can_nr].ReadMessage(&pcm))
{
case 0: //no event
case BCAN_ERR_TIME: //Daten können gesandt werden (eingangspuffer ist leer)
nret = 0; //Daten dürfen gesendet werden
break;
case CANBUS_EVENT_TRANSMITTED:
nret = 1;
break;
case CANBUS_EVENT_RECEIVED:
nret = 2; //Receive-Buffer nicht frei -> Daten zwischenspeichern
objecT.dlc = (unsigned char)(pcm.byDatalength); // Anzahl der Datenbytes
objecT.id = (unsigned short)(pcm.dwIdentifier); // Identifier
objecT.rtr = 0; // RTR-Bit eintragen
memcpy(objecT.daten,pcm.byContent,objecT.dlc);
objectReceived = TRUE; //Daten zwischengespeichert!
break;
case CAN_ERROR:
ErrorStatus[can_nr] = GetLastError();
nret = 3; //BasicCAN Error
break;
default:
nret = 4; //event overrun?
break;
}
return(nret);
}
===================================================
Ãƒâ€žnderungen in can.cpp aus cancheck-Demo:
bool CCAN::Init(TCHAR* pszName, DWORD dwBaudrate)
{
if( m_hCAN != INVALID_HANDLE_VALUE )
{
CloseHandle( m_hCAN );
}
m_hCAN = CreateFile(pszName, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL );
DWORD dwMode=CANBUS_FORMAT_CAN_2_0_A;
CAN_ACCEPTANCE_FILTER filter;
filter.mask = 0x3FF;
filter.code = 0x000;
if( m_hCAN == INVALID_HANDLE_VALUE )
return false;
if(!DeviceIoControl( m_hCAN, IOCTL_CAN_INIT, NULL, 0, NULL, 0, NULL, NULL ))
return false;
if(!DeviceIoControl( m_hCAN, IOCTL_CAN_SET_CAN_MODE,&dwMode, sizeof(DWORD), NULL, 0, NULL, NULL ))
return false;
if(!SetFilter( &filter))
return false;
if(!SetBaudRate(dwBaudrate))
return false;
::SetCommMask(m_hCAN,CANBUS_EVENT_RECEIVED|CANBUS_EVENT_BUS_ERROR|CANBUS_EVENT_WARNING);
return true;
}
DWORD CCAN::ReadMessage( CANMSG* pcm )
{
DWORD dlc=0;
DWORD dwEvent=0;
DWORD dRet = 0;
CAN_EVENT event;
memset( &event, 0, sizeof( event ) );
DWORD dw;
if( DeviceIoControl( m_hCAN, IOCTL_CAN_READ_EVENT_DATA, NULL, NULL, &event, sizeof(CAN_EVENT), &dw, NULL ) )
{
// msg available
if( event.event == CANBUS_EVENT_TRANSMITTED )
{
// check for lost message
if( event.lost )
{
dRet = CAN_ERROR;
}
else
dRet = CANBUS_EVENT_TRANSMITTED;
}
else if( event.event == CANBUS_EVENT_RECEIVED )
{
// new msg received. finish loop.
pcm->dwIdentifier = event.data.identifier;
pcm->byDatalength = event.data.dlc;
memcpy( pcm->byContent, event.data.msg, pcm->byDatalength );
dRet = CANBUS_EVENT_RECEIVED;
}
else if( event.event == CANBUS_EVENT_OVERRUN )
dRet = CANBUS_EVENT_OVERRUN;
}
else
{
dRet = GetLastError();
if (dRet == ERROR_NO_MORE_ITEMS)
dRet = 0;
else
dRet = CAN_ERROR;
}
return (dRet);
}

Display More

ada · Sep 8th 2008

Hallo,

nachdem wir bisher die CAN-Schnittstelle nur mit einem CAN-Sniffer überprüft haben, haben wir zwischenzeitlich noch mit dem Oszi die CAN-Kommunikation überprüft. Es konnten keine Fehler festgestellt werden. Sende und Empfangstelegramm (Quittierung, ..) sind ok. Vom PICOCom1 wird das empfangene Antworttelegramm zwar quittiert, aber kein CANBUS_EVENT_RECEIVED zurückgemeldet.

Aus anderen Beiträgen weiss ich, dass es mit dem CAN-Treiber Probleme gibt. Haben sie zwischenzeitlich eine Lösung?
Unter anderem wird im Beitrag 'EventMask CAN-bus' vom 05.08.2008 wird ein neuer Treiber für die CAN-Schnittstelle angekündigt. Wo kann ich ihn finden?
Des weiteren wurde im Beitrag 'CAN-Schnittstelle über -Controller auf dem Modul?' vom 27.06.2008 ein Software-Paket zum Testen der CAN-Schnittstelle angekündigt. Wo kann ich dieses SW-Paket finden?

Könnten sie zumindestens einen Status zur CAN-Schnittstelle mitteilen, falls sie noch Ãƒâ€žnderungen vornehmen müssen.

Vielen Dank

fs-support_HK · Sep 9th 2008

Quote from "ada"

Unter anderem wird im Beitrag 'EventMask CAN-bus' vom 05.08.2008 wird ein neuer Treiber für die CAN-Schnittstelle angekündigt. Wo kann ich ihn finden?

Gerade gestern haben wir einen neuen PicoCOM1-Kernel online gestellt (NKPC1_CORE_CF2_080908 bzw. NKPC1_CORE_CF35_080908). Probieren Sie es mal damit.

Quote

Des weiteren wurde im Beitrag 'CAN-Schnittstelle über -Controller auf dem Modul?' vom 27.06.2008 ein Software-Paket zum Testen der CAN-Schnittstelle angekündigt. Wo kann ich dieses SW-Paket finden?

Damals (am 30.7.) hatten wir aber doch schon einen neuen Kernel veröffentlicht (NKPC1_CORE_CF35_080730). Hatten Sie bisher schon diesen Kernel im Einsatz? Weil sonst könnte es sein, dass der Befehl SetCommMask() die Problematik bewirkt.

Das Problem insgesamt ist, wie diverse Dinge miteinander zusammen hängen. Der CAN-Controller hängt per SPI am Microcontroller. Also muss man hier aufpassen, dass der CAN-Treiber mit dem SPI-Treiber zusammenspielt. Die ersten Versionen taten dies nämlich noch nicht. Der SPI-Treiber wurde aber erst jetzt fertig.

Auch das Tool zum Testen der CAN-Schnittstelle ist leider noch nicht ganz fertig. Es benutzt diverse Dialoge, um alle Features des Treibers einfach konfigurieren und anzeigen zu können und das ist eben nicht mal so schnell nebenbei programmiert wie ein kleines Kommandozeilentool. Und leider musste ich wegen eines dringenderen Projektes (auch im Zusammenhang mit der PicoCOM1) hier die Arbeit für eine Weile unterbrechen. Da wir natürlich auch selbst dieses Tool zum Testen des CAN-Treibers einsetzen wollten, und wie gesagt das Zusammenspiel zum SPI-Treiber funktionieren sollte, hatten wir bisher die Veröffentlichung etwas verzögert.

Nachdem nun aber einige Anfragen kommen, haben wir eben doch schon jetzt einen weiteren Kernel veröffentlicht, auch ohne dass das CAN-Testtool zur Verfügung steht. Insofern gehe ich davon aus, dass der CAN-Treiber grundsätzlich schon ganz gut funktioniert, aber im Detail mag es vielleicht noch irgendwo klemmen.

Könnte es bei Ihrem konkreten Problem sein, dass der Acceptance-Filter falsch gesetzt ist? Lesen Sie doch mal den aktuellen Wert zurück. Bitte beachten Sie, dass für jedes geöffnete Filehandle nun ein eigener virtueller Channel geöffnet wird mit eigenem Acceptance-Filter. Haben Sie den Eintrag "Align" oder "MaskActive" in der Registry irgendwie gesetzt?

Mit freundlichen Grüßen,

H. Keller

ada · Sep 12th 2008

Leider habe ich z.Zt. das Problem, dass ich den ursprünglichen Zustand (Senden ja, Empfangen nein) nicht mehr zum laufen bekomme. Ein Wechsel des PICOCom1 hat keinen Erfolg gebracht. Weder mit unserer Hardware als auch mit dem Starterkit ist eine Ausgabe auf die CAN-Schnittstelle erkennbar (überprüft z.B. mit Oszi). Bei der Selbstdiagnose ('T'-Kommando) wird CAN als ok gemeldet. Z. Zt. wird eine neue HW aufgebaut, die hoffentlich den ursprünglichen Zustand wieder herstellt.

Bei den ursprünglichen Tests war die aktuelle PICOCom1 Firmware:
Boot Loader, Version 1.1
PicoCOM1 V1.03 Build: Jul 30 2008/08:12:04 -> (NKPC1_CORE_CF35_080730)

In der Registry stehen folgende Angaben:
Prefix CID
DLL CANDRV.dll
Order 32
Index 1
Ioctl 4
FriendlyName CAN interface for PicoCOM
DeviceArrayIndex 0
IRQ 1
Die Einträge "Align" und "MaskActive" wurden von mir nicht gesetzt.
Den Acceptance-Filter hatte ich kontrolliert (mit Funktionen aus ihrem CANcheck-Programm), ebenso unsere HW die eine korrekte Antwort lieferte.
Als Referenz hatte ich zusätzlich das NETDCU8 Starterkit, bei der die Kommunikation über die CAN Schnittstelle ohne Probleme läuft.
Bei den Tests wurde immer mit derselben HW nach der CAN-Schnittstelle (NETDCU8, Picocom1) gearbeitet.

PS
Beim Aufruf des WCE Remote Registry Editors ist mir aufgefallen, dass die Meldung: 'ETH: LookupRxBuffers : Error BNA!!' ebenfalls mehrfach auf der Debugschnittstelle (COM3) ausgegeben wird.

Mit freundlichen Grüssen
M.Kast

Share