FlexCAN CRC Issue

[nhinshaw]

Hello, I was working on my K64F board, and noticed an oddity.  the other controllers on the network, using MSCan interfaces, werent picking up any of the traffic from my K64F.  I hooked into a logic analyzer and noticed that the CRC generated from the K64F was different than the CRC generated from a duplicate send from both a KE06Z and a Pcan module, both of which had the same message.  Attached is an image of the Logic analyzer tests.  Is there an issue with the CRC generation on the FlexCAN code, or did I just miss a register somewhere?  Any help would be appreciated.

-Nate Hinshaw

[nhinshaw]

Sure enough, the line i thought was calling the set was never getting called, i manually set the bit, and now my CRC checks out and my other controller accepts the message. Thanks for the help Earl. I will note, the error was in generated processor expert code, is there a place to report incorrectly generated code?

-Best

Nate Hinshaw

[nhinshaw]

I factored the logic analyzer out of the equation, and instead used my OScope, just to make sure that it wasnt introducing error.  Comparing against https://automotivetechis.files.wordpress.com/2012/06/extended_data_frame.jpg , the pcan and ke06Z seem to be sending the correct packet, however the k64F seems to be sending incorrect data, If you look at the logic analyzer images, the area in which they diverge happens after the first bit stuff, there is a 1low 3 high 1 low, then the k64f diverges into a different pattern than the ke06z board.  I suspect there is an error in the processor expert implementation in the k64f, as the code is the same on both boards.  The SRR, IDE, and RTR bits do all seem to be set correctly in either case.  this being, High SRR, High IDE, low RTR

[egoodii · Accepted solution]

Your previous information was:

CAN_PDD_EnableMessageBufferSRR(CAN0_BASE_PTR, BufferIdx, PDD_DISABLE); /* Clear SRR bit */

I cannot speak to any potential PE-based issues -- I use pure bare-metal.

Are you now retracting this indication?  Your original images clearly showed a line-bit-difference 'about 12 bits in', which is right where SRR happens to be.  Can you just change that above line to SET SRR and see what happens?

Can you dump the mailbox contents (just prior to the 'send enable' operation) onto this forum?

[nhinshaw]

Once i get back in tomorrow I'll see about finding that info, and will post what I find

[nhinshaw]

I dug into the generated code.  It has

	CAN_PDD_EnableMessageBufferRTR(CAN0_BASE_PTR, BufferIdx, PDD_DISABLE); /* Clear RTR bit */
	CAN_PDD_EnableMessageBufferSRR(CAN0_BASE_PTR, BufferIdx, PDD_DISABLE); /* Clear SRR bit */

in the function that is called on message write.  This would lead me to believe both bits are cleared

and CAN_PDD_EnableMessageBufferIDExt(CAN0_BASE_PTR, BufferIdx, PDD_ENABLE); /*Set ID extended */

sets the ID to extended, as that is what I am sending]

-Edit, it does change on extended frame

CAN_PDD_EnableMessageBufferSRR(CAN0_BASE_PTR, BufferIdx, PDD_ENABLE); /* Set SRR bit */

[egoodii]

Try with SRR set.

My Vector 'reference chart' says SRR will be recessive (1) for extended-ID messages.  My TX-prep code for the first MB word:

pFlexCANReg->MB[iTxMBNo].CS = FLEXCAN_MB_CS_CODE(FLEXCAN_MB_CODE_TX_INACTIVE)

          | FLEXCAN_MB_CS_SRR               //Always 'set' SRR

          | (bIDEin<<FLEXCAN_MB_CS_IDE_BIT_NO)

          | (bRTRin<<FLEXCAN_MB_CS_RTR_BIT_NO)

          | FLEXCAN_MB_CS_LENGTH(iNoBytes);

In any case, all we can say at this point is that some bit NOT shown by your logic analyzer is 'different', and the CRC is 'ok' because your receive-nodes ACK the message (so 'good' at the physical layer!) -- and this 'unseen content' is causing the message to be dropped, either directly by the receiver's message-filters, or by higher firmware layers.

Also, from a Kinetis Reference Manual:

[nhinshaw]

I am unsure what you are asking for, so I am unsure how to confirm, I do think those bits should be set correctly, as I did not see any settings for them in processor expert

[egoodii]

I am not a PE user, so I can't help there.  These two bits are part of the overall 32-bit CAN 'lead in', and their content, like all else, is part of the message buffer you fill:

First word, bits 22 and 20 respectively.  I assume IDE is already '0' for extended...

I might guess that if any of these three bits are 'nonzero' as received, that the destination 'stack' might just toss them.

[egoodii]

Sorry, SRR and IDE need to be '1' (been a while since I looked this close...).

[nhinshaw]

That is why i thought the issue odd; however From what codewarrior is telling me, there is no clock issue, as I also verified through my OScope, with a 4microsecond bit stuff timing that matches up with the 250kbit line.  In addition, the packet send with the incorrect CRC does get an Ack, which implies that it was recieved on the end im attempting to send it too.  In addition,

Im running the CAN at 250kbit with a 0% tolerance, which matches with the PCAN view, which lists my data packets as correct at the selected Baud.  the only different between the messages that are accepted by my controller and the ones that are not seem to be in the ACK value

[egoodii]

I'll take your statements to indicate a direct crystal reference for CAN, so we can believe the net bit accuracy (not just the calculated 'expected').

Can you confirm your stuffings for SRR and RTR?

[egoodii]

These are old, stable modules -- I do not see how the CRC itself can be wrong.  I might assume that 'some bit in the sequence' not seen by your decoding-device is 'different' (one of the 'reserved' bits). I note that while your reference startup message starts with 5/1/1/3/1/2... bit times, the K64F is 5/1/1/3/1/5...  Decodes to the same extended-ID, but different SRR (12th bit in)?

IF your other nodes are NAKing this message, it is much more likely that your source clock is not 'exact enough' (which might also explain a decode-difference in your 'scope shots?).