CAN baud rate settings selection

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The certain baud rate is achievable with more than one way. My question is what criteria (prescaler BRP, propagation time segment, phase segments 1 and 2) are more and what less important? So far I was able to reliably communicate via CAN with speed up to 500kbps. All my attempts to rich 1Mbps have failed. I was able to send/receive several frames with that speed but pretty soon connection was lost.
For testing I have 2 16MHz AT90CAN128 boards with the short (10sm) twisted pair and terminators on the both ends. My results show that when ratio CLKio/Fcan < 4 - expect troubles.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you read the BOSCH white paper on setting up CAN baud? Its not the easiest thing to use, but it has much better information than the data sheet. It also answers your question about what is important in the baud setup, although you need to read the whole thing because unfortunately it is not a simple single answer.

http://www.semiconductors.bosch....

When you initially connect at 1 Mbps have your software look at the CANREC and CANTEC error counters. As you send and receive CAN data you will probably see one, the other or both error counters keep incrementing which indicates an unhealthy CAN bus. Its the CANTEC error counter that will eventually force the node off the CAN bus when you have repeated Tx errors. Try checking the 500 Kbps connection also. Sometimes CAN will get data through an unhealthy bus via its automatic retries. The obvious conclusion is you do not really know how well it is working at 500 Kbps without checking these internal error counters or monitoring the CAN bus with an analyzer.

BTW, remember to keep the total number of Fcan (Tscl) Time Quanta in a bit time between 8 to 25.

You also have to choose an external crystal frequency that will give you an exact 1 Mbps baud rate. You cannot fudge CAN baud % error rates like UART baud % error rates.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FWIW I've been studying the MicroChip MCP2515 data sheet lately, and it seems to have a pretty clear description of CAN bit timing, and considerations for setting the control registers. Even if you don't plan to use the part, it might answer some of your bit timing questions. Twisted pair at 1 MHz seems a little high to me, but it ought to work on the test bench.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
All my attempts to rich 1Mbps have failed.

Let me expand this statement and add some new test data. I was able to talk at 1Mbps with the settings: CANBT1=0x00;CANBT2=0x0C;CANBT3=0x37.(page 264)
The next step was to use longer twisted wire. Still works. Some number of connectors was added. To make it work one terminator has been removed. Doubled up length and connectors. Now it does not work reliably. I have looked at the signals on the chip: the receiver gets the frame and ACKs, but often too late: the sender has already started retransmission.
At this point I tried to change CANBT2 and CANBT3(Tprs,Tph1,Tph2) to their extreme and medium points keeping Time Quanta = 16. No any difference. The same picture. Adding and removing terminators didn’t help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
CANBT1=0x00;CANBT2=0x0C;CANBT3=0x37

umm.... looks like 7+4+8 = 19 TQ to me.... but I did it quick so I may have my math wrong.

Quote:
To make it work one terminator has been removed.

So.... you are saying reflections help you? Better hang a scope on the line and check the signal quality. Working better with a terminator removed may be a red herring. What kind of error counts are you getting?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbc wrote:
What kind of error counts are you getting?

Quote:
I have looked at the signals on the chip: the receiver gets the frame and ACKs, but often too late: the sender has already started retransmission.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

brberie wrote:
dbc wrote:
What kind of error counts are you getting?

Quote:
I have looked at the signals on the chip: the receiver gets the frame and ACKs, but often too late: the sender has already started retransmission.

dbc, you'd better reference
https://www.avrfreaks.net/index.p...

theusch wrote:

Hold on, y'all--you just don't realize that there are two rules that govern discussions with brberie:

1) brberie is always 100% correct.
2) If you feel otherwise, see rule #1.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CANBT2=0x0C;CANBT3=0x37
PRS = 6; PHS1 = 3; PHS2 = 3; p.256
Tsyns = 1 (always)
Tquanta = Tsyns + (PRS+1) + (PHS1+1) + (PHS2+1) = 16
CANBT3 bit0 reflects number of samples, so phs2=3, but not 7.

