This may be my slowest blog series ever - previous post was October '17.
I'm trying out basic CAN communication on a Hercules microcontroller.
In this part I have my driver boards working.
I designed a tiny CAN driver PCB more than a year ago, for the Microchip CAN Bus Analyser Tool Road Test.
At the time, it didn't work. Road Test stress and work and life prevented me from getting to the bottom of the issue.
You can see some of my trials in the comments of part 3c: Design a Bus Driver PCB - Layout
This week - I had holidays - I took the time to beep out all the connections on both boards.
I found that two of the CAN driver IC pins on one board gave contact when I measured near the PCB, but not when I measured on the top of the IC.
Turns out that they made bad contact and were slightly floating over the solder.
I removed the IC, cleaned the footprint and put it back. Everything is working now.
On the microcontroller side of a CAN chip, all is digital. In my case, the signal is on a 3V3 logic level.
In automotive, a signal is exposed to interference. Loads of things happen inside a car.
If you run a wire that has a digital signal in a car, data will get corrupted.
That's why the CAN physical layer is made. It defines that the physical layer is a (relatively) strongly driven signal.
It's differential,and the wiring is twisted pair. These measures take care that the signal is much more resilient to .environmental influences.
The differential signal is a direct function of the digital signal. But instead of a single signal referenced to ground, it's two opposite signals referenced to each other.
Both twisted pair and the differential nature helps to filter out external noise. Physics take care that most of the noise cancels itself.
The driver is responsible for translating from data layer to physical layer and back. It's not a fully implemented OSI model but implements several layers.
The controller logic, in my case, is part of the microcontrollers. I'm using an automotive Hercules TMS570LS04.
( am using 2 CAN controllers of the same microcontroller today, but you get the point).
The ICs on my drive boards, TCAN332D, are the ones that do that translation.
I've chosen simple devices that only do the translation.
There are more advanced ICs that handle errors on the physical layers.
I haven't used those for a few reasons:
- my main goal is to validate the Microchip CAN analyser on physical level
- the Hercules controllers have a fair amount of error handling themselves
- keep the design focused. There are elaborate development kits available. I wanted a bare basic one.
I'm testing with an oscilloscope now. I'll use the Microcip CAN BUS analyser on the physical layer once I'm sure I'm within its operating conditions.
I'm using a design that I tested on the logic layer, so I'm confident that the logic works (see TI Hercules LaunchPad - test the CAN with a poor man's CAN driver).
The driver boards allow me to analyse the traffic on the physical level.
I can confirm that the design is working - and that the signals are within the limits of the Microchip analyser.
In the next post, I'll try to capture the data using that analyser (edit: done part 4: Analyze the Physical layer of CAN Bus).