CAN BUS Baud rate setup

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

I am pulling my hair, have been trying to understand how to configure the can baudrate parameters for avr32.

There is no function in the ASF to calculate the needed bps settings for a certein can clock.

I am using a UC3C-EK board and I want to acheive 250kbps. Any help that can be provided would be greatly appriciated.

Thanks /// Carl

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

There are some formulas in the data sheet

Quote:

The bit duration is given by the formula:
Tbit = (PRS + PHS1 + PHS2 + 4) x (PRES + 1) x PGCLK_CANIF

Here what is the unit of TBIT ? Seconds ? I assume that PGCLK_CANIF is the same as OSC0 16MHz. Without any divisions in the formula I dont see how I can reach a 0.000004 s/bit timing. i.e 250kbps

Quote:

TQ = Prescaler x GCLK_CANIF = (CANCFG.PRES+1) x GCLK_CANIF

Further confusing me I have seen examples for a CAN clock of 8MHz and 16MHz both using the same parameters reaching 1mbps

Quote:

#define CAN_BAUDRATE_1MHZ_CANCLOCK_16MHz
#define CAN_BAUDRATE_1MHZ_CANCLOCK_16MHz_SJW 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_16MHz_PRES 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_16MHz_PRS 2
#define CAN_BAUDRATE_1MHZ_CANCLOCK_16MHz_PHS1 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_16MHz_PHS2 1

Quote:

#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_SJW 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PRES 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PRS 2
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PHS1 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PHS2 1

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

Quote:
Here what is the unit of TBIT ? Seconds ? I assume that PGCLK_CANIF is the same as OSC0 16MHz. Without any divisions in the formula I dont see how I can reach a 0.000004 s/bit timing. i.e 250kbps

Yes the unit of TBIT is seconds. You must choose values for PRS, PHS1, PHS2 and PRES so that the formula will give you a 1/250.000 second. There are tables for these parameters for Common Baud rates.

Quote:
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_SJW 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PRES 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PRS 2
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PHS1 1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PHS2 1

I think that these definitions are wrong. Where have you found them?

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

Quote:
Yes the unit of TBIT is seconds. You must choose values for PRS, PHS1, PHS2 and PRES so that the formula will give you a 1/250.000 second. There are tables for these parameters for Common Baud rates.

If you know where I can find these tables please post the link. 250kbps should be a common rate since its used by j1939.

Quote:
I think that these definitions are wrong. Where have you found them?

http://asf.atmel.com/docs/latest/uc3c/html/conf__can_8h.html

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

Take a look at the CAN chapter inside the AT90CAN datasheet, there you find example values.

I found in http://asf.atmel.com/docs/latest...

#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PRES 3

But I think this must be wrong, better ignore it for the moment.

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

If I want the bus speed to be conigured to 250kbps

Quote:

Tbit = (PRS + PHS1 + PHS2 + 4) x (PRES + 1) x PGCLK_CANIF

Should Tbit be equal to 250000 ?

My PGCLK_CANIF = 16 000 0000 all other parameters in the formula are > 1 how can that evaluate to Tbit = 250 000 ?

Should the PGCLK_CANIF be divided by the prescaler and not multiplied?
I have to be missing something obvious here because it doesnt makse sense at all.

Thanks /// Carl

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

PGCLK_CANIF = 16.000.000Hz = 1/16000000s
If you set PRS=2,PHS1=1,PHS=1,PRES=7 then you have:
(2+1+1+4) x 8 * (1/16000000s) = (1/250000s)

And that is what you wanted

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

Thank you so much, that wasn't clear to me

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

Be aware that you can get the same baudrate with other settings, e.g: PRS=6,PHS1=3,PHS=3,PRES=3. Since I am no CAN Bus expert, I am not sure in what cases someone wold choose the one or the other setting.

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