Is my math correct, chimpanzLee? Your posts are always very informative and helpful, right on topic. Am I right again?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
CANBT3 bit0 reflects number of samples, so phs2=3, but not 7.

Correct, I looked at the wrong bits.

Quote:
I have looked at the signals on the chip: the receiver gets the frame and ACKs, but often too late: the sender has already started retransmission.

I'm not sure what you mean here. The CAN ack comes between the CRC and the end of frame. You have about 10 bit times after an ack before the sender has truely completed sending a frame, do it can't have started a re-transmission. If the sender really is ack'ing the frame so late that the ack is falling in the re-transmission, then the ack is *way* late. Are you looking at actual bits on the wire?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

p.234 After 15 bit CRC goes 1 bit CRC del, then 1 bit ACK and 1 bit ACK del, 7 bit EOF and 3 bit intermission.
My receiver has successfully read the message and sent the ACK. The timing from the SOF seems to be correct. But ACK del and EOF I do not see: they should be at the high level, but I see very short glitch to high level (ACK del) and then low (SOF) - it is transmitter repeats the message. Its hardware did not recognize ACK. I can not tell you why. Very rare ACK is accepted. My probes are on the CANTX pins of both MCUs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ACK FIELD
The ACK FIELD is two bits long and contains the ACK SLOT and the ACK DELIMITER. In the ACK FIELD the transmitting station sends two ’recessive’ bits. A RECEIVER which has received a valid message correctly, reports this to the TRANSMITTER by sending a ’dominant’ bit during the ACK SLOT (it sends ’ACK’).

ACK SLOT
All stations having received the matching CRC SEQUENCE report this within the ACK SLOT by superscribing the ’recessive’ bit of the TRANSMITTER by a ’dominant’ bit.

ACK DELIMITER
The ACK DELIMITER is the second bit of the ACK FIELD and has to be a ’recessive’ bit. As a consequence, the ACK SLOT is surrounded by two ’recessive’ bits (CRC DELIMITER, ACK DELIMITER).

The above is from the BOSCH CAN specification.

On the CAN bus itself the ’dominant’ bit is a low logic level and a ’recessive’ bit is a high logic level. I assume your CAN tx logic level where you attached your probe is inverted from the CAN bus logic level.

This is from page 237:
Bit Stuffing
The coding of the individual bits is tested at bit level. The bit representation used by CAN is "Non Return to Zero (NRZ)" coding, which guarantees maximum efficiency in bit coding. The synchronization edges are generated by means of bit stuffing.

Here is more information from the BOSCH CAN specification.
An ’error active’ station detecting an error condition signals this by transmission of an ACTIVE ERROR FLAG. The ERROR FLAG’s form violates the law of bit stuffing (see CODING) applied to all fields from START OF FRAME to CRC DELIMITER or destroys the fixed form ACK FIELD or END OF FRAME field.

The remaining bit fields of the DATA FRAME or REMOTE FRAME (CRC DELIMITER, ACK FIELD, and END OF FRAME) are of fixed form and not stuffed.

brberie wrote:
But ACK del and EOF I do not see: they should be at the high level, but I see very short glitch to high level (ACK del) and then low (SOF).....
The CRC delimiter and ACK delimiter are both fixed format. Both these bit times must be ’recessive’ bits. Since NRZ coding is used and bit stuffing is not applied to these fields, these bit values must be inferred from their baud which specifies the timing and sample point. There are two reasons the ACK may not be present. If the ACK FIELD bit value matches the CRC delimiter and ACK delimiter bit values, then no ACK was generated by a receiver node OR an active error frame has destroyed the entire ACK FIELD. Knowing if an active error is at work requires deciphering the ’dominant’ and a ’recessive’ logic level values at your probe point.

I think the ACK field can be characterized this way

No ACK from receiver:
	CRC DEL = recessive, ACK = recessive and ACK DEL = recessive
ACK from receiver:
	CRC DEL = recessive, ACK = dominant and ACK DEL = recessive
