Hi Brett,

This is only a comment !!!!

I remember in my last job with body/hvac/pod/ecm computers we implemented a message feedback strategy, it means.., if your bus class2/can/lin/keyword suffer a short to battery, short to ground suddenly or exists high demand, we use a logic to detect which message physical/functional was lost and we need to recover immediately.

For us the problem was not see DTC set for every conexion, the real problem is the lost of messages.

Best Regards

Jorge

Stahlman Brett <b...@siemens.com> wrote:

Hello all,

I don't know whether this is a problem or not. During testing of our product, it was noticed that certain bus fault scenarios (e.g., CANH shorted to battery) didn't lead to BusOff. (This was noticed because our diagnostic strategy will set a fault only if MSCAN cell goes BusOff - i.e., TxErr > 256.)

The situation is as follows:
Using a MSCAN controller on the HC12 DP256 (STAR12)
Bus speed 500 kbs
Only one other node on the bus (Vector CANalyzer using CANCARDX)

What happens:
Generally, when the CANH pin is shorted high, RxErr count rises quickly to over 128, putting us (and the other node) into the "Error Passive" state, but not BusOff, since TxErr generally latches at a value well below 128. I know that TxErr is not supposed to increment when we are "Error Passive" and no one else is on the bus. However, in this case, there is someone else on the bus. Even after we go "Error Passive," the other node has not gone BusOff; however, it is "Error Passive" as well. Perhaps that is why TxErr doesn't continue incrementing? If so, the problem is that RxErr gets to 128 before TxErr does. Here is my theory as to how that is happening:

In the case of CANH shorted to battery, CANH signal stays dominant too long after the SOF. This corresponds to a message with 1st few bits of CAN Identifier == 0; i.e., a relatively high priority message. Thus, in many cases we assume we've lost arbitration and switch over to receiver *before* detecting any error. Thus, the eventual error is counted as a receive error, even though we originated the message. Does this make sense? Can anyone offer another explanation?

Thanks in advance,
Brett Stahlman

..........................................................

Mit freundlichem Gru/ Kind regards

Brett Stahlman

Senior Software Engineer

Siemens VDO Automotive AG

SV C BC

100 Electronics Blvd #240001

Huntsville, AL 35824-6401

The United States of America

Tel. 001.256.464.2227

Fax 001.256.464.2786

E-Mail: b...@siemens.com

Internet: http://www.siemensvdo.com

Yahoo! Mail
Stay connected, organized, and protected. Take the tour

Hello all,

I don't know whether this is a problem or not. During testing of our product, it was noticed that certain bus fault scenarios (e.g., CANH shorted to battery) didn't lead to BusOff. (This was noticed because our diagnostic strategy will set a fault only if MSCAN cell goes BusOff - i.e., TxErr > 256.)

The situation is as follows:
Using a MSCAN controller on the HC12 DP256 (STAR12)
Bus speed 500 kbs
Only one other node on the bus (Vector CANalyzer using CANCARDX)

What happens:
Generally, when the CANH pin is shorted high, RxErr count rises quickly to over 128, putting us (and the other node) into the "Error Passive" state, but not BusOff, since TxErr generally latches at a value well below 128. I know that TxErr is not supposed to increment when we are "Error Passive" and no one else is on the bus. However, in this case, there is someone else on the bus. Even after we go "Error Passive," the other node has not gone BusOff; however, it is "Error Passive" as well. Perhaps that is why TxErr doesn't continue incrementing? If so, the problem is that RxErr gets to 128 before TxErr does. Here is my theory as to how that is happening:

In the case of CANH shorted to battery, CANH signal stays dominant too long after the SOF. This corresponds to a message with 1st few bits of CAN Identifier == 0; i.e., a relatively high priority message. Thus, in many cases we assume we've lost arbitration and switch over to receiver *before* detecting any error. Thus, the eventual error is counted as a receive error, even though we originated the message. Does this make sense? Can anyone offer another explanation?

Thanks in advance,
Brett Stahlman

..........................................................

Mit freundlichem Gru/ Kind regards

Brett Stahlman

Senior Software Engineer

Siemens VDO Automotive AG

SV C BC

100 Electronics Blvd #240001

Huntsville, AL 35824-6401

The United States of America

Tel. 001.256.464.2227

Fax 001.256.464.2786

E-Mail: b...@siemens.com

Internet: http://www.siemensvdo.com