This: (PRS + PHS1 + PHS2 + 4) is a really strange way of representing what is going on. First SYNC_SEG has no AVR32 CANCFG field because it is always a fixed value of 1 no matter what (it is never programmable). Because PRS, PHS1 and PHS2 are represented as minimal binary 3 bit fields (0 to 7), their TQ unit value (1 to 8 ) is actually PRS+1, PHS1+1 and PHS2+1. See Table 29-2 CAN Parameter Settings. The actual Bosch equivalent formula is this:
Tbit = (SYNC_SEG + PRS+1 + PHS1+1 + PHS2+1)

The data sheet formula is correct, it just has a strange way of hiding the SYNC_SEG and the three different bit field increments which altogether equal 4.

CAN bit timing is complicated. The CAN baud rate limits the maximum physical length of the CAN bus due to propagation delay. Other electronic circuit propagation delays also limit the maximum physical length of the CAN bus. After compensating for propagation delays (PRS+1), phase segment 1 (PHS1+1) determines the sample point. The Synchronization Jump Width is not part of Tbit, but it allows the CAN baud timing to dynamically shift the sample point up to the SJW+1 value (this must never be larger than PHS1+1). Then phase segment 2 (PHS2+1) fills out the rest of the Tbit length.

The UC3C data sheet left out the CAN Information Processing Time (IPT) value. The IPT determines the minimum length of phase segment 1 and phase segment 2. Both phase segments 1 and 2 have rules about their minimum and maximum values in relation to each other starting at the IPT value.

All of this CAN baud programming taken all together makes it possible for each CAN node to correct for total network propagation delay and total network phase error such that every CAN node sees the exact same CAN bit at exactly the same corrected time frame. This is one critical element that makes real time CAN bit binary value arbitration possible on a CAN network.

This ATMEL application note has more information, but not really for CAN baud - AVR32129: Using the 32-bit AVR UC3 CANIF:
http://www.atmel.com/dyn/resourc...

This has detailed CAN buad information - The Configuration of the CAN Bit Timing:
http://www.semiconductors.bosch....

The ultimate source for CAN info - Bosch CAN Specification Version 2:
http://www.semiconductors.bosch....

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

Since I had a PM question about this I thought I would add it to this post. Actually the AT90CAN data sheet has several problems with the CAN baud description.

Bosch spec page 29 wrote:
The RESYNCHRONIZATION JUMP WIDTH shall be programmable between 1 and min(4, PHASE_SEG1).
AT90CAN data sheet page 241 rev 7679H wrote:
SJW: (Re) Synchronization Jump Width is programmable between 1 and min(4, PHS1).
Obviously ATMEL copied this from Bosch. However, the problem is Bosch RESYNCHRONIZATION JUMP WIDTH and PHASE_SEG1 values are true TQ starting at 1 not at 0 (the Bosch upper limit of 4 for a 2 bit SJW field is one clue that it has a +1 offset). While the ATMEL SJW and PHS1 values are binary fields starting at 0 not at 1. ATMEL made the mistake and they should have said:
Quote:
SJW: (Re) Synchronization Jump Width is programmable between 0 and min(3, PHS1).
All this means is:
0 ≤ SJW ≤ PHS1 (the maximum value for SJW is 3 because it is a 2 bit binary field)

This AT90CAN info:

AT90CAN data sheet page 241 rev 7679H wrote:
PHS2: PHase Segment 2 is programmable to be ≤ PHS1 and ≥ INFORMATION PROCESSING TIME.
is also wrong. The Information Processing Time (IPT) is in TQ starting from 1, while PHS1 is again a binary field value from 0 to 7. This should have said something like this:
Quote:
PHS2: PHase Segment 2 is programmable to be ≤ PHS1 and ≥ (INFORMATION PROCESSING TIME - 1).
This is also wrong:
AT90CAN data sheet page 241 rev 7679H wrote:
PHS1: PHase Segment 1 is programmable to be 1, 2, ..., 8 TQ long.
Because of the IPT it should read:
Quote:
PHS1: PHase Segment 1 (+ 1) is programmable to be 2, 3, ..., 8 TQ long.
PHS2 (binary field) is bounded by IPT (a value of 2 TQ) and PHS1 (binary field) as follows:
(IPT - 1) ≤ PHS2 ≤ PHS1
it also means this:
(IPT - 1) ≤ PHS1
Basically how can this ever be true when (IPT - 1) = 1:
1 ≤ PHS2 ≤ PHS1, (where PHS1 = 0) makes 1 ≤ PHS2 ≤ 0 (impossible)