Active error frame:
	Either CRC DEL or ACK DEL = dominant

Having said all that, the CAN Tx pin may not be the best place too see all this happening. In theory the Tx pin will only see what that CAN node Tx is sending to the CAN bus and not see the entire bus activity. If this is the case then you will only see an ACK when that node receives a valid CAN message without errors. Again, an unhealthy CAN bus may prevent any receiver from sending an ACK.

In any case a successful ACK FIELD bit value must be opposite polarity from the surrounding CRC delimiter and ACK delimiter bit values if an ACK actually occurred. However, a Tx output pin only has to assert the dominant bit at the correct time. In this case what you thought was the ACK DEL on the CAN Tx pin may have been the actual ACK bit instead? Any node Tx pin should not even be able to see an Active Error frame sent by another CAN node. So, only looking at the Tx pin may isolate you from finding out what is actually happening on the CAN bus.

What are you seeing from the CANREC and CANTEC error counters (page 258)? If your bus is not healthy then not getting an ACK will predominate.

BTW, when you say “glitch” do you mean a time period much shorter than a 1 Mbps NRZ coded CAN bit time? I cannot tell if you meant a real glitch or if you observed an isolated 1 microsecond wide pulse.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike,

For this test setup I have only 2 nodes on the bus. The idea is exactly to monitor the physical TTL layer. Because there are only two nodes monitoring both TX pins simultaneously gives me a good idea about what is going on the bus. As you mentioned, the receiver will respond only at the ACK field and just before I do see a high level on both probes – I would say that it is CRC del. Immediately after there is low level signal on the receivers side and nanoseconds later there is a low signal from the sender. I do not see ACK del and the rest of the expected stuff in the frame. This low signal seems to me be SOF of retransmission.
Also I do get right response from the receiver, in other words it received and understood the command correctly.
In other words somehow the sender doesn’t get ACK…
I know that my bus is unhealthy, but it is close to what I expect in the real world and my goal is to prove that I can or can NOT use 1 Mbps speed. The only tool in my power is CANBTx settings.
I did not look at CANREC and CANTEC. I may try to do it on Monday.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heres a simple thing I forgot all about. Did you disable any “slope control” on both CAN interface transceivers? When its enabled it cuts down on EMI, but it also limits the maximum CAN bus bandwidth. It must be shut off at 1 Mbps.

There is another tool in your control and that is the CAN bus wiring itself.

I found this page where they list some of the actual specifications for the CAN wire:

http://www.cd-systems.com/Can/ca...

The cable quality goes up with the CAN bus speed.

BTW, a few nanoseconds is nothing with a 1 microsecond 1Mbps NRZ baud rate. Propagation delay through cable and interface chips will be much larger than a few nanoseconds. A change this small is still part of a single bit time in the frame.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a tranceiver I have ata6660. 1Mbps is legal for it. It also has fixed slope control, so there is no additional tool here. The cable and connectors robot has I can not change. So my degree of freedom is quite limited.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI for those who are doing CAN bit timing math, I made a spreadsheet to calculate CAN bus bit timings for the AT90CANxxx microcontrollers. It is in OpenOffice spreadsheet format. It has some directions inside it. It is based on Mike B's work.

Find at: http://selvaguitars.com/CanBusBi...

Hope you find it useful. Use at your own risk. Please report to me any errors / comments / ways to improve it, and I can do so. It worked great for me in finding some values that will give standard CAN baud rates while running on a "magic number" crystal (multiple of 1.8432), and I bet it will have other uses, such as playing around with different time quanta.

Why choose? Be there *and* be square!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

brberie,
if you don't see 1us ack pulse it is possible your ata6660 driver is set for low bandwith as Mike B suppose. Check pin 8=RS and ground it.
Szymon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brberie's post is over a 1.5 years old. I hope he figured it out by now :).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I mentioned a spreadsheet that I made for CAN bit timings. Well, I turned it into a Javascript application that may be easier for you to use:

http://karmacarpentry.com/can_ca...

Sage

Why choose? Be there *and* be square!