Why does it keep sensing the same frame endlessly o error or NAK?

candle-usb / candleLight_fw

gs_usb compatible firmware for candleLight, cantact and canable

Other

662 stars 292 forks source link

Why does it keep sensing the same frame endlessly o error or NAK? #185

Closed deividAlfa closed 3 months ago

deividAlfa commented 3 months ago

Using latest canable fw on a UCAN board (stm32f072). I attached a logic analyzer so I can see what's going on.

I turn the device up with sudo ip link set can0 up type can bitrate 500000.

When I send any frame, for example cansend can0 123#aaaa5555, it keeps sending this frame forever, with a gap of 22us between them, why? Shouldn't it just report NAK or ERROR and stop?

Another strange thing is the first 16 frames end with "ERROR", then it's all NACKs.

This happens always, and doesn't matter if it's connected to something else or not.

Once this happens, I can't send anything else or stop it. It'll stop with sudo ip link set can0 down but will inmediately continue sending the frames again when turning it back on. I have to physically disconnect it to stop it.

I'm a bit lost, I'm trying to talk to a standalone CAN device, just the canable and the device, nothing else, maybe I'm doing something wrong?

Thanks, David

marckleinebudde commented 3 months ago

You need a 2nd CAN station on the bus, with the same bit rate configuration. The bus must be properly terminated. The sending station is repeating the CAN frame until someone ACKs it.

fenugrec commented 3 months ago

+1 to what Marc said. As for the device resuming its attempts after being brought down then up again, that is tracked already by #137

deividAlfa commented 3 months ago

Thanks for answering.

The UCAN board has a 120R termination, the wire length to the other device is about 10cm, the can signals are sharp and clean (Also checked with a scope). Tried with another 120R resistor at the other side, no difference.

So what if you send a frame to a non-existant device? The device locks up sending the same frame, end of the story? Is this how CAN is supposed to work? Doesn't look to me, it may retry n times, but then give up and return some failure code, instead saturating the bus forever?

I don't know the device address and I'm trying to figure it out, I wanted to perform an address scan, which should took little time at 500Kbit, but either this is not possible in CAN, or this "keep sending forever" frame management is making it very hard.

I'm not very familiar with can, but a lot more with other buses like I2C, I expected getting a NAK, then keep sending new frames with different addresses until something ACK'ed.

But still, shouldn't it always NAK? Why getting error exactly on the 16 first frames and not always?

Sorry if this is a very basic issue!

marckleinebudde commented 3 months ago

Yes, CAN is supposed to retry to send the CAN frame until someone ACKs it.

deividAlfa commented 3 months ago

Ok, so for this functionality the only way is to use a custom fw? Is there anything that can discover can devices by actively querying the bus?

Thanks!

fenugrec commented 3 months ago

Ok, so for this functionality the only way is to use a custom fw?

no, your first step is to set the same bitrate as your device, and make sure it's ACK'ing frames, regardless of what you put in them. AFAIK, most/all CAN devices always ACK frames if they're active, regardless of the frame contents, so it would not be a valid method for bus / node scanning anyway.

is there anything that can discover can devices by actively querying the bus?

that is one layer above raw can frames, and thus getting out of scope for this discussion. You need to find out what protocol your device uses and work at that level, e.g. iso-tp / UDS/ CanOPEN / etc.

deividAlfa commented 3 months ago

But they wouldn't ack if not matching their ID, right? That's exactly what I'm talking about, simply sending a random packet to different addresses until something acks.

fenugrec commented 3 months ago

they wouldn't ack if not matching their ID, right?

Wrong. You're giving more meaning to the ID field that CAN itself specifies; I suggest you read up more on the subject.

simply sending a random packet to different addresses

CAN has no notion of addresses, sender/receiver, etc. Hence why protocols are almost always used on top of it. If your device has a standardized CAN-based protocol then the ID field may have the sort of meaning you expect, but as I said that is not part of the basic CAN functionality, and would have no effect on the ACK/NACK behaviour.