This is what the AT90CAN data sheet should have said:

Tprs range is 1 to 8 (TQ units)   PRS[2..0] range is 0 to 7
Tphs1 range is 2 to 8 (TQ units)  PHS1[2..0] range is 1 to 7  (PHS1 is never smaller than PHS2)
Tphs2 range is 2 to 8 (TQ units)  PHS2[2..0] range is 1 to 7  (PHS2 is never larger than PHS1)
Tsjw range is 1 to 4 (TQ units)   SJW[1..0] range is 0 to 3   (SJW is never larger than PHS1)

My own comment for new baud rates wrote:
For example, if PHS2 = 4 then PHS1 may only be 4, 5, 6 or 7.
I threw some WinAVR code together for when I am creating my own CAN baud rates on the AT90CAN family as a double check for custom baud rates:
        // Set the CAN baud rate (CLKio - CANBT1, CANBT2, CANBT3):
        // >>>> DO NOT forget about the CLKPR register and CKDIV8 fuse settings. <<<<
        //
      //****
      // This is a randomly selected CAN Baud setting, you need to put your real values based on CLKio here.
      // See the CAN baud examples and the Baud Rate Prescaler errata in the ATMEL data sheet.
      //****
    #define CANBT1_VAL  0x12
    #define CANBT2_VAL  0x0C
    #define CANBT3_VAL  0x37

    CANBT1 = CANBT1_VAL;        // Timing - Baud Rate Prescaler. See the data sheet errata if CANBT1=0.
    CANBT2 = CANBT2_VAL;        // Timing - Re-Synchronization Jump Width and Propagation.
    CANBT3 = CANBT3_VAL;        // Timing - Phase Segment 2, Phase Segment 1 and Sample Point.

        // Perform a warning check and error checks on the CAN baud setup values. These checks do not
        // verify the actual CAN baud rate is correct, they only verify certain rules are followed.
    #if ((CANBT1_VAL & 0x7E) == 0)
        #warning See the CAN data sheet for CANBT1.BRP = 0 errata.
        #if ((CANBT3_VAL & 0x01) == 1)
            #error Errata, the CAN baud CANBT3 SMP bit must be cleared when CANBT1.BRP = 0.
        #endif
    #endif
    #if ((CANBT3_VAL & 0x0E) == 0)
        #error The CAN baud PHS1 must be larger than 0 due to the Information Processing Time (IPT).
    #endif
    #if ((CANBT3_VAL & 0x70) == 0)
        #error The CAN baud PHS2 must be larger than 0 due to the Information Processing Time (IPT).
    #endif
    #if (((CANBT3_VAL & 0x70) >> 4) > ((CANBT3_VAL & 0x0E) >> 1))
        #error The CAN baud PHS2 must be equal to, or less than PHS1.
    #endif
    #if (((CANBT2_VAL & 0x60) >> 5) > ((CANBT3_VAL & 0x0E) >> 1))
        #error The CAN baud SJW is larger than PHS1.
    #endif
    #if ((4 + ((CANBT2_VAL & 0x0E) >> 1) + ((CANBT3_VAL & 0x0E) >> 1) + ((CANBT3_VAL & 0x70) >> 4)) < 8)
        #error The CAN baud Tbit count must be 8 to 25.
    #endif
    #if (((CANBT1_VAL & 0x81) != 0) || ((CANBT2_VAL & 0x91) != 0) || ((CANBT3_VAL & 0x80) != 0))
        #error Reserved CAN baud bits in CANBT1, CANBT2 or CANBT3 are not set to zero.
    #endif

