0
\$\begingroup\$

I am trying to work with a Microchip MCP2515 CAN Controller (16 MHz oscillator) alongside a MCP2551/61 CAN transceiver. I have been successful trying to setup the device via SPI, but I am unable to send/receive CAN frames (trying to send throws a large count of error frames, increasing the register error counter and making the interface go error-passive and bus-off).

I suspect the reason of these errors is the bit-timing although I am not so sure about it.

Does the CAN bit timing for each device affect only receiving, or both receiving and transmitting?

Enter image description here

In this case, does the sampling point, phase segment 1 and phase segment 2 affect during sending?

Update: I just figured out why the controller was not working... The MCP2551 transceiver was dead... I replaced it, and it worked all of a sudden.

\$\endgroup\$
  • 1
    \$\begingroup\$ It's different from controller to controller. I don't know this one so I'll refrain from answer, but some controllers have a tight coupling between how you set the tq segements and what baudrate you get. I would recommend to download the CANopen spec "CiA 301" and check the sample point recommendations there. Regardless of if you are using CANopen or not, this is a good industry standard for all CAN bus use. Table 1 contains recommendations, recommended sample point position is at 87.5% from the total bit size. \$\endgroup\$ – Lundin Dec 4 '18 at 7:50
  • \$\begingroup\$ Do you have another device on the bus to receive the frames? If you only have one device and you do not disable ACK errors (not sure if MCP2515 can do this) your own device will generate the error frames each time the ACK is missing until it goes error_passive. \$\endgroup\$ – Jon Dec 4 '18 at 15:58
  • \$\begingroup\$ Watch youtu.be/3lkfK2-BUno followed by youtu.be/se204xfyb4g I would jack up the SJW to 4, this may help. \$\endgroup\$ – vini_i Dec 4 '18 at 16:37
  • \$\begingroup\$ @vini_i You only need to adjust SJW when running the highest baudrate, if at all. And then to 2. Setting it to 4 sounds very much wrong - the need for doing so indicates the presence of larger problems, such as for example hobbyist RC oscillator instead of the necessary crystal oscillator in a CAN bus application. \$\endgroup\$ – Lundin Dec 5 '18 at 10:12
  • \$\begingroup\$ @Lundin Why only at the highest baud rate? The OP does not mention what type of CAN bus the device is connecting to. If the bust is entirely set up by the OP, then I agree, there are other underlying issues. If the OP is trying to connect to an existing bus that is already running there is no issue with having a wide SJW. This is mostly because with an existing bus you would not know how good the clocks are and it would be best to compensate for the worst. \$\endgroup\$ – vini_i Dec 5 '18 at 10:23
2
\$\begingroup\$

With CAN, the timing scheme is important for both transmitting and receiving.

During the arbitration, everyone is transmitting and receiving at the same time. This is to figure out who has the lowest address. Every node writes a bit to the bus and reads that bit at the same time. If node 1 writes a recessive bit and node 2 writes a dominant bit, node 1 will read that the bus is dominant and stop transmitting. This is because a dominant bit will overwrite a recessive bit and as soon as a node sees that its recessive bit has been overwritten it know that it does not have priority and stops transmitting.

Now imagine the worst case scenario. Node 1 is on one side of the bus and node 2 is on the other. Do to propagation delay the leading edge of the bit takes time to travel from one side of the bus to the other. This worse case is where node 1 issues the SOF (start of frame) which takes time to travel from one side to the other. Then when the arbitration starts the bit edge from node 2 has to travel from the other side of the bus back to node 1. This actually gives a delay of two bus lengths that need to be compensated for.

Without knowing the exact setup of your bus it is difficult to say exactly what is going wrong. That being said I would suggest increasing propagation delay to 3, leave phase 1 at 8, decrease phase 2 to 4 and increase the SJW to 4.

62.5% is kind of early to sample. 70% to 80% tends to be more realistic. The suggested setting I have given here is 75%. Also widening the SJW will give the module more leeway in adjusting where the sampling point is. Every time the bus resyncs (at least once every 10 bits) the SJW allows the sampling point to move in compensation to where the rising edge of a dominant bit falls. This can help with a jittery or leading/lagging clock.

\$\endgroup\$
  • \$\begingroup\$ The solution to having a bad clock is to fix the clock. You can't run CAN bus with crappy clock sources. The recommended sampling point is 87.5% on all baudrates, as specified by CAN in Automation. What's your source for "The suggested settings are 75%", some random Youtube person? \$\endgroup\$ – Lundin Dec 5 '18 at 10:19
  • \$\begingroup\$ @Lundin No, experience with the bus. With the OPs current setup of 16TQ my recommendation pushes the sampling point as far back as possible while maximizing the SJW. With the maximum SJW the controller then can adjust for the optimal sampling point. \$\endgroup\$ – vini_i Dec 5 '18 at 10:28
  • \$\begingroup\$ @Lundin Although the OP does not mention what is making the clock, I would agree, mentioning that a good crystal is needed to run CAN is required is a good idea. \$\endgroup\$ – vini_i Dec 5 '18 at 10:31
  • \$\begingroup\$ So you set the sample point too early like 70% and then compensate for this by increasing SJW? Don't do that, put the sample point in the correct location instead. Follow industry standards instead of cooking up something of your own. \$\endgroup\$ – Lundin Dec 5 '18 at 10:45
  • \$\begingroup\$ @Lundin The 87.5% sampling point is meant to compensate end nodes on a very long bus. If setting up a bus that is 12 inches long the sampling point could be at 50% and the bus will run just fine. If connecting to someone else's bus of unknown length and setup then maximize your chances. If you were connecting to an unknown bus and "industry standards" didn't work would you throw up your hands and say "the standards don't work so there is nothing I can do"? \$\endgroup\$ – vini_i Dec 5 '18 at 11:06
3
\$\begingroup\$

The bit timing is important for both sender and receiver: each sender also samples the bus while transmitting.

For example during the arbitration phase, it needs to know if a higher priority message is also being transmitted and that it should therefore drop it's transmission.

Also, at the end of the message, it needs to check the ACK bit.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.