I'm trying out basic CAN communication on a Hercules microcontroller.
In this third blog I'll design driver PCBs.
The third part reviews the KiCAD PCB layout.
Two Layer PCB
I could have used a single layer PCB but there's no price difference with two layer boards.
The bottom side is dedicated to the power rail and ground. The top for the digital and analog signals.
Let's start with the bottom layer. Because the 3V3 isn't used a lot but crosses the whole board, I decided to route that first.
All the rest of the board area is ground. I added keepout areas on the two trough-hole connectors.
I've used the datasheet of the TCAN332D for the layout guidance.
These are the things I've taken over from the advice:
- Transient Protection on CANH and CANL: ... These devices must be placed as close to the connector as possible
- Decoupling Capacitors on VCC: Bypass and bulk capacitors must be placed as close as possible to the supply pins of transceiver
- Ground and power connections: Use at least two vias for VCC and ground connections of bypass capacitors and protection devices to minimize trace and via inductance
- Filtering noise on digital inputs and outputs: To filter noise on the digital I/O lines, a capacitor may be used close to the input side of the I/O
I didn't do anything specific for this one:
- Because ESD and EFT transients have a wide frequency bandwidth from approximately 3 MHz to 3 GHz, high frequency layout techniques must be applied during PCB design.
I tried to keep all signals short and direct and provided a decent plane on the back. Only one signal goes trough a via (unfortunately in the transient protection circuit - maybe the worst one of the whole set?)
This wasn't a difficult exercise. The whole circuit is symmetrical and the components almost call for a particular position on the board.
You can see on the digital side on the board that there's nothing complex there.
The components on the left are the digital circuitry.
The bulky copper below U1 are the two power planes.
I've provided enough vias to get a good connection with the bottom planes.
The output circuit and protection are also symmetrical.
Here you can see that I used two vias to route the signal between R5 and C6.
Because this is a part of transient protection, it's best to have a short path .
I could have taken the proper time to rethink the position of a few components.
Putting D1 to the left of the output passives would have been one of the options.
The boards are ordered yesterday evening.
I've got a message from OSHPark that I got an upgrade to the Super Swift service and that the fab will make them within 5 business days.
The KiCAD project is attached to this blog.
Optional Components and Line Termination
The whole output protection part is optional. I do not intend to populate C5, C7 and D1 for this project.
These boards will not end up in a car. It will just be two of these talking together in the safe lab.
I don't need pull-up resistor R3 because the weak pull-up in the CAN driver together with the active pull that I will configure in my microcontroller should do.
I'll probe the signals once the circuit is built. If there's a sign of a weak digital signal, I'll try some pull-up values.
I will populate the CAN Bus termination components because both devices are end points and for signal integrity, both ends need to be terminated with a 120R impedance.
There are two options. I can either use two 60R for R5 and R6 and populate C6, or I can use 120R for one of the two resistors and bridge the other one. In that case C6 should not be placed.
Both options close the line as per specs. The first one has better common noise filter behaviour.
Monitor the Signals with an Analyser
I have some good news for @self here. I'm selected for the Microchip CAN Bus Analyser Tool road test.
I used this blog series as driver for the participation (see How I Enroll for a RoadTest - Part 6: Case for CAN Analysis Tool).
So I will have to make that happen now . I think it will be a very welcome instrument. My current analyser can probe the digital side only and doesn't understand CAN traffic.
With the CAN Bus analyser I'll be able to see traffic, but also to inject traffic on the bus. Excited.
can_driver.zip 27.7 KB