IWR6843AOP: CAN-FD multiple devices

Hi Adam,

An expert will reply shortly.

Best,

Nate

Hi Nathan,

In the meantime, I've made some additional observations. I've increased the frame periodicity to ensure there is ample time on the bus for multiple devices' transmissions. While one device operates correctly on the bus, connecting a new device could potentially disrupt its operation, causing it to either malfunction or cease functioning altogether. I've added a few debug messages that I can monitor over UART (CLI_write()).

When a device stops working, it appears to freeze—there's a halt in both its operation and the transmission of data over UART. When monitoring the device's boot-up process in situations where it's not working, it freezes randomly. No error messages are displayed, and it seems that all initial tasks are executed successfully up to the point where it freezes.

Upon repeatedly attempting to power cycle the problematic device, there are instances where it boots up successfully, starts transmitting data, but the previously connected device stops working. This behavior seems somewhat random and gives the impression of a problem with receiving CAN messages, as if some error is occurring but not being reported.

Could you please confirm if you've successfully operated multiple IWR6843AOP devices (e.g., EVM) on a common CAN bus?

Thank you,

Adam

One more discovery: in an attempt to disable the callback for CAN message reception, I utilized the following MCAN configuration:

mcanCfgParams->errInterruptEnable = 0U;

mcanCfgParams->dataInterruptEnable = 0U;

Now, multiple devices are operating correctly, and I'm successfully receiving messages from more than one device.

While I'm not entirely certain about the specific impact of disabling these interrupts (I may need them for communication with the device), it could aid in isolating the problem. Debugging these sections using a probe might prove beneficial.

At the very least, I am currently able to receive messages from multiple devices.

Adam

Hey Adam,

Thank you for updating this post with your observations and discoveries; its very helpful for others in the same boat. I have not personally tested multiple IWR6843AOP devices on a CAN bus, but I will look internally to see if this has been tested before. Did the changes you incorporated fully resolve the issue or do you need additional support?

Regards,

Kristien

Hi Kristien,

They did resolve my issue; however, it came at the cost of not being able to receive a message over CAN, I suppose. I can use it this way for now, but it could be limiting for my future intentions.

I would appreciate it if someone from your team could debug this part of the code. Perhaps it's just a minor issue. I don't have a debug probe, and somehow, I'm unable to pinpoint the problem exactly using custom debug messages.

Thank you for your help,

Adam

Hey Adam,

Unfortunately, I have not been able to track down anyone who has tested multiple IWR6843AOPs on a CAN bus. For now, I can continue to try and support you on the software side. You mentioned previously that you were able to receive messages with the data and error/status interrupts disabled, but now you are unable to receive them. What changed to cause this new behavior or was it not tested enough on your end? Were you originally using interrupts to verify data was received? 

Regards,

Kristien

Hi Kristien,

I have successfully resolved the issue, and I can now receive data over CAN on the SK-AM68 side. The problem mentioned earlier was resolved by disabling error and data interrupts. As a result, I am now receiving point cloud data from multiple IWR devices.

However, I am encountering difficulties using the CAN interface to communicate with IWR devices for tasks such as configuration. Although I haven't conducted extensive testing, I believe it might be simpler to use the debug probe for finding this bug.

If someone from your team could confirm whether a sensor continues to send data over CAN even after another device sends a message on the same bus (e.g. simly using cansend can0 123#1122334455667788), it would help me determine whether the bug emerged during my firmware modifications or if it was present in the original version.

Thank you for your assistance.

Regards,

Adam

Hey Adam,

Thank you for debugging this on your side. Are you able to verify if these issues are linked to arbitration message priority instead? 

Regards,

Kristien