We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
I’m using the BeagleBone Black Rev C running Debian Linux. We are developing a new agricultural field implement. I have designed a CANBus interface board that uses the MCP2562 transceiver and Molex 39281043 for position connectors. The first board I designed has just one Molex connector, which connects to the CAN Bus network cable. I have a 120 ohm resistor across CAN_H and CAN_L, which can be jumpered in or out of the circuit as needed. This board works fine with two nodes, both of which are terminated with the onboard resistor connected.
I realized after receiving these that I had no way to easily use this board as a midpoint node, so I copied the working design and added a second Molex connector, allowing the board to be inserted into the network in a daisy chain fashion (at least, that’s how I think it works).
I’ve started testing by putting one of the boards in the middle of the network. Before doing so, I have reconfirmed that the two-node configuration still works and confirmed all the cables are good by using each in the two-node configuration one at a time.
I’m running at 500kbps. The cables are roughly 18” long.. The traces on the boards are under 0.5”.I have checked continuity on the boards and swapped the new boards out for a different copy of the board. At this point, I am not trying to communicate with the mid-node. I just want to keep communicating between the two end nodes firs,t and that is not working.
Any ideas? Anything you’d like to see? This is my first work with CANBus boards, and it was really encouraging to have such initial success. Now something has gone haywire!
From the info given it’s difficult to comment at any significant level of detail.
The basic complaint of communication between points A and C being disrupted by the insertion of point B in the middle might suggest that a person get out the 'scope and look for changes in the signal waveforms before and after. The differences that are bound to exist should give a person pointers for further inquiry.
When taking a new protocol/tech out for a spin the first time on a new design, it’s helpful to start with a presumption that any lack of desired function is due to silly oversights or misapprehensions one’s part, rather than going straight to theories of a more esoteric nature. Also, that even after something “works” on the bench there’s probably more to the story that one may want to consider, in order that the success may continue afield. Lots of good app notes available from component suppliers on such topics…
@David_1528 Thanks for taking a look though! @rick_1976 Yes, the scope is out and I’ll be doing just that. I am concerned though that the way I added the second Molex to the two connector board intended for ‘mid-node’ use in this network might not be correct.
I’ve gone ahead and popped in a screenshot of the PCB layout and if you have a moment to look it over and see anything just blatantly wrong, I would appreciate hearing that from you (or others). As I said, this board is based on the single connector board that works fine with the end points when the 120 Ohm terminating resistor is jumpered in.
I’m not asking for a full critique of the board (although I’ll take that too). I’m interested in if J1_TO_BUS and J2_TO_BUS are connected in a way that will keep them from working as a mid-node connection. My vision was that J1_TO_BUS connects to a cable going to end node A and J2__TO_BUS connects to a cable going to end node B. (J2_TO_MAINBRD goes to the BeagleBone Black). The board is 52 mm x 34 mm.
First impression of the layout is that the traces are very narrow with minimal clearance at a number of points. Very easy for that to result in things being connected that shouldn’t be or vice-versa, and also bad for signal integrity.
I’d check for rogue shorts/opens, add a ground plane, and fatten up the trace/space limits in a next revision.
@rick_1976 I was afraid you’d say that! I agree but had my fingers crossed. I have some time before these are needed so I will make a rev 2.
I did connect the scope and CAN_L looks really good on the mid-node board. BUT, CAN_H seems to be riding down on a lower frequency (probably 60Hz) carrier coming from somewhere. In my experience that’s usually a ground issue somewhere. That riding down while CAN_L is stable is going to impact the differential. CAN is great for dealing with noisy environments but this is probably stretching it.
I’m going to put a different one of these boards in and see if the behavior is the same. The cables are all good when checked with just the two end node boards in place.
@rick_1976 As a way to test the theory, do you think reducing the bit rate would make a difference?
Also, I could cut the suspect traces on a board and use wirewrap wire to re-establish the connections? I have three prototypes and I could sacrifice one. I only hate these kinds of hacks because they often introduce new problems.
60Hz coupling is often of a parasitic capacitive nature due to the wires strung all about to carry the stuff. That coupling might be estimated at picofarad scale, and should be no match at all for the output impedance of the driver(s) on the CAN_H line. If indeed you are seeing 60Hz superimposed on that net, it would seem to suggest a bad connection between the conductor and the driver that’s supposed to be driving it, but isn’t.
Multiple examples of a new board design that give the same result often points to a problem with the board. Variance of behavior among them suggests an assembly-related issue. Found many a rogue solder dribble in my time, and equal examples of stupids on my part with regard to layout. Most PCB tools provide some form of design rule check that are quite helpful once one learns to use them properly.
Lore of circuit development is rife with tales of [color]-wire fixes. A PCB is somewhat fixed by nature, but still affords a measure of fiddling about by hand to experiment and figure out what exactly a person messed up. Do what is needful to identify the root of the problem during development, and correct the problem(s) before entering production.
As for PCB design, understand that the “ground” network is closely analogous to sewer piping. A typical toilet in the US is likely to be connected to supply via a ~3/8" pipe, but have a 4" pipe coming out. The 0.1uF capacitor planted next to who-only-knows how many ICs over the years is analogous to the tank on the back of the typical household commode. 'Aint quite the same, but the idea translates pretty well.
Use a ground plane. Don’t chop it into nibbles and islands. Get a copy of Bogatin’s Signal Integrity Simplifed and such supplies as you reqiure to read it attentively, if you anticipate doing design work in the future.
I strongly suspect that your problem can be attributed to some relatively mundane issue, but can’t quite put my finger on it from this side of the screen.
@rick_1976 I have developed all the custom boards for our system under development over the past 5 years. I started off with Eagle and then AutoCAD merged it into Fusion 360. It has the design rules and error checking that you mention and I use those. I also like the 3D PCB board feature that helps with placing boards in enclosures but it’s still clunky and lots of components don’t include a 3D model.
I have a sample of Signal Integrity Simplified and started reading it a while ago and then decided, based on the information within the first bit of it, that our signals just aren’t fast enough to warrant a lot of the work described. However, of course, fast or slow, good design does pay off. On our latest rev of the main board, I did indeed apply some of what I learned in the first few chapters in the sample.
One bad habit of mine is that I don’t use ground planes. I know I should be, but I just haven’t. I’ll make the next rev of this board my first foray into this.
I am going to give the wirewrap hack a try and we’ll see what’s going on.
I reduced the bit rate to 125000 bps and the three node set up works. So I am redesigning the board to improve the layout so we can run at the higher rate. Lessons learned. Thanks!
FIXED! This issue all along has been capacitor C3. I misread the Microchip literature and thought that capacitor was supposed be installed from CAN_H to CAN_L. But it isn’t. I took that capacitor off the original boards and a three-node network is working really well now at 500Kbps. Looking at it now, it was obvious from the scope traces that a capacitive decay was involved as the two-node waveform has a decay and then adding a third node, thus increasing the capacitance, made the decay even worse. Duh. Shame on me! Live and learn.
I know this thread has been resolved, but I did notice one other thing that should be clarified.
You mention using the MCP2562 in your text and in your schematic, but the MCP2562 does not have the “SPLIT” pin shown in your schematic. Only the MCP2561 has that pin. The MCP2562 replaces the “SPLIT” pin with a “VIO” PIN, which should be connected to the VIO voltage supply of your controller device (looks like that’s the BeagleBone Black Rev C in this case).
It looks like you have that pin going to a pin on J2 labeled 3.3V, so that implies that it is connected correctly, but you might want to correct the label on pin 5 by labeling it “VIO” in your schematic to be consistent with the part number you are using.
