CAN1 does not work at 250 kbit/s bitrate setting

Please provide the following info (tick the boxes after creating this topic):
Software Version
[*] DRIVE OS 6.0.8.1
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
[*] Linux
QNX
other

Hardware Platform
[*] DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
1.9.3.10904
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
[*] native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

Good day,
I understand from previous discussions that instead of the promised 6 x CAN it is possible to use only 2 x CAN and that for can.socket; can0 and can.socket; can1. And can.aurix is not supported now, do you have a rough idea if it will be possible to use another CAN (connector P3, P4, P13, P14, P15) in the next version of DriveOS, because it is quite restrictive?
Through testing, I discovered that only connectors P11 and P12 can be used, where is this information in the manuals?
Through testing, I found that can0 for setting 1000 kbit/s does work, but according to the connected PCAN, it falls into BUSHEAVY status. For can1, when set to 250 kbit/s, the bus does not work and when PCAN is connected, the status is Busoff. What is the bitrate range for can0 and for can1?
Thank you

Please refer to the “Cable Harness H1 Connector DB9 Breakouts” tables in DRIVE AGX Orin Mechanical and Installation Guide.

Please see if information in To set can0 interface bitrate helps.

I assume you mean this note from the documentation:
3. This CAN port also connects to Orin CAN1 (GP19_CAN1_DOUT, GP20_CAN1_DIN) via CAN transceiver.
4. This CAN port also connects to Orin CAN0 (GP17_CAN0_DOUT, GP18_CAN0_DIN) via CAN transceiver.
According to the documentation for H1, note 3 is also for the P13 and P14 connectors, so when setting can0 it should also work on these connectors? Because it didn’t work in the test.
And I didn’t get an answer for P3, P4, P13, P14 and P15 connectors with the CAN bus. Will it be possible to use them in the near future?

Furthermore, you refer to the documentation for can0, I know about it, but as I already wrote when setting 1000 kbit/s, CAN messages are being transmitted, but CAN is in BUSHEAVY state even when sending 2 messages with a period of 1000 ms. This is a completely negligible load on the CAN bus.
And what about the can1? That’s not in the documentation. So the setting of 250 kbit/s cannot be used? Or what is the setting range for can1?

Thank you

Could you please share the specific section or page in the documentation where this information is located?

No.

Could you provide more detailed connections, configurations, and steps you followed when encountering the BUSHEAVY state issue on CAN0?

Good day,
sorry, I missed that there is a different explanation (note 3) for table 2-4 for pin 44, 43, 41, 40 than for table 2-5 in document DI-10587-003_v04. And the FSI_CAN0 or FSI_CAN1 is also not possible to use in any way? Or is it not necessary to access CAN at a lower level outside of DriveWorks, so that more CAN buses can be used?
Therefore, it would probably be appropriate to change https://developer.nvidia.com/drive/hyperion that the hardware only has 2 x CAN and not as you state “6 CAN interfaces”, because I’m probably not the only one who expected 6 x CAN.
From the point of view of connecting can0, the standard DSUB connectors were connected and between them there are two wires (twisted) fitted with 120 ohm resistors at the end. It was a standard connection that is used in the automotive industry. And PCAN hardware is connected on one side and P11 connector was connected on the other side. For 250 kbit/s and 500 kbit/s everything worked and for 1000 kbit/s PCAN status is BUSHEAVY but sending and receiving messages worked.
And I didn’t get an answer to:
So the setting of 250 kbit/s cannot be used? Or what is the setting range for can1? The connection was the same as in the previous case, but 250 kbit/s did not work.

Thank you

Please refer to FSI_CAN1 on Drive AGX Orin.

Thank you for providing the details regarding the CAN bus connections and the observed behavior. To better understand the issue, could you please provide more detailed steps on how you verified for both can0 (1000 kbit/s) and can1 (250 kbit/s)?

What did you mean ‘PCAN status is BUSHEAVY’ for can0 at 1000 kbit/s? Could you elaborate on how to tell?

Regarding can1 at 250 kbit/s, you mentioned it didn’t work. Could you provide details on the symptoms or error messages encountered during this configuration?

Good day,
I tried experimenting with can1 and the 250 kbit/s setting
P11 (can0) and P12(can1) were connected by two wires via DSUB9 connectors and the third connector is connected to PCAN (CAN analyzer). The ends of the wires are fitted with 2 x 120 ohms.
Message ID 0x18FF0102 being sent from can0. Can0 and can1 have no filter set, so they read everything. The PCAN analyzer generates messages 0x18FF0101 after 1000 ms
In this case, everything works:

  • can0 sees message from PCAN 0x18FF0101
  • can1 sees message from PCAN 0x18FF0101 and from can0 0x18FF0102
  • PCAN sees message from can0 0x18FF0102

BUT when turning on the sending of another message from PCAN 0x18FF0201, PCAN sees nothing and reports Bus-Off. Can0 and can1 also do not see messages from PCAN. Bus-Off For PCAN hardware this means:
The CAN controller has entered the “Bus-Off” state because a serious and continuous error exists on the bus (255 error points have been exceeded). A possible cause can be a short circuit on the bus.
If I change the Source address for the message from PCAN 0x18FF0201, for example, from 01 to 02, that means 0x18FF0202, then everything works again. So I don’t know what the problem is. There was also a problem with message 0x18FFB203.