Because the UC3C data sheet does not give the IPT value, I'm not sure where PHS1 and PHS2 actually start, but an IPT=2 TQ seems to be a fairly typical value in most CAN chips. Of course the UC3C clock setup is more complex, the programming fields are different and the errata is different, but something like this could be written for the UC3C CAN baud programming.

BTW, you do not have to check for Tbit > 25 because 25 is the maximum value:

Tbit = (1 + 8 + 8 + 8) is 25

Tbit will never get any higher because of the 3 bit binary field values (all incremented by 1 to get real TQ values of 8 each).

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

Sorry, I forgot one issue about SJW. I assume I understand and use the correct CAN baud rules, but if PHS2 is correctly less than PHS1, but PHS2 is lower then SJW I'm not so sure about this. Like: PHS1=4, PHS2=2 and SJW=3. in this case I'm more comfortable with SJW=2. Unfortunately I do not have a good answer for this case, however there is no Bosch rule about taking the PHS2 value into account for SJW.

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

I'm using UC3-EK and compiling the CAN-LIN-LOOPBACKS-DEMO

In conf_can.h they have the following defines:

#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_SJW     1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PRES    3
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PRS     2
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PHS1    1
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz_PHS2    1 

However, if I evaluate the formula given above:

Tbit = (PRS + PHS1 + PHS2 + 4) x (PRES + 1) x PGCLK_CANIF 

And assume (from the name provided) that the PGCLK_CANIF = 8MHz then it calculates out at a CAN baudrate of 250kbps which is not the same as the name appears to claim?

Is the #define just incorrectly named? Or am I missing something? perhaps I'm confusing CAN_BAUDRATE_1MHZ being the same as 1Mbps?

I want to achieve 500kbps. So, assuming the CAN clock is ticking at 8MHz then I plan on using PRS=2, PHS1=1, PHS2=1, PRES=1

To produce the 1Mbps claimed (assuming 1Mbps = 1MHz) then with those values we'd need a CAN clock of 32MHz. And to achieve 500kbps then I'll use PRS=2,PHS1=1,PHS2=1,PRES=7.

Of course, at the moment I don't know whether affecting all of the change via PRES is the way to go. So who knows what I'll get - I have found this link: http://karmacarpentry.com/can_ca... which says this:

Quote:
Though CAN bus timing is complicated, generally the sampling point, which is the start of Phase Segment 2, should be at around 70% timing within the bit.

However, I'm not really sure how to use the calculator and to tie it back to the calculations presented here.

Sigh...

Color me confused! Any suggestions on where the mismatch between the calculation and the nomenclature in the example would be greatly appreciated. In the meantime I'll throw a bunch of values at it and see what sticks... ;-)

Even if I don't get an answer thanks to all of you who've already posted. Thanks to you I'm at least a lot closer than I was...

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

One problem is the 8 bit AVR and 32 bit AVR documentation use Tbit to represent different things.

8 bit AVR wrote:
The bit duration is given by the formula:
Tbit = Tsyns + Tprs + Tphs1 + Tphs2
This Tbit is actually the total number of TQ per CAN bit. It does not tell you the baud rate since there is no prescaler or clock frequency information. The equivalent formula is:
TQ per CAN bit = PRS + PHS1 + PHS2 + 4
AVR32129: UC3 CANIF wrote:
The bit duration is given by the formula:
Tbit = (PRS + PHS1 + PHS2 + 4) x (PRES + 1) x PGCLK_CANIF
This Tbit should be the actual bit duration, probably in seconds? One problem is PGCLK_CANIF does not appear to exist in the loopback demo code (it is probably deep in some library if it exists at all). The other problem is line 54 of file conf_can.h is too simple:
#define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz

