CANBus Determining Network Baud Rate, Automatic bit-rate detection

http://www.canbushack.com/blog/index.php?title=determining-network-baud-rate

Determining Network Baud Rate

So you found a CAN BUS to reverse engineer, but you don't know it's buad rate.

There are a couple to find it out.

One.

Go one-by-one through a possible list. 

CAN BUS baud rates tend to be of only certain baud rates.

I am not positive, but this most likely has to do with the common crystal speeds used in microprocessors.

The slower the crystal, the slower the bus speed.

So baud rates tend to be one of the following:

33,333 bps, 50 Kbps, 83,333 bps, 100 Kbps, 125 Kbps, 250 Kbps, 500 Kbps (Most common), 800 Kpbs, and 1,000 Kbps.

The last two being the least common as they suffer from reduce network length issues.

You will not find a baud rate that exceeds 1,000 Kbps as this violates the CAN BUS specification.

If I do not know the baud rate of the network that I wish to connect to,

I will typically go through this list and hope one works.

In some cases you may effectively decapitate the network by having the wrong baud rate set in your tool.

So make sure you are not switching baud rates while the vehicle is in motion!  This could cause undesired effects.

Two.

Use an osciliscope or logic analyzer. 

The foolproof way of measuring any serial data network such as CAN BUS is to use tool that can measure the one bit time.

Baud rate is simply the inverse of one bit time.

So if you can measure this, you simply take 1/(one bit time) in seconds and you have your baud rate.

The best location to find a single bit on CAN BUS is to look at the last transition.

This is typically the ACK bit (acknowledge). 

This is where receiving nodes send back a single bit to say that they properly received the frame.

This is always a bit by itself as the bit to the left is recessive as well as the bit to the right whereas it is dominate.

So it will stand out and you should have little trouble finding it.

So look to that last transition and mesure from on transition to the next and you should get something like 0.000002 seconds.

In this case you will simply take 1/0.000002 and you will get 500,000.

Thus the baud rate will be 500,000 Kbps.  Done!

具有can总线模块及自动速度检测的微控制器

一种用于初始化微控制器中的控制器区域网络CAN模块的方法，在所述方法中可提供以下步骤：

测量CAN信号的多个下降沿或上升沿之间的周期时间；

对所述周期时间进行排序；

确定所述经排序周期时间的相邻周期时间之间的差值；

对所述差值进行排序；

从所述经排序差值选择第一差值并从所述第一差值确定第一频率；

使用所述选定频率初始化所述CAN模块；

接收CAN信号帧；

确定是否发生错误；

如果发生错误，则选择下一频率并重复初始化所述CAN模块直到已发现有效的CAN频率为止。

http://www.datamicro.ru/download/801_v01000000.pdf

5.2 Automatic bit-rate detection

5.2.1 General In order to meet the requirement that a running CAN network is not disturbed by error frames,

it is not suitable to “test” the reaction of the network by sending out messages on all possible bit-rates.

The method for bit-rate detection should be non-reactive for the complete CAN network.

The two possible methods are:

• Measuring the time of a single bit

• Suppressing transmission of error frames (listen-only mode)

5.2.2 Measuring the bit-time of a single bit

Measuring the time of a single bit does not require a CAN controller,

but a good and fast timer module inside a microcontroller.

The concept has already been described in /AP292501/.

During the detection phase the CAN controller is switched off.

The timer module measures in a consecutive process the length of a single bit inside the data stream.

The main problem of the method is to find one single dominant bit – and only one – inside the frame.

There is always one dominant bit inside a CAN frame which is surrounded by two recessive bits:

the acknowledgement bit.

But this is only true if there are at least two CAN nodes on the bus.

Assuming only one active node (e.g. the CANopen manager is scanning the bus),

this method requires a specified identifier field or data field, otherwise it will fail.

Also the method requires a timer module, whereas the clock frequency should be higher than 10 MHz.

For a clock frequency of 10 MHz the difference between 800 kbit/s and 1 Mbit/s is just 2 timer ticks (refer to table 2).

Due to the drawback that at least two active nodes are required

and the high demands on the timer module this approach does not seem suitable.

5.2.3 Analyzing in listen-only mode

The listen-only mode is a feature that has already been implemented in several CAN controllers.

In listen-only mode, the CAN controller only listens to the CAN receive line without acknowledging the received messages on the bus.

It does not send any messages in this mode.

However, the error flags are updated so that the bit timing may be adjusted until no error occurs.

The necessary software algorithm is shown in Figure 1.

The CAN controller is initialized for acceptance of all messages (i.e. the global / local mask is set to 0).

The bit timing values of the first possible CANopen bit-rate (10 kbit/s) is loaded

and the controller is switched into “Listen-Only” mode.

Assuming that there is traffic on the network and the bit-rate is correct, the message is accepted.

The error registers will not change and the flag for message reception is set inside the CAN controller.

This means the correct bit-rate has been detected.

Assuming the bit-rate is not correct, the error flags will be updated (stuff-, CRC or form-error).

In this case the CAN controller is switched off and the next possible bit timing values are loaded from the bitrate table.

The minimum number of required messages to find the correct bit-rate is eight

(i.e. the number of defined CANopen bit-rates).

However, it shall be taken into account that a delay between the CAN messages is required, as shown in Figure 2.

The delay Tcc is the time to configure the CAN controller

(switch CAN controller off, select next bit-rate, set CAN controller into “Listen-Only” mode).

Depending on the interframe space and the time to re-configure the CAN controller,

the number of required CAN frames may be higher.

In addition to that, a CAN frame might be corrupted when the detection on the correct bit-rate is in progress.

This means the algorithm will exit in the „bus error“ branch.

One improvement of the algorithm is to check two consecutive times for a bus error,

leading to a more stable behavior even in a disturbed environment.