Software-Injected CAN frames?

[bienieck]

---

@Hooovahh wrote:

And if you aren't talking to anything...what's the point of a communication bus?

---

The case might be to test the communication bus itself, and actually, this is my case. So, let's say I want to test if my DUT is communicating via the CAN bus. Let's say the communication test fails. Now, what is the real problem, the CAN bus itself or perhaps the microcontroller? I don't want to report microcontroller issues if there is a bus issue.

I don't know if I can use echo to test the bus itself. Does anyone have any thoughts?

[Hooovahh]

If you want to test the functionality of a CAN transmitting device, without any other device on the bus, you can still do this.  When you send the CAN message you need to enable Single-shot mode.  This will send the message once, and only once.  Normally if a CAN message goes out and there is no ACK from any other device on the bus, then the message will go out again and again until there is a response.  But Single-shot will send the frame once, and that's it regardless if there is a device that responds or not.  You can then put the bus on an oscilloscope and see if it was what you expect.

I'm unsure if an echo'ed frame will come back, if it was for a Single-shot, and there was no node to ACK for it.  But honestly in the past when I've needed to test the CAN bus, I would put a node out there to read the bus, and see if the expected data could be read.  Maybe the device has an input, and that value is put on the bus.  So change the input and see if the value changes.  Maybe it has a temperature probe, so provide a changing input to the temperature and see if the message changes on the CAN bus.

I get that you are concerned that if your CAN bus reading device breaks, then your tester will not work right.  But this is true of all DAQ devices.  If the DAQ device breaks so does your ability to test the DUT.  Besides as a customer I'd feel more confident knowing that the CAN bus worked talking to an actual thing, rather than some kind of simulated communication and then rely on some other interpretation of the bus.

[bienieck]

---

@Hooovahh wrote:

I get that you are concerned that if your CAN bus reading device breaks, then your tester will not work right.  But this is true of all DAQ devices.  If the DAQ device breaks so does your ability to test the DUT.  Besides as a customer I'd feel more confident knowing that the CAN bus worked talking to an actual thing, rather than some kind of simulated communication and then rely on some other interpretation of the bus.

---

The idea is to distinguish between different fails root causes. This will speed up the work of the team responsible for the investigation of the failed device. And also fails reports will be more precise (and this will also speed up production improvement).

Anyway, I will try a single shot with echo. By looking at PCAN Basic driver help it is doable.

EDIT:

Unfortunately there is no single-shot in PCAN (or at least I can't find this mode). There is a possibility to configure a delay between frames so perhaps if I set some big delay I will be able to read back echo without too much traffic on the bus (caused by lack of ACK).

[Hooovahh]

---

@bienieck wrote:

---

---

The idea is to distinguish between different fails root causes. This will speed up the work of the team responsible for the investigation of the failed device. And also fails reports will be more precise (and this will also speed up production improvement).

---

If the software is unit tested and validated on the microcontroller, I'd think the only failure mode is a bad CAN transceiver which is extremely unlikely as these chips have been in production for several decades with real low PPM.  Or a bad connection on the newly fabbed board that it is used on.  A bed of nails tester can verify the connection properly, but since CAN basically works or it doesn't, a non-working communication to me is a poor connection to the board, or failed board itself.  

It looks like PCAN hardware does support Single-shot based on what I've seen.  No idea if the drivers expose that.

[bienieck]

---

@Hooovahh wrote:

If the software is unit tested and validated on the microcontroller, I'd think the only failure mode is a bad CAN transceiver which is extremely unlikely as these chips have been in production for several decades with real low PPM.  Or a bad connection on the newly fabbed board that it is used on.  A bed of nails tester can verify the connection properly, but since CAN basically works or it doesn't, a non-working communication to me is a poor connection to the board, or failed board itself.  

---

Good point.

---

@Hooovahh wrote:

It looks like PCAN hardware does support Single-shot based on what I've seen.  No idea if the drivers expose that.

---

I use free PCAN Basic driver and only paid version expose single-shot: CAN-API Comparison: PEAK-System. Perhaps I need to invest.