TCAN4550-Q1: Problem programming error counting

Edwin,

Thanks for bringing this question to E2E, it is strange that the error counters aren't incrementing when the data rate is different from what is expected. I would expect some bit rate errors or maybe even an ACK error since the controller would be expecting the ACK at a different time than when the ACK occurred. Since there is no explicit "data rate error" in the CAN protocol, and the data rates are multiples of each other, it may be getting by with no perceived errors, but not receiving the message because the frame is longer than expected. 

When you say you don't receive packets, does the transmitter continue to transmit the full frame and it is not received? Or does the frame stop mid-communication?

I'd also like for you to read register 0x0820 to see if any interrupts are getting thrown at all.

Regards,

I have the TCAN4550 listening in monitor mode to a bus with a transmitter sending at 250kbps standard that also has a receiver which is supplying ACKs.

For this case I am receiving correct packets and register 0x0820 returns 0x00000082.  How do I clear these bits?  Also 0x1044 returns 0x000008.

If I change the TCAN4550 receive rate to 125kbps, I receive no data (the FIFO is empty) and 0x0820 changes to 0x00000000.  Also 0x1044 changes to 0x00000A then 0x000049 then 0x000069.  It appears I can detect the error here.

If I change the TCAN4550 receive rate back to 250kbps, I receive data correctly and 0x0820 changes to 0x00000082.

If I disconnect the TCAN4550 from this bus, register 0x0820 changes to 0x000000A2, then 0x000000A0.

If I reconnect the TCAN4550 to this bus, and set it to 250kbps, register 0x0820 remains at 0x000000A2.  I still receive packet correctly.

In all cases, register 0x1040 returns 0x00000000.

Edwin,

Thanks for all of the information, I'll have a response for you tomorrow. Thank you for your patience.

Regards,

Edwin,

To answer your question about clearing the interrupt flags in register 0x0820, since these are triggered by interrupts in the MCAN interrupt register, you'll have to clear those. The interrupts getting asserted in 0x0820 are Global error and MCAN_INT, meaning that an interrupt is present (Global error) and it's an MCAN interrupt. The MCAN interrupts can be read from register 0x0824, but they are cleared by writing a 1 to the specific interrupt in register 0x1050. 

Now for the register contents in the "good" and "bad" cases:

Good case

0x0820 - 0x00000082 - MCAN_INT, Global error

This makes sense to me, I'd assume the interrupt getting thrown in the MCAN interrupt register (0x0824 or 0x1050) is the notification of receiving a message.

0x1044 - 0x00000008 - ESI bit set

The ESI bit in the CAN frame indicates the error state of the node. If it is set to 1, it usually means that the node is in error passive, but this case only occurs when the TEC or REC have been incremented past their threshold levels. However, there are cases where the ESI bit can be transmitted as recessive and still be in error active mode. Since it looks like the ESI bit is always set in this node, I would say the latter is happening.

125kbps case

0x0820 - 0x00000000

Since the data rate error will show up as a protocol error, I wouldn't expect any of the interrupts in register 0x0820 to be asserted, so this makes sense.

0x1044 - 0x00000A00 - ESI bit set, Form error detected

    - 0x00004900 - protocol exception event occurred, ESI bit set, stuff error detected

    - 0x00006900 - protocol exception event occurred, FD frame received, ESI bit set, stuff error detected

In this case, the form error is the result of the data rate being different than expected. Once the node detects this error, it will transmit its own error active flag, which is 6 consecutive dominant bits. Because of this, it will then detect a stuff error (stuff bit not in place), which is why that is being detected as well. The protocol exception event is the result of the frame being an FD frame, but the res bit being recessive. I'm not sure how this points to anything with the data rate changing, but it's interesting that it gets thrown only in that case. Also, these are all persisting through consecutive reads because they aren't being cleared.

The cases where 0x0820 0x000000A2 and 0x000000A0 are the same as the good case, except CANSLNT is likely being asserted because the bus is idle for longer than tSilence.

The TEC and REC timers can't be cleared unless a power cycle occurs. These values are either incremented for a protocol error, or decremented for a correctly received/transmitted CAN frame. It could be possible that it is decrementing back to 0 before you read it, but I'm not sure that makes sense if you are reading it while receiving the incorrect data rate. If you aren't already doing this, can you read register 0x1040 before and after every received CAN frame?

Regards,

I cannot read 0x1040 before and after received frames when the data rates mismatch since there are not received frames.  The FIFO is empty.  Do you expect in this case that I should be receiving frames with an error indication of some sort?

Register 0x1040 is always reporting 0.  I poll it frequently.  I would expect to see at least the CEL field increment to maximum.  There should be no good packets received when the data rate is mismatched, so the TEC and REC fields should not be zero either.  Can you duplicate my results or figure out if some additional configuration setting is needed to make this work?

Also you raise another question for me.  You said that when the form error is detected, the node will transmit an error active flag.  Please remember I have set the node to monitor mode, so I really don't want it to place any dominant bits on the bus.  Can you verify that it will not if it is in monitor mode?  I don't think it is doing this because my receiver on the bus is not logging any errors, which I would expect it to see if the node places 6 dominant bits at the wrong data rate.

Edwin

Edwin,

No, I was meaning for you to poll it, but you're already doing that.

And thanks for pointing that out, I read right over the monitoring configuration. In this case, the controller will still report the error frame to itself, but won't transmit it to the bus since it can't transmit any dominant bits in monitoring mode. Can you read register 0x1018 and let me know its contents? I'm curious if restricted mode is getting set, this would explain TEC and REC not incrementing.

Thanks for your patience in working through this.

Regards,