Defined as what? This suggests this define CAN_BAUDRATE_1MHZ_CANCLOCK_8MHz may be nothing more than a defined label for compiler/linker information used by library code that has no source included with the provided demo source code (it is all AVR Software Framework stuff).

From the formula we know:
TQ per CAN bit = (2 + 1 + 1 + 4) = 8
Prescaler divider = (3 + 1) = 4

AVR32129: UC3 CANIF wrote:
The Time Quantum is a fixed unit of time derived from the GCLK_CANIF clock period:
TQ = Prescaler x GCLK_CANIF = (CANCFG.PRES+1) x GCLK_CANIF
I cannot find the definition for GCLK_CANIF in the demo code either. However, at 1 mbps CAN baud the total CAN bit time is (1 / 1000000) = 1 µs long. With 8 TQ per each 1 µs long CAN bit, each individual TQ time is (1 µs / 8 ) = .125 µs long. These values are fixed by the physical CAN baud rate and TQ per CAN bit you have chosen. I think the CAN PRES prescaler is a divider, but the clock source has an available PLL that is capable of multiplying the UC3C clock source frequency. We do know the CAN hardware needs an 8 MHz clock to get 1 mbps with 8 TQ per CAN bit (8 TQ * .125 µs) = 1 µs CAN bit time length (1 mbps). With a CAN prescaler of 4 this appears to suggest a 32 MHz UC3C clock. With a .4 to 20 MHz crystal limit and an 80 to 240 MHz PLL limit, this suggests a PLL multiplied crystal, divided down to 32 MHz that feeds the CAN prescaler input.

I get the feeling mastering the AVR Software Framework may be needed if you make major crystal frequency changes.

The CAN bit sample point is:
Sample point in TQ = Tsyns (fixed value of 1 TQ) + PRS + 1 + PHS1 + 1)
With 8 TQ total the percentage of the sample point in each CAN bit is:
Sample % = (Sample point TQ / 8 TQ) * 100

Your 1 mbps baud is (1 + 2 + 1 + 1 + 1) = 6 TQ to the sample point:
Sample point TQ = (PRS + PHS1 + 3) also works.
6 TQ / 8 TQ = .75 * 100 = 75 % bit sampling

Your 500 kbps baud uses the same PRS, PHS1 and TQ per CAN bit, so it is also 75 % sampling (SJW may change the actual sample point).

Cutting the baud rate in half from 1 mbps to 500 kbps suggests the prescaler PRES needs to be increased (double to cut the CAN hardware clock in half just like you did in your example) as long as you are keeping the 8 TQ per CAN bit intact. I would start by getting the 1 mbps CAN baud demo working first, then try increasing the CAN PRES to see if the baud rate gets to 500 kbps. Since the demo uses the same built in hardware with a common clock, measuring the exact CAN baud rate will be difficult. If you get the CAN baud rate wrong, without any external CAN hardware involved it will probably work just fine at the wrong CAN baud rate. If your code is working and you have known 500 kbps external CAN hardware connected it will get constant CAN bus errors if the UC3C baud is wrong. A logic analyzer capturing the same CAN frame traffic at both rates should show double length NRZ CAN bit lengths for the 500 kbps frame captures.

Since there are several defines that I am not able to find, I am not able to help you figure out those formulas. For example when they say “bit duration” I would expect bit length time in seconds and not frequency. But without the missing define values I am not able to tell if they are talking about seconds, real duration, frequency, TQ measure integer units, etc. for the formula results???? If you assume a specific result type for a formula you should be able to solve for the unknown value, but it might not be exactly what the AVR Software Framework uses for their define value.

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

Mike - thanks for the reply.

So far none of my chosen values are letting me connect to my external source (an '05 Prius' OBD-2 connector).

As you pointed out - I can successfully change the values and see a different rate occur in the demo code (I just modified the RX callback to increment a counter and I see it rise at a different rate with different PRES/PRS/PHS1/PHS2 values). But, like you say, that just tells me that I can change the baud rate. Not that the baud rate is correct.

