Receive queue non-empty if previous CAN_Uninitialize missing

The free CAN Software API (Application Programming Interface) for Windows®
Post Reply
H.Mueller
Posts: 6
Joined: Wed 6. Aug 2014, 16:05

Receive queue non-empty if previous CAN_Uninitialize missing

Post by H.Mueller » Fri 5. Dec 2014, 16:17

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

K.Wagner
Software Development
Software Development
Posts: 767
Joined: Wed 22. Sep 2010, 13:36

Re: Receive queue non-empty if previous CAN_Uninitialize mis

Post by K.Wagner » Mon 8. Dec 2014, 12:23

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.
Best regards,
Keneth

H.Mueller
Posts: 6
Joined: Wed 6. Aug 2014, 16:05

Re: Receive queue non-empty if previous CAN_Uninitialize mis

Post by H.Mueller » Mon 8. Dec 2014, 13:16

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

antred
Posts: 4
Joined: Thu 3. Sep 2015, 13:50

Re: Receive queue non-empty if previous CAN_Uninitialize mis

Post by antred » Fri 28. Apr 2017, 09:25

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.

Post Reply