# Making high CAN baud rates work

I'm dealing with a board that no matter what I do I can't seem to make CAN work over 125 kbit/s. I'll give some detail about the board on the bottom, but I'm going to keep this question generic.

First of all, regarding hardware. From what I've gathered, there isn't any need for a pull-up resistor on the TX of CAN. Is that correct? It may perhaps be chip-specific, but wherever I see, it seems that the TX/RX lines are directly connected to the transceiver.

Second, regarding bit-timing: Using different calculators, for example, Kvaser or the one from Microchip, I can see the following configuration (for 64 kHz input clock):

             SYNC     PROP     PHASE1      PHASE2       BRP (prescaler)

125  kbit/s   1        1        3           3            32
250  kbit/s   1        1        3           3            16
500  kbit/s   1        1        3           3             8
1000 kbit/s   1        1        3           3             4


I've seen this from more than one source. Furthermore, the numbers fit to the formula in the datasheet of the microcontroller.

However, only the configuration for 125 kbit/s works for me. I'm using CANreal to monitor the messages.

I've tried different configurations for the CAN, for example with 16 time quanta instead of 8 as well as changing my microcontroller's clock to 16 MHz and using again different values. Regardless of all that, speeds higher than 125 kbit/s result in only errors and warnings in CANreal (which are taken from the CAN driver). Note that the same CAN board, driver and software works with 1 Mbit/s with some other hardware I have.

This all is made harder since, as soon as I put a probe from my oscillator on the TX line, it becomes a continuous 0-1 alteration like the following:

      __------     __------     __------     __------     __------
/       |    /       |    /       |    /       |    /       |
/         |  /         |  /         |  /         |  /         |
/          | /          | /          | /          | /          |
|          | |          | |          | |          | |          |
|          |_|          |_|          |_|          |_|          |


Which is not something I would be outputting by software. In fact, as soon as I remove the probe, the messages start arriving (again, only at 125 Mbit/s). So basically, I don't seem to be able to have any oscillator debugging available.

Back to my "first of all, regarding hardware", the shape of the signal suggests a pull-up resistor may be necessary, but I haven't seen the need for that in any datasheet I found. Furthermore, my microcontroller configures the pin when used as CAN, so I don't have control over making it push-pull (since it looks like it's open-drain). Not to mention the microcontroller doesn't even have a configuration to make the pin push-pull.

Is there any hidden parameter somewhere that should also be set? Is a pull-up resistor necessary after all? Why would the oscillator probe cause such a behavior?

Details from the board:

• MCU: P18F45K80. CAN is connected to its default RB2 and RB3.
• CAN transceiver: ISO1050
• Compiler: mikroC
• Any chance you could post a schematic? I've got a guess as to what's wrong but a schematic would really help. Even just from one transceiver to another. I did a lot of work with 1 Mbit/sec CAN at my last job and it was pretty picky about how the physical layer was configured. – embedded.kyle Nov 8 '13 at 19:30
• Perhaps this question on the Electronics Stackexchange might be the answer? What does this CAN bus waveform mean? – Rocketmagnet Nov 11 '13 at 16:10
• @Rocketmagnet, thanks for the link. So probably adding the oscilloscope caused the bus to change and made the termination resistor invisible, or something like that! (Excuse my ignorance, my knowledge of electronics is quite limited) – Shahbaz Nov 11 '13 at 16:13
• @Shahbaz Would this question be better suited to electronics.SE? Especially since the problem is solved, it might be easier for people with the same problem to find it there. – ThomasH Jan 11 '14 at 15:38
• @Shahbaz Just learned that you can't migrate a question after 60 days, so I'm four days late and we'll leave it be, since it would be a cosmetic change anyway – ThomasH Jan 11 '14 at 18:50

## scope probe

I can sympathize with how frustrating it is when attaching an oscilloscope probe to debug a problem makes the system act differently.

A standard 1X probe (1:1 probe) will load a circuit with a capacitance of about 110 pF. Many people use a 10X probe or a 100X probe, giving 1/10 or 1/100 the loading on the circuit -- hopefully small enough to be insignificant.

## ISO1050

a pull-up resistor on the TX of CAN. ... the shape of the signal suggests a pull-up resistor may be necessary, but I haven't seen the need for that in any datasheet I found.

I think this is it. Page 4 of the datasheet for the ISO1050 specifically says

NOTE

TXD is very weakly internally pulled up to VCC1. An external pull up resistor should be used ... An adequate external pullup resistor must be used to ensure that the TXD output of the microprocessor maintains adequate bit timing input to the input on the transceiver.

## PIC18F45K80

I'm assuming you're using the Microchip PIC18F45K80. The PIC18F66K80 family datasheet has a lot of useful information about the Microchip PIC18F45K80. In particular, I think you might find section 27.0 ECAN MODULE useful. Subsection 27.2.5 mentions ENDRHI: Enable Drive High bit, where

• ENDRHI = 1: CANTX pin will drive VDD when recessive
• ENDRHI = 0: CANTX pin will be tri-state when recessive

Subsection 27.3.1 CONFIGURATION MODE implies that ENDRHI (and all other configuration bits) must be set in configuration mode, and cannot be changed while the CAN module is active.

I suspect that either the pull-up resistor or setting ENDRHI to 1 would be adequate. However, if I were you, I would run some tests with both a 10 KOhm pull-up resistor and ENDRHI set to 1.

• That must be it! I'd have to wait till Monday to test this, but ENDRHI must be it. Probably the reason I didn't see pull-up resistor used in other schematics was because they have been strongly driving the pin. Searching for push-pull in the datasheet hadn't given me any results which was strange. Can't believe I missed ENDRHI! – Shahbaz Nov 9 '13 at 15:39