Code:

int main(int argc, char** argv)
{
(void)argc;
(void)argv;

dwStatus status;

std::cout << "*************************************************" << std::endl;
std::cout << "AVK_example_CAN_can0tocan1_250" << std::endl;
std::cout << "*************************************************" << std::endl;

dwSensorParams params_CAN_0{};
dwSensorParams params_CAN_1{};
params_CAN_0.protocol = "can.socket";
params_CAN_0.parameters = "device=can0";
params_CAN_1.protocol = "can.socket";
params_CAN_1.parameters = "device=can1";

dwSensorHandle_t canSensor_CAN_0;
dwContextHandle_t sdk_CAN_0 = DW_NULL_HANDLE;
dwSALHandle_t hal_CAN_0     = DW_NULL_HANDLE;
{
	dwContextParameters sdkParams_CAN_0 = {};
	CHECK_DW_ERROR(dwInitialize(&sdk_CAN_0, DW_VERSION, &sdkParams_CAN_0));
	dwSAL_initialize(&hal_CAN_0, sdk_CAN_0);
}
status = dwSAL_createSensor(&canSensor_CAN_0, params_CAN_0, hal_CAN_0);
status = dwSensor_start(canSensor_CAN_0);

dwSensorHandle_t canSensor_CAN_1;
dwContextHandle_t sdk_CAN_1 = DW_NULL_HANDLE;
dwSALHandle_t hal_CAN_1     = DW_NULL_HANDLE;
{
	dwContextParameters sdkParams_CAN_1 = {};
	CHECK_DW_ERROR(dwInitialize(&sdk_CAN_1, DW_VERSION, &sdkParams_CAN_1));
	dwSAL_initialize(&hal_CAN_1, sdk_CAN_1);
}

status = dwSAL_createSensor(&canSensor_CAN_1, params_CAN_1, hal_CAN_1);
status = dwSensor_start(canSensor_CAN_1);

int loop = 1;
while(loop)
{
    dwCANMessage msg{};
    status = dwSensorCAN_readMessage(&msg, 0, canSensor_CAN_0);
    std::cout << "Status Read CAN 0: " << status << std::endl;
	while(status == DW_SUCCESS)
	{
		std::cout << "Read CAN 1: Msg: 0x" << std::setw(8) << std::hex << std::uppercase
				<< msg.id << std::endl;
		status = dwSensorCAN_readMessage(&msg, 0, canSensor_CAN_0);
		std::cout << "Status Read CAN 0: " << status << std::endl;
	}

	msg.id = 0x18FF0102;
	msg.data[0] = 0xFF;
	msg.size = 8;
	msg.timestamp_us = 0;
	status = dwSensorCAN_sendMessage(&msg, 10000, canSensor_CAN_0);
	std::cout << "Status Write CAN 0: " << status << std::endl;

	status = dwSensorCAN_readMessage(&msg, 0, canSensor_CAN_1);
	std::cout << "Status Read CAN 1: " << status << std::endl;
	while(status == DW_SUCCESS)
	{
		std::cout << "Read CAN 1: Msg: 0x" << std::setw(8) << std::hex << std::uppercase
			<< msg.id << std::endl;

		status = dwSensorCAN_readMessage(&msg, 0, canSensor_CAN_1);
		std::cout << "Status Read CAN 1: " << status << std::endl;
	}

    std::this_thread::sleep_for(std::chrono::milliseconds(1000));
    const auto now = std::chrono::system_clock::now();
    const std::time_t t_c = std::chrono::system_clock::to_time_t(now);
    std::cout << "Time: " << std::ctime(&t_c) << std::endl;
}

dwSensor_stop(canSensor_CAN_0);
dwSAL_releaseSensor(canSensor_CAN_0);

dwSensor_stop(canSensor_CAN_1);
dwSAL_releaseSensor(canSensor_CAN_1);

return 0;

}

I also tried setting quantum directly and as I tried different variants, it seems that you have an error when setting tq 16:
sudo ip link set can0 down; sudo ip link set can0 type can tq 16 prop-seg 93 phase-seg1 94 phase-seg2 62 sjw 1; sudo ip link set can0 up
Number of time quanta = 93 + 94 +62 + 1 = 250
Bit time = tq * Number of time quanta = 16 * 250 = 4000 ns
Bit rate = 1/(4000/1000000000) = 250,000 bit/s
When using the command:
ip -details -statistics link show can0
a bit rate of 200,000 bit/s is written in the console. It’s like it takes the smallest value of tq 20, but I couldn’t find a limit for it anywhere.
can1_set_error

I also don’t know if it’s ok if I use the command
sudo ip link set can1 type can bitrate 250000; sudo ip link set can1 up
and I leave can0 in the stop state. So can1 doesn’t work. Only when I set can0 does it work.

Thank you

Does it have anything to do with the PCAN? What if it’s not connected?
Can you follow Test Classic (Non-FD) CAN to test the message IDs between can0 and can1?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.