TM4C129XNCZAD: CAN transmitter error

What error code is set in LEC of the TM4C129?

Good question.  There's some interesting wording in the datasheet: 

"The LEC field holds the code that indicates the type of the last error to occur on the CAN bus. This
field is cleared when a message has been transferred (reception or transmission) without error. The
unused error code 0x7 may be written by the CPU to manually set this field to an invalid error so
that it can be checked for a change later."

In my example above, the left packet has an error and the right packet transmits without error.  Does the bold statement mean I have to check LEC before the packet on the right transmits?  That implies I need to set an interrupt on LEC to check this. 

WIth the name Last Error Code it seems the error would be static until it is read and overwritten with 0x7. 

As an example your register list in shows a LEC value of 0x5.  Was that captured on an interrupt? 

Looks like it is time to drag out the debugger! 

Yes, it requires enabling the CAN status interrupt and checking the LEC on a status change. 

Looking at your logic analyzer pictures it looks like the ACK from TCU is arriving too late to the SPG. The SPG would thne see it as a form error. This is the worst case timing path because the delay is doubled. The delay from SPG to TCU on the start of frame, accumulated error due to frequency difference and then the delay from the TCU back to the SPG for the acknowledge. Is your bus over 30 meters long? 

Thanks. 

I'm seeing this on a 20 m, 25 m, and 30 m bus that is point to point between the two devices.  I have the control register set for a long delay (15 quanta/bit, TSeg1, TSeg2, SJW = 13, 1, 1 (register values+1)).  By my calculations that puts the earliest sample point at 800 ns.  Worst case the total delay through the transceivers and down the bus is under 660 ns (my 100 ohm transmission lines are slower than 5 ns/m).  I should have over 140 ns margin but the performance is still intermittent as shown. 

How much more delay is added within the TM4C129XNCZAD and LM3S2793 parts?  I tried to quantify by sending a single dominant bit and expecting an active error frame 6 bit times later plus the internal delay, but I could not get consistent results (I'm expecting the the peripheral settings were disturbing this test).  This technique is described on p.9 of the Bosch PDF titled "The Configuration of the CAN Bit Timing". 

If worst case through the transceivers and down the bus is 660nS, then for the acknowledge bit the worst delay is 1320nS. The receiver timing is off from the transmitter timing by 660nS (time for start of frame to get to the receiver) and another 660nS for the acknowledge signal to get back to the transmitter. There is a clock synchronization delay on the receive pin of both the TM4C and the LM3S.  It is one system clock period.

Sorry, loop timing is under 660 ns, so 320 ns each way down the bus.  This is shown as the time delay from RxTCU to RxSPG or vice versa (minus one pass through the HVD230 receiver, ~44 ns).  . 

One system clock means I add 29 ns (1/120 MHz  + 1/50 MHz).  I should still have good margin. 

Which device (TM4C129 or LM3S) is SPG and which is TCU? From your logic analyzer shot it looks like the acknowledge from TCU is arriving at SPG about 60% into the acknowledge window. Do you ever get errors when TCU is transmitting and SPG is sending the acknowledge?

Yes, the TM4C129 is at the SPG end.  60% is correct, that is why I have the CANBIT parameters set so high (15 quanta/bit, TSeg1, TSeg2, SJW = 13, 1, 1 (register values+1)) so I'll sample at 80%.  I'm not sure if I have errors from the Stellaris end too yet.  The TM4C129 occasionally gets enough errors that it can take the transmitter off the bus, so that is where I'm concentrating my effort. 

Can you provide a screenshot showing the CAN registers of the TM4C129 after configuration?

Unfortunately this issue got bumped in priority so I won't be back to this for a while.  I can start a new thread when I have more data.  Thanks for all your help.