PEAK-System Forum

Hello,

If a user program is ended without calling CAN_Uninitialize (e.g. due to forced termination from task manager) at high bus loads on restart (e.g. also visible in PCAN View) the receive buffer contains false messages (i.e. theses messages are not currently on the bus - instead this is traffic at previous programm termination without calling CAN_Uninitialize()).

I tried a workaround to ensure CAN_Uninitialize() is called via atexit(). But I noticed the status from CAN_Uninitialize() within atexit() is 0x40000 (i.e. PCAN_ERROR_INITIALIZE).

So I assume there is a bug (e.g. race condition) in the driver during release of the interface if invocation of CAN_Uninitialize() does not happended. As I noted atexit() seems no workaround.

This behavoiur is observed with driver 3.13.0.15462.

Do you know a way to ensure CAN_Uninitialize() is called correctly for a console application?

Thanks
H. Mueller

Hello,

H.Mueller wrote:... the receive buffer contains false messages (i.e. theses messages are not currently on the bus - instead this is traffic at previous programm termination without calling CAN_Uninitialize()).

Just for clarification, since this can be easily misinterpreted by other users: They are not false/wrong messages if they were sent/received at any time by the hardware. They are just queued.

H.Mueller wrote:If a user program is ended without calling CAN_Uninitialize (e.g. due to forced termination from task manager) at high bus loads on restart (e.g. also visible in PCAN View) ...

You should know that CAN keep trying to send messages that were not successfully sent. If you are sending messages from hardware-A to hardware-B (and there is no other CAN-participant that reads message on that hardware-B), the hardware-A will keep trying to re-send those messages until they get read (e.g. another participant get online). At this point the new participant (on hardware-B) will receive all those messages (in your case another instance of PCAN-Basic, or PCAN-View).

H.Mueller wrote:I tried a workaround to ensure CAN_Uninitialize() is called via atexit(). But I noticed the status from CAN_Uninitialize() within atexit() is 0x40000 (i.e. PCAN_ERROR_INITIALIZE). So I assume there is a bug (e.g. race condition) in the driver ...

This is not a bug. PCAN-Basic just know when applications attached to it terminates (normal, or abnormal) and closes all opened channels. So atexit calls Uninitialize on an uninitialized channel, i.e. the error is fully correct.

Hello Keneth,

Thanks for your fast resonse.

In fact you are right after another test. If I power off of the sender, I do not see these unexpected messages.
If the sender is still powered, it seems it will keep trying to re-send those messages until they get read as you wrote.
That is what I oberseved in my first post, but my interpretation was false.

Thanks
H. Mueller

A program could just as well circumvent the issue of there potentially being left-over messages in the TX queue from a previous application by first calling CAN_Unitialize and only then calling CAN_Initialize, right? Or do you see any problems with that approach?

EDIT: Never mind ... stupid idea. Obviously can't uninitialize a channel that was never initialized in the first place.