Why does it keep sensing the same frame endlessly o error or NAK? about candlelight_fw HOT 8 CLOSED

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.

from candlelight_fw.

+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

from candlelight_fw.

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!

from candlelight_fw.

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

from candlelight_fw.

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!

from candlelight_fw.

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.

from candlelight_fw.

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.

from candlelight_fw.

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.

from candlelight_fw.