Hi, this is my first post and I have some questions that have been bothering me. I have a Vector and one ECU (random ecu does not matter). In my configuration the vector is set to send a request to the ECU and after that to destroy all the responses of this ECU for a specified period (under and over the timeout of the ECU). From what I can understand, if there is no ACK from the Vector for the responses of the ECU (ACK Errors) the ECU will increment the TX error counter until  128 and then stop incrementing because in my configuration the ECU should not reach busoff and just keep sending responses( I'm not really sure about this maybe someone can explain if it reaches or not).

With this configuration and different ecu's I have different cases of results:

1. If I stop the disturbance before the ECU timeout, it sends the response ( expected result)

2. If I stop the disturbance after the ECU timeout time it does not send the response( expected result)

3. after 16 error frames, the ECU stops sending anything and does not send the expected response even if I stop the disturbance ( can't explain why)

4. I can see the error frames for all the period of the disturbance but if I stop it before timeout I can't see any response from the ecu ( can't explain why)

5. I see the busoff in the results window, but when I stop the disturbance the ECU still sends the correct response although it should not ( maybe buffer but how does the buffer know that I stopped the disturbance???? )

Could someone with more experience maybe enlighten me with some of the issues of this post?

Can a ECU reach busoff if it does not get any ACK from the network? Why does it respond ok sometimes when I stop the disturbance and sometimes it does not ( take into consideration that I'm talking about different ECU's ). How does the buffer work for ECU's because in some cases I think the response is stored in the buffer but how does the buffer actually know when I stoped the disturbance and sends the response?

I don't know if I'm clear enough but you can ask me anything and i'll try to send a response asap.

Thank you  

I can't say that we'll be able help solve your problem, or even suggest a reasonable path to diagnosing the problem described. However, I think that you need to provide a bit more information before you can expect a reasonable suggestion/answer from the board. For example, (1) what is the communications bus physical layer interface that you are using, and (2) what is the link/network layer protocol expected on the bus you are using?

I'm using a CAN HS bus with 500kbps. I don't understand the second question maybe you can elaborate?

IOWs, are you using DeviceNet, CAN-Open, CAN Kingdom, or any such higher level protocol?

BTW. what CAN transceiver does your implementation use?

The can transceiver is not relevant, because I use different ECU's for this tests, this being a diagnostic test with the purpose to check if the ECU respects the timeout. I'm using a Vector Canalyzer so I think it's Can-Open protocol. That is what I can't actually determine, why are ECU's acting different. The normal behavior would be receive request, try to send response for 1000ms ( ECU timeout) and no busoff because from what I know you can't reach busoff only for ACK errors(Bosch can specification). The test is simple. Send request, start disturbance with canalyzer, stop disturbance after 950 ms to see if the ECU still responds in timeout and the second test is send request, start disturbance, stop disturbance after 1050ms to see if ECU aborts communication after 1000ms timeout. The issue is that I see the different behaviours described in my first post and I can't understand why.

Does "disturbance" mean that you simply don't respond to a request, or do you actively interfere with bus activity?

If the disturbance is the temporary absence of any participating node or nodes on the bus other than the ECU, then I completely agree with your comment about not going bus off.

However, in case 5 in your original post you mention seeing bus off, which implies more is going on than simply forcing the intended destination node or nodes to stay passive for some time period to create missing acknowledgements.

If your test can create a bus off condition, it isn't too amazing to see some variation in the way these different ECUs respond to your test, particularly if the ECUs have different CAN controller hardware and software.

The disturbance is a short between CANH and CANL so there should be no ACK, that is why I can't understand the busoff from case 5. As an unrelated question, does anyone know if the test tools(canalyzer,canoe, etc etc) can actually reach busoff themselves?

I am at risk of telling you more than I absolutely know, but I think you are getting transmit errors with CANH/L shorted that you would not see with a normally terminated bus and no responding receivers. I believe the can controller expects to see its own transmission on the RX input when transmitting. Shorting CANH/L prevents it from driving/receiving a dominant level, this produces transmit errors other than the absence of an acknowledgement, which will in turn increment the transmit error counter and eventually the controller goes bus off.

I have not gone back and taken a detailed look at the CAN specification to understand transmit error detection and count control in detail, but the fact that you're seeing bus off suggests that something like this is going on. Under these conditions the real time behavior of different ECUs with different hardware and/or software could vary, the largest source of variation probably having to do with how reinitialization is handled in software to clear bus off. You may even see different behaviors from the same ECU by repeating the test many times.

I understand your point of view but I have another problem. Disregarding the fact that only one time I managed to see a clear busoff from hundreds of tests, in other cases I can never actually see a busoff just weird behavior, in the case that shows busoff, the ECU should delete all previous request info and after busoff recovery just stay idle until the next request. In my case, I can see the busoff recovery is made, the TX counter goes back to 127 the ECU stays idle and no errors can be seen during the short and after I stop the short and restore the bus, the ECU responds correctly with the answer TO THE INITIAL REQUEST. This behavior takes me to the idea that this is not actually a busoff and it's just some kind of reading error from the tool or, as I specified in my first post, maybe the buffer keeps the info and it's not deleted but then to my other question, how does the buffer know that I stoped the short and sends the info in under a millisecond?