Router overloaded?

[cgmollo62]

Hi. I realize it is difficult to inform on when the PCAN-Router FD might be overloaded, but I suspect that is what is happening in our situation. We are using the router to convert about 15 CAN messages from CAN FD to CAN 2.0. However, the CAN FD network has 316 unique messages on it. Message rates range from 10 msec to 1000 msec, with 100 msec and 250 msec being the most common. Message DLCs range from 6 to 64... the average is about 11.

We recorded about 5 seconds of the CAN FD traffic. On average, a message is received about every 260 microseconds. On average, about 43 DLCs worth of data is received every millisecond.

Is the above information enough to make a judgment call that the router is probably overloaded?

Are the limits of the router known and quantified in any way? If so, could you share that information?

We have tested the firmware on a "test bench" with very low message load... everything works great.

However, when we put the router on the actual vehicle CAN FD network it does not transmit any messages. The firmware is programmed to blink the CAN1 LED when a message is successfully received (CAN_UserRead(CAN_BUS1, &RxMsg) == CAN_ERR_OK evaluates as true). The CAN1 LED does blink when the router is running, so we think messages are being received OK (CAN data bit rates are configured OK, etc.).

The firmware is programmed to blink the CAN2 LED if it attempts to transmit a message (regardless of success). The CAN2 LED does not blink. We also connected PCAN-View to the CAN2 side and we do not see any messages.

So, we are thinking our firmware code never completely executes the processing loop because the router is overloaded with handling the incoming CAN messages. Could this be? Is the user-programmable code interrupted to handle incoming CAN messages?

What happens when the router is overloaded? Does it go into constant reset?

Is there a way to check if the router is being overloaded?

Any opinion you can offer would be greatly appreciated!

[PEAK-Support]

If you convert from CAN FD to a CAN2.0a/b Network, it is up to you to check if the CAN 2.0a/b Network could even handle the messageflow (Network Management)
We could not do this for you, as we do not know what exact happend on both sides of your CAN Networks, which CAN Frames and which real Busload is on both CAN Channels, what else do you do inside the CAN Router Firmware (maybe signal conditioning..we do not know). All this paramaters are influence the workflow. Also keep in mind that a BRS Message need less time on a Network as a normal CAN Frame etc. You should calculate all Network Timings, and first of all be sure that the network(s) could handel it. After that simply forward the Frames - step by step - until you run into your problem. Measure with a scope, or CAN FD PEAK Hardware, the Busload, to be sure that it is realistic what you want to do. The Router FD is a fast Device - but all is depending on the Bitrate / Data rate on both Networks and the way you route the CAN Frames or maybe Signals (single Data Bytes)

You could check the can_user.c file - here you find the code of the CAN_UserRead function. Simply use this code to extend it for your need if the information (CAN_BUFFER_STATUS, CAN_BUFFER_CRITICAL) is not enough for you. For Example switch on LED if you run into "CAN_BUFFER_CRITICAL" state etc.

Code: Select all

// CAN_UserRead
// This wrapper is used to pre-process some incoming data.
CANResult_t  CAN_UserRead ( CANHandle_t  hBus, void  *buff)
{
	CANResult_t  ret;
	CANBuffer_t  *rx_buff;
	
	ret = CAN_ERR_RX_EMPTY;
	rx_buff = buff;
	
	if ( CAN_Read ( hBus, rx_buff) == CAN_ERR_OK)
	{
		// buffer read from CANx. Check type of buffer.
		switch ( rx_buff->bufftype)
		{
			case CAN_BUFFER_STATUS:
				// the buffer is a status notification from the CAN controller.
				if ( /*!busOFF[hBus]  &&*/  rx_buff->status.bus_status)
				{
					// CAN controller not involved into bus activities
					
					// uninitialize (this includes a TX-path flush)
					CAN_UnInitialize ( hBus);
					
					// initialize CAN controller
					CAN_Initialize ( hBus, &Timing_CANx[hBus]);
				}

				// remember last state to suppress initialization endless loop
				// due to redundant status frame
				//busOFF[hBus] = rx_buff->status.bus_status;
				break;		
				
			case CAN_BUFFER_RX_MSG:
				// the buffer is a receive message. Forward to application.
				ret = CAN_ERR_OK;
				break;
								
			case CAN_BUFFER_CRITICAL:
				// receive queue level was critical. Data might be lost.
				break;
		}
	}
	return ret;
}

[cgmollo62]

Thank you very much for the reply. I am not concerned about the CAN 2.0 network (or the CAN FD network)... my concern is solely with the PCAN router. The info you provided on can_user.c is helpful. Thanks!

Just as an FYI, the router has to check every incoming CAN FD message to see if it is one of the 15 messages we want to convert and send out as a CAN 2.0 message. If it is one of the 15, then certain bytes are copied to the CAN 2.0 message. For example:

Code: Select all

			else if (RxMsg.id == 0x214)
			{
				TxMsg.id       = 0x423;                 
				TxMsg.msgtype  = CAN_MSGTYPE_STANDARD;
				//TxMsg.size     =                        // computed by CAN_Write function
				TxMsg.bufftype = CAN_BUFFER_TX_MSG;
				TxMsg.data8[0] = RxMsg.data8[8];
				TxMsg.data8[1] = RxMsg.data8[9];
				TxMsg.data8[2] = RxMsg.data8[17];
				TxMsg.dlc      = CAN_LEN3_DLC;          // number of bytes of data (0 - 8)
				
				num_msgs_to_tx = 1;
			}

Sometimes two or three CAN 2.0 messages are generated from one CAN FD message.

Anyhow, hopefully that gives you some sense of the processing we have programmed into the router. I will post again to this forum topic if we make any further discoveries.

Thanks again!

Chris

[PEAK-Support]

Thank you for the Information - we recommend to use a switch instead a if/then/elsif ...
You also could change the compiler optimation (see make file), after you think your firmware is ready, to a higher level.

[cgmollo62]

Yes... I was thinking about changing the long if / else if to a switch construct. I will do that. Thanks for the tip on the compiler optimization!

Chris

[cgmollo62]

We eventually figured out that the CAN network configuration was not quite correct. Some CAN messages were coming in with the incorrect configuration, so that confused the situation at first... we figured the configuration was probably OK since some messages were coming into the firmware. Turns out, that was not a valid conclusion. Once we changed the CAN network configuration programmed into the router, things worked great! The router is a very fast device. It seems to be handling the 300+ incoming messages, checking them against a list of about 20 messages (now using a switch construct) to convert to CAN 2.0 and transmit. Thanks again for your help!