Tomorrow I will try hooking up a scope on the development board and I should be able to calculate the frequency that way. Well, that's my hope anyway.

BTW - I've submitted a ticket to Atmel about this - I've no idea if they'll respond or not.

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

Since you are going to an OBD-2 connector, give your UC3C-EK CAN board termination some thought. The OBD-2 connector is probably a CAN bus stubb that does not want any termination (pull the J9 or J14 jumper depending on which CAN you are using) or possibly weak termination for some automotive CAN bus designs (this would be a custom hardware termination setup). Most likely you just need to make sure the termination jumper or jumpers are removed from the UC3C-EK.

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

Mike B wrote:
Since you are going to an OBD-2 connector, give your UC3C-EK CAN board termination some thought. The OBD-2 connector is probably a CAN bus stubb that does not want any termination (pull the J9 or J14 jumper depending on which CAN you are using) or possibly weak termination for some automotive CAN bus designs (this would be a custom hardware termination setup). Most likely you just need to make sure the termination jumper or jumpers are removed from the UC3C-EK.

Ah! Good point. For the demo they're both terminated, but I suspect you're right and the port I use for connecting to ODB-2 shouldn't be terminated.

BTW, I got the following response from Atmel:

Atmel wrote:

This configuration is not right. It use 16MHz for can clock not 8MHz. And PRES should be 1 to configure CAN clock 1MHz. I will report this bug and thanks for your information.
Please refer to the CAN Software Stack Example in ASF for the right configuration.
You can open Atmel Studio 6.0->File->new->example project, in the "New Example Project" window, click "Kit" from the left side and expand the board you use(UC3C-EK), then select “CAN Software Example ".

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

I managed to get hold of another CAN development system (from Microchip) that hooks up to the PC and displays the traffic.

With this I was able to confirm that I can get the AC3C-EK communicating at 500kbps using the following parameters:

Quote:
#define CAN_BAUDRATE_500KBPS_CANCLOCK_16MHz_SJW 1
#define CAN_BAUDRATE_500KBPS_CANCLOCK_16MHz_PRES 3
#define CAN_BAUDRATE_500KBPS_CANCLOCK_16MHz_PRS 2
#define CAN_BAUDRATE_500KBPS_CANCLOCK_16MHz_PHS1 1
#define CAN_BAUDRATE_500KBPS_CANCLOCK_16MHz_PHS2 1

This coincides with all the information presented above. I've also attached a simple spreadsheet that allows the calculation of the PRES/PRS/PHS1 and PHS2. It could be improved to take into account sample point - but I'll leave that as an exercise to the reader! :)

BTW, I can't yet get my board talking to the Prius OBD2 connector (with or without the termination resistors in place). But now at least I have a way of confirming that the dev board is working as expected.

THANKS!!!

Attachment(s): 

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

It sounds like the next step is to detect and report the CANISR register errors and CANFC register EMODE/TEC/REC values. This should give you some valuable debug clues as to what is going on between the OBD2 and your CAN board.

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

Hey guys.

thx to jdh2550 for the baud.xls
I have enhanced the functionality and now you just enter:

    target bps source clock speed
    target sample point

After pressing Calculate the xls tries to find the best register settings for you. At the bottom is a table where you can see the results sorted by accuracy (best at the top when acurracy = 0).

Have fun
Tobias

Attachment(s): 

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

 

Anyone know of a CAN Baudrate Calculator like TobiasDiendorfer posted above but that will work with 8-bit AVRs?

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

Yes, it was true in the calculations but not with that occurs in field.

I've tried it and it didn't work with the formula, after I find out, a successful formula is:

PRS = 4, PHS PHS = 4, = 4, PRES = 3 then you have:

(4 + 4 + 4 + 4) x 4 * (1/16000000s) = (1/250000s)

 

and this works well