CAN BoosterPack

[spirilis 1,265]

Those examples cause the red LED on the MSP430G2 LaunchPad to flash twice if a successful call & response occurs (master sends 2 bytes to 0x00000080, receiver acknowledges by replying same data at 0x00000040), and either side will go into an infinite loop flashing their red LED if an error occurs.

 

If the receiver is disconnected, the CAN controller recognizes the lack of ACK as an error and throws an error.  So if the receiver side's RJ45 is disconnected, the master goes into an infinite loop flashing its LED and needs to be reset. (obviously this can be handled in software and retried)

 

So that's something an application will have to watch for... a TX error will occur if nobody's around to listen.  Even if nobody's acting on the message, just having another node present on the bus to provide the ACK is important.  The node could be filtering out the message entirely and an ACK would still get sent indicating successful transmission of the message.

[spirilis 1,265]

Fixed up some of the filter logic in my library too.  Have proven that it works correctly (call & response succeeds when filter + mask combinations favor it, and fails when they don't).

 

Now time to start writing applications for this shizzle!

First up will be a can_printf() routine for dumping data over the CAN bus to a specified msgid, with a Nokia 1202-enabled receiver that will dump it out onto the LCD.  Unfortunately I don't have my Nokia 1202 LCD with me so that will have to be a playtoy for a later time...

[spirilis 1,265]

tossing this in for my own reference-

Tiva-C CAN pins-

+--------+-----------+-------------+--------------------------------------------------+
|IC pin# |  Port ID  | CAN Pin ID  | LaunchPad Alt. Funct                             |
---------+-----------+-------------+---------------------------------------------------
| 17     |  PA0      |  CAN1Rx     | Backchannel UART RX, breakout not available      |
| 18     |  PA1      |  CAN1Tx     | Backchannel UART TX, breakout not available      |
| 28     |  PF0      |  CAN0Rx     | Pushbtn 2, TEST line on MSP430's but not here.   |
| 31     |  PF3      |  CAN0Tx     | Green LED                                        |
| 57     |  PB5      |  CAN0Tx     | Analog 11, J1.2 pin location                     |
| 58     |  PB4      |  CAN0Rx     | SPI SCLK                                         |
| 59     |  PE4      |  CAN0Rx     | Analog 9, J1.5 pin location                      |
| 60     |  PE5      |  CAN0Tx     | Analog 8, J1.6 pin location                      |
+--------+-----------+-------------+--------------------------------------------------+

[spirilis 1,265]

Heh, writing an autonomously-managed TX function for dumping arbitrary amounts of data over the CAN bus... and ended up having to come up with a flowchart (posted for amusement)-

[dubnet 238]

That character based flowchart must have taken just a little bit of time to compose....

[spirilis 1,265]

That character based flowchart must have taken just a little bit of time to compose....

Yes... The code ended up taking a lot less time to compose too  The flowchart was drafted out on paper beforehand but I wanted to include it for reference.

Maybe I should do this more often!

[Rickta59 589]

Heh, writing an autonomously-managed TX function for dumping arbitrary amounts of data over the CAN bus... and ended up having to come up with a flowchart (posted for amusement)-

can_managed_tx_flowchart.png

http://www.asciiflow.com/#Draw .. useful for doing character based graphics

[spirilis 1,265]

Managed to discover flow-control (not that I didn't know about flow-control, but it's always fun to "rediscover" it in each new communications system) while doing a can_printf that bursts data as fast as it can (stuffing all the TXB's).  And a bug in my error handling, which was a good reason to do that... and then rediscovered the concept of priority in the MCP2515's TX buffers, so in the end I redid the can_printf function to only utilize TXB#0 and adding an option to introduce a delay between each transmit.  Might work out a simple flow-control reply next, but maybe not, I should save my time for more worthy endeavours (like learning the CANOpen protocol or whatnot).

[spirilis 1,265]

In preparation for releasing this BoosterPack through the 43oh store, here's the hardware design files:

 

DipTrace schematic + PCB layout: SPI_CAN_BPak_draft2_1.zip

Elecrow/Seeed/ITead gerbers: Elecrow_SPICANv21_5x10.zip

OSHpark gerbers: OSH_SPICANv21.zip

 

Going to do a writeup shortly detailing the board and its features.

[spirilis 1,265]

Writeup & Hardware Guide-

 

The CAN BoosterPack will be detailed here with its various features illustrated.

 

This BoosterPack features the NXP TJA1051T/3 CAN transceiver and optionally Microchip MCP2515 SPI CAN controller.  A Microchip MCP1725 LDO voltage regulator is provided for convenience when a LaunchPad is being powered by the CAN bus wiring, and a TI TPS27081A current-limiting switch is featured for inrush current limiting on bus-powered slave nodes.

 

This BoosterPack by itself is not suitable for connecting to automotive OBD-II systems, such as those found in all cars made starting 2008.  I am producing a separate adapter board that will be suitable for attaching an OBD-II cable to this BoosterPack.  It will power the BoosterPack through a buck converter stepping automotive 12V down to 5V too.  More on this later.

 

First off, when purchasing the CAN BoosterPack, you receive the following items inside an antistatic bag:

 

Partially assembled CAN BoosterPack with loose Microchip MCP2515, 16MHz XTAL and 47uF electrolytic capacitor.  No boosterpack headers supplied; you will need four 1x10 (or two 2x10) stackable or female headers to attach this to a 40-pin LaunchPad.  Optionally you can work with just the outer headers, e.g. for MSP430G2 launchpads; a pair of 1x10 headers will suffice.

 

An important feature of this boosterpack is the "Mirror pins" -- both sides of the BoosterPack footprint include 4 rows, not 2.  The outermost 2 rows on each side are the actual BoosterPack pins; stackable or female headers should be soldered to these so they may attach to a LaunchPad.  The innermost 2 rows of pads provide a mirror of the BoosterPack rows; the very inner-most row mirrors the innermost BoosterPack rows (referred to as headers "C" and "D" in BYOB terminology) and the next-to-inner-most row mirrors the outermost rows.  Look closely and you can see the copper traces attaching the mirror headers to the main headers.  This allows you to cleanly remap I/O functions to alternate BoosterPack pins, typically involving cutting a solder-jumper and running a jumper wire to one of these Mirror pins.

 

This boosterpack requires 5V for the CAN transceiver hardware; all 40-pin LaunchPads provide this as part of the inner-left header (header "C"); but for the MSP430G2 LaunchPad, the "5VTAP" pin must jumper to the TP1 test point behind the LaunchPad's USB port:

 

Note that if you choose to *power* the MSP430G2 node from the CAN bus remotely via the VBUS line on the RJ45, then you can omit that jumper wire.

 

For the LaunchPads lacking a native CAN peripheral, the Microchip MCP2515 SPI CAN Controller is provided (surface-mount SOIC-18) and the bulk of the left-half of the BoosterPack is dedicated to routing the I/O pins for this controller and allowing the user to re-map them if they so desire.

Note: When soldering the MCP2515, make sure to solder it *before* the 16MHz XTAL.  The XTAL will get in the way of a few of the pads otherwise.

 

 

Default pinouts conform to the TI BYOB standard; SPI likewise matches the USCI pinout for MSP430G2 LaunchPads.  A number of signals are not hooked up by default, but have pass-through pads provided so the user can run jumper wires to the requisite boosterpack "mirror" pins as they desire; these include CANSILENT (routed to the CAN transceiver's SILENT pin) and the MCP2515 GPIO/FUNCT header.  Those pins provide alternate methods of triggering & interrupting CAN I/O and their details are covered in the MCP2515 datasheet.

 

A CAN system is typically split between the Controller, which is part of an MCU or a peripheral (like the MCP2515) controlled by the MCU, and the Transceiver.  The transceiver talks native CAN differential signals, and communicates back to a *single* controller using a CMOS interface involving a CAN_RX line and CAN_TX line.  These communication lines are broken out to a pair of pins, and solder-jumpers connect them to the MCP2515.  If you do not populate the MCP2515 IC, you can leave the solder jumpers in place, otherwise you should cut them before routing CAN_RX/CAN_TX to anything else.  These pins run at Vcc voltage (3.3V or 3.6V depending on the LaunchPad).

 

 

The use of these CAN_RX/CAN_TX pads are the method used for allowing this BoosterPack to attach to a native-CAN MCU such as the Tiva-C or Hercules.  For the Tiva, solder these pads to boosterpack mirror pins corresponding to the Tiva's available CAN RX and TX lines; for Hercules, the CAN lines are on the separate header to the upper right of the BoosterPack footprint, and a pair of jumper wires will be required.

 

Focusing on the CAN Transceiver, connector and power side-

 

The CAN BoosterPack features a pair of RJ45 ports facilitating the creation of a true LaunchPad CAN "bus".  Split-Bus Termination is featured using a pair of 60R resistors and 4.7nF capacitor; a pair of jumpers are provided to disconnect this termination circuit.  The RJ45 pinout follows a standard found here (RJ style)- http://www.interfacebus.com/Can_Bus_Connector_Pinout.html

 

Pin 1,2 represent the CAN bus (CAN_H/CAN_L), pins 3 & 7 are GND, and pin 8 carries VBUS (5V).

 

The connection between VBUS and the BoosterPack is dictated by a jumper called DIR/LIM.

 

DIR connects VBUS to a polyfuse leading to the LaunchPad 5V rail, and this is intended to be used by a LaunchPad+CAN BoosterPack node that is *providing* power to other nodes via its 5V rail.  Since there is no inrush current limiting provided by this method, it is not recommended for slave nodes that are powering themselves via the RJ45 interface.

 

LIM connects VBUS through an inrush-current-limiting circuit to the 5V rail on the BoosterPack; this provides safer charging of the onboard capacitor and initiation of the MCU without adversely dropping the VBUS voltage for other nodes.  Note that CAT5 cabling is not designed to carry a lot of power; and long runs add further impedance, making a large network of slave nodes powered by one LaunchPad potentially problematic, but YMMV.

 

When using the VBUS signal in any way, it is recommended to install a capacitor at either C1 (SMD 1206 pads) or C3 (electrolytic capacitor, like the one included in the kit).

 

If you do not wish to connect the LaunchPad+BoosterPack to the VBUS line of the RJ45, simply remove the DIR/LIM jumper altogether.  This is important also if the VBUS line operates at a voltage other than 5V; for example, 12V or 24V.  Some alternative RJ45-CAN implementations may do this.

 

Lastly, down below is an LDO voltage regulator providing 3.3V to power the LaunchPad's Vcc rail.  This is used for instances where the node is powered by the RJ45-CAN VBUS signal and does not have an onboard regulator converting 5V to 3.3 or 3.6V for powering the MCU (or if it does, you are choosing not to use it for one reason or another).  It may be disconnected from the Vcc rail by pulling the LDO_EN jumper; an optional feature (disabled by default) allows the LDO voltage regulator to suspend the RESET line of the LaunchPad until its voltage is nominal.  This feature can be enabled by shorting solder-jumper SJ4, just behind the LDO_EN jumper.

 

The LDO is a Microchip MCP1725, 3.3V and up to 500mA.

[spirilis 1,265]

So far I only have experience with MSP430 + MCP2515, haven't toyed with the Tiva-C or Hercules yet.  Going to play with Tiva-C CAN soon.

[bluehash 1,581]

Big thanks! This will be on the store shortly.

[Jb88 0]

Any specific reason you did not go with a SN65HVD1050 or SN65HVD255 transciever by TI? I'm working on putting together a custom board design using the Tiva C series and SN65HVD255 transciever for my S.D. project. Just curious.

[spirilis 1,265]

Any specific reason you did not go with a SN65HVD1050 or SN65HVD255 transciever by TI? I'm working on putting together a custom board design using the Tiva C series and SN65HVD255 transciever for my S.D. project. Just curious.

I had some TJA1051T/3's in my parts bin already. Lots of transceivers could be used for this

 

Sent from my Galaxy Note II with Tapatalk 4

 

 

[bluehash 1,581]

The CAN BoosterPack is now available for purchase in the 43oh Store.

Thanks @@spirilis!