False zero id packets

[ArosPrince]

Hello Collin,
I've been trying your library. First, let me say, it looks great, good work on that one.

I am however facing a strange issue. Sometimes after calling Can0.read(in), the id member of the structure is set to zero although I am quite sure the the ID is something like 0x5FE. This is a CANOpen node and an SDO response. Most of the times, the id is filled in correctly but sometimes, there is just zero. And no, it's not NMT signal or anything. I can read the rest of the packet and the content is OK, only the id is filled in incorrectly.

Any idea?

I don't use any filter I just read the packets like this:

if (can.available()){
	can.read(incoming);
	...
}

Also might be worth mentioning... I use 5V transciever, not 3.3V because I couln't get one anywhere. I have connected some resistors to make it 3.3V and it seems to work. This may not be relevant at all, I just thought you should know.

Thanks...

[collin80]

I have seen that happen from time to time. I'm not entirely sure why. It seems like it could be due to communication issues - bad transceiver, poor termination, etc. But, I'm not totally sure. If you notice a pattern I'd be interested to hear about it.

[ArosPrince]

Hi,
I have borrowed a CAN analyzer and solved the problem. It has probably something to do with uninitialized memory. The thing is that sometimes, CAN extended packet was sent instead of the normal packet. In this case, the device also responds with CAN extended packet and this extended packet is (for whatever the reason) assigned zero ID. The content of the packet is correct as I said in the initial post.

Now, I though that the CAN_FRAME structure is initialized automatically, but now I had a look and of course it is just a C structure... No constructor there :-( So in my case the problem was dependent on what was on the stack before calling the function that sends the packet... How simple :-)

Anyway, why in such a cases does your library not detect correct ID, that I do not know. I thought that both extended and short CAN messages are supported.

However my solution is simple, I will simply use only standard id size (11 bit).

[coryjfowler]

Aha! This is exactly what brought me here. I have concerns about the baudrate calculation... What is the desired sample point bit time percentage when calculating the Prop, PS1 and PS2 segments? Is there a target value I am missing when I glanced over the section before heading here to see if there was an active issue? I have a very repeatable bench setup for this issue right now and my suspicions are at the signal sample point which I prefer to be greater than 75%. I have a PCAN-USB dongle sending 0x10 as an extended frame which is being received as 0x0 by the Due at a 250k baud.