G120HDR Rev2 CAN ports

NETMF & Gadgeteer
#1

I’m trying to get CAN communications working with my G120HDR Rev2 but can’t seem to get any output on the CAN pins. I’ve looked over the two other related posts with CAN timing and possibly dead ports, but they both seemed to just dry up about 5 months ago. Rather than throwing Thread Necro, I figured a fresh thread would be more useful.

I’ve successfully set/cleared the pins (P0_0, P0_1, P0_4, P0_5) using the following, so I don’t believe it’s blown those pins:

OutputPort port = new OutputPort(GHI.Hardware.G120.Pin.P0_1, false);
while (true)
            {
                port.Write(!port.Read());
                Debug.Print("Pin P0.1: " + port.Read());
                Thread.Sleep(100);
            }

The really strange part is that the debugger falls down after a few dozen cycles of this, but the board keeps plugging away:

    #### Exception System.NotSupportedException - CLR_E_NOT_SUPPORTED (1) ####
    #### Message: 
    #### Bit_toggle.Program::Main [IP: 002c] ####

This is thrown at Thread.Sleep and happens completely at random.

Here’s what I’ve got for software:

Firmware 4.2.10
Latest .net and GHI libraries (4.3?)
Visual Studio 2012 Express
Win7 Enterprise x64

The only other thing I can come up with is that I need to manually set the registers to activate the CAN functionality on those pins…

#2

At this point I’m trying to verify that the pins are working. I tried the demo code from the other thread, but the results were the “CanBus Off” error and no output from the CAN1_TD and RD pins on the G120.

The end goal is to have CAN communications on both CAN ports through CAN transceivers (MCP2551). The transceivers are connected to a National Instruments CAN module to verify that there is traffic on the bus and respond to the G120.

#3

Correct–I am not using the CAN_DW module. Instead I am using an MCP2551 CAN transceiver.

I do have the CAN_DW module and a FEZspider–which works exactly as expected with the sample code–but the spider only supports one CAN channel natively and my project requires two on the same board.

#4

The other device is a National Instruments USB-8473 high-speed CAN module. I have only used 500kbit so far, and the spider/DW combination works at that speed.

I’ll see what I can do with connecting the DW to the ‘user’ port on the G120HDR and also try the lower bit rate, but that will have to wait until tomorrow.

Thanks for the suggestions!

#5

I haven’t had a chance to get back to this yet–the transciever hardware has priority over the CAN software right now–but I should be able to work on it again next week.

#6

No luck with changing the baud rate. I tried re-flashing the firmware but that hasn’t helped either.

I don’t have an easy way to connect the CAN DW module to the G120HDR yet, but I think I can make a quick wire harness to connect to the USER header. I don’t have a quick solution for connecting the transceiver chip to the FEZspider: no easy way to get the .05" pitch header broken out without destroying the cable.

What I’m getting at this point is a single posted message (debugger output is 1, 0, 0, …) but no errors. I’ll have to get out my scope and see what kind of output is showing up on the CAN TD/RD pins and make sure that it’s at least attempting to communicate with the transceiver.

#7

Do you have another working CAN device on the network? It doesn’t have to be transmitting. A listener a the same bus speed and settings is enough to confirm it it working.

If you do not, the transmitting CAN device will quickly go to BUS OFF if there is no acknowledge of the transmitted message.

You might thought still detect that initial burst on the bus.

#8

@ Dave - yes, as stated above I have a CAN device connected directly to the transceiver board, and the device has been verified to work at 500kbaud with the FEZspider and CAN_DW module. The behavior I’m seeing from the G120HDR is a lack of any output on the CAN_TD/CAN_RD pins. In fact, CAN1 is always low and CAN2 is always high. There is some noise on the scope traces, but no 5V switching happening. The transceivers are MCP2551 in DIP-8 form. Those are pretty straightforward, so I don’t understand where the problem may be.

My thought at this point is that the registers aren’t being initialized properly, so I’m doing a crude dump of the registers listed in the manual for the LPC1788. As far as I can tell, all of the relevant registers are initialized and configured correctly, but I don’t know how that carries over from the source code to the deployment.

PCONP (&0x6000): 0x6000 -> pins 14 & 13 are high
PCLKSEL: 0x02 -> correct?
CAN1BTR: 0x7E0004 -> BRP = 5, T1 = 15, T2 = 8
CAN2BTR: 0x7E0004 -> (same)
IOCON_P0_0: 0xA1 -> set to: pu/pd resistor inactive, CAN_RD1
IOCON_P0_1: 0xA1 -> set to: pu/pd resistor inactive, CAN_TD1
IOCON_P0_4: 0xA2 -> set to: pu/pd resistor inactive, CAN_RD2
IOCON_P0_5: 0xA2 -> set to: pu/pd resistor inactive, CAN_TD2
CAN1ICR: 0x00 -> default?
CAN2ICR: 0x00
CAN1IER: 0xA9 -> not sure which of these settings are needed…
CAN2IER: 0xA9

I’m going to try the CAN_DW module tomorrow (or some time this week) once I get a breakout module for the gadgeteer headers, but I’m running out of ideas for things to try.

#9

I decided to measure the voltages with the transceivers disconnected:
On RESET: 3.3V all pins.
Steady state:

P0.0/CAN1_TD 3.3V
P0.1/CAN1_RD 0V
P0.4/CAN2_TD 3.3V
P0.5/CAN2_RD 0V

Running the code with the VS debugger shows only one posted message total for each CAN port, but no BusOff errors on either port.

Reconnecting the transceivers resulted in the following:

0V on both CAN1_TD and CAN1_RD (RESET and steady state)
5V CAN2_TD and CAN2_RD (RESET)
3.3V on CAN2_TD and 5V on CAN2_RD (steady state)

The debugger shows CAN1 only posting once and reports no errors. CAN2 posts all 10 times, but throws a BusOff error each time.

P.S. Sorry for all the edits, there’s no preview feature.

#10

why are you seeing 5v? The micro will only drive at 3v3 so there’s no way you should be seeing that. Are you sure you have the MCP2551 wired correctly with TX/RX crossed?

#11

Ok, back to square one: I’m going to assume there are some shorts on the circuitboard and try a breadboard instead. I can’t think of any other reasons for those pins always reading 0V when connected to the transceiver board.

#12

I would expect that CAN_TX on the micro side can only go to a maximum of 3v3. That is an output pin from the micro.

I note that the datasheet is explicit in it’s TXD RXD terminology; TXD is an INPUT into the MCP device, so is connected to CAN_TX on the micro, and RXD is the OUTPUT of the MCP device so gets connected to CAN_RX on the micro. I hate UART dyslexia https://www.sparkfun.com/products/449

#13

OK, I’ve got good news and bad news.

The good news is that the code is now working as expected on the G120HDR with an MCP2551 at 500k.

The bad news is that there were multiple shorts on the transceiver board, several to ground and a few to +5V. That explains all of the “strange” behavior. That also means I have potentially 70 bad boards to diagnose and rework.

To clarify the other point of confusion, CAN1_TD (G120) connects to TXD (MCP2551) and CAN1_RD connects to RXD. I also connected a 120 Ohm resistor across the CAN_H and CAN_L pins on the MCP2551, though it probably isn’t needed with only 4 cm wires.

In summary, the G120HDR (Rev 2, firmware 4.2.10) works with the MCP2551 at 500k.

#14

So how do I mark my own answer as the solution? Just mark one next to it?