How can I reset the Tx Buffer of Peak CAN

[rachedrech]

Hi,

I am using PCAN USB PRO FD to establish a connection in FD can with a microcontroller.

When I try to send a CAN frame to the MCU while it's not connected or not even powered, the peak CAN tries always to send the message because when I first turn on and connect the MCU, the peak sends the last messages and I dont want that to happen, I already call the Reset method to reset the PCAN in case there was no reception of the messages but that didnt work either.

can you suggest something else that might delete or clear the last unsuccessfull messages ? Thank you in advance

[PEAK-Support]

The CAN Core of our Interface try to resent the message again and again, because there is no 2nd active CAN node that ACK the Frame - this is normal in a CAN System.
Simply call CAN_Init(..) again, then the CAN Core also delete the Msg in the Tx buffer. Or you add the 2nd CAN Channel of you PCAN-USB Pro FD to the Network and run the PCAN-View Software with this channel- Then the 2nd CAN Channel will ACK the Frame and it will be send only once!

[rachedrech]

thank you for your reply,

I am using the PCAN Basic with java, I only have Initialize and InitializeFD methods, there's no CAN_init, will it work with these methods ?

EDIT: I tried with InitializeFD and unfortunately it solve the problem, I still getting the messages after I restart the MCU

[PEAK-Support]

If you use on your Network the CAN-FD standard use the CAN FD Init, if you use the CAN2.0a/b please use the normal CAN Initialize. The JAVA functions are only wrappers for the PCAN-Basic Interface DLL (using a JNI DLL) - so you could read the Onlen Help of the PCAN-Basic API to get more Info how it works.

After the Initialize, the Tx is definatly deleted. Please check always the MsgType of the Frame you read with the API - it also could be a Status Frame - it must not be a real CAN Frame !

[rachedrech]

the only way that seems to delete the TX messages is when I reconnect the USB cable, even using the CAN initFD function won't work

[PEAK-Support]

You are wrong...with the CAN_Init or CAN_Init FD Function the CAN Controller will be reset and lost all Tx Messages. You need to check the Msg.Type as i wrote .....
send us WHAT exact you receive in your application - with ALL Information.

[rachedrech]

Okay, here you go:
I tried to send can message from my GUI to the microcontroller using the function writeFD while the MCU's CAN is not configured, so i get an error in my gui which is normal saying that the chip is not in CAN bootloader mode.
I added the InitializeFD function after detecting this error so it will clear the TX queue.
So, After resetting the MCU in bootloader, I receive instantly the last message that i tried to send and here are the informations that i get from the MCU :
--------------------------
CAN Message info:
- Dir : RX
- Remote : No
- ID type : Std - 0x2
- FDF type: No
- BRS type: No
- ESI type: No
- DLC = 0
--------------------------

But if I do the same thing and disconnect and reconnect the PCAN USB cable before restarting MCU in bootloader then there will be no messages

[K.Wagner]

Hello,

I think you are missing a step. As Uwe said, the new initialization of the channel (CAN_Initialize, or CAN_InitializeFD) does reset the device TX queue. From your post I assume you are calling CAN_InitializeFD without uninitialize the channel. This means moreover that you are not checking the result values, since a call of CAN_Initialize/CAN_InitializeFD on an already initialized channel will fail with the error CAN_ERROR_INITIALIZE.

Help of CAN_Initialize

PCAN-Basic_Init.PNG (38.54 KiB) Viewed 14611 times

The right steps should be:

• Initialize your channel (CAN_Initialize/CAN_InitializeFD)
• Try to send your data
• In case you get the mentioned error with the MCU, re-initialize your channel
  • Uninitialize your channel (CAN_Uninitialize/CAN_UninitializeFD)
  • Initialize your channel (CAN_Initialize/CAN_InitializeFD)

hope now you get your device reset,

[rachedrech]

Yes thank you, calling unitialize before initializing solves the problem

[PEAK-Support]

OK - thanks for the feedback - i thought it was clear that you need to call CAN_Uninitialize up in front before callling CAN_Initialize. Sorry !