CAN problems

[pbrew1]

I have two pic18f458s smd ,connected by a can network. Node#1 is just sending, node#2 is just reading. If node#2's pic is running , then node#1 stops sending(both can driver and pic). Ocasionally the node#1 will transmit and the other node will correctly receive data.

pic is running at 40M
can running about 71khz
can driver mcp2551 smd

Thanks for any info as I have run out of things to try.

Paul

[PCM programmer]

1. Did you build the hardware yourself, or did you buy a development
board ?

2. If you bought the board (or boards), what brand and model are they ?

3. If you built it yourself, do you have the 120 ohm terminator resistors
on each end of the bus ?

4. What driver software are you using ? The CCS drivers ?

5. What is your CCS compiler version ?

6. Why the 71 KHz speed ? Why not 125 kbits/sec or one of the
other "standard" speeds ?

[pbrew1]

I build the hardware myself using TQFP44 18f458 pic

There is a 120 ohm resistor on each board next to can driver

Using CCS 3.226

I was using speed set by ccs sofware, I then changed the can_brg_prescalar from 4 to 20. Did not help anything. No reason for the specific speed, just thought slowing it might help.

Node 1 will transmit when node 2 has power but not when pic is running.
The can line goes to its recessive state of about 2.5V for each line.

[Guest]

Post your code.

You do know that when only 1 module is running that it is not 'sending' valid messages right? It will send a message but it will report back that there was an error since no other modules set the ACK bit at the end of its message.

CAN needs at least 2 modules to work. Both pics must be ON and have can modules enabled/ready.

If you are sending message with node 1 while node 2 is off or in the listen-only mode and node1 reports no errors and successful transmission, you have a problem. Most likely in that case that you have node1 in loopback mode.

Make sure both nodes are in normal mode when you do a live test. And really, you should use loopback to test each one seperately, THEN connect them in normal.

That is what loopback is for.

[PCM programmer]

[sjbaxter]

Paul,

You might also want to look at this thread:

Can you help?

This also addresses some of the main problems encountered when getting CAN up and running.

A post of your code would really help to narrow down the problem.

You may also need to think about CAN_ENABLE_DRIVE_HIGH. This by default is zero. Depending upon the CAN tranceiver, you may need to set this to 1. otherwise the transmit line from the controller/PIC to transceiver will float giving very unpredictable results.
_________________
Regards,
Simon.

[Guest]

You don't need a DRIVE_HIGH with a MCP2551.

[sjbaxter]

Wasn't sure when I posted it, but I think it is worth mentioning.

I use the Philips PCA82C250/251 tranceivers which do need it setting to 1.
_________________
Regards,
Simon.

[pbrew1]

I used bit timing calculator and set baud to 125 kps. It now works fine. Never suspected abitrarily choosing TQ would cause problems. Why is it that when I search for "can" (on this forum) I don't get any results?

Thanks for all the help, don't think I would have ever got very far without it.

Paul

[sjbaxter]

Maybe the moderators need to add a few extra forum categories to the main forum page based on device capabilities, i.e. CAN, ADC, SERIAL, GENERAL I/O, LIN, TIMERS, HARDWARE INTERFACING, etc

Also areas for specific topics such as the IDE and COMPILER versions.

rather than just GENERAL CCS C DISCUSSION and CODE LIBRARY.

I know this is a CCS C forum, but it can be broken down into different categories to make life a bit more ordered.

Examples:

Hauppage Forum

even the phpBB forum is a good example !!!

phpBB Forum

Come on Darren ...
_________________
Regards,
Simon.

[Guest]

What issues could anyone see if I had 13 nodes on a network (with about a meter of cable) interms of reliability. Should the 120 ohm terminator be on every node as we get it to work when we only put it on the final node on the cable. I'm yet to work out if it is CAN harware but, very rarely, I am only able to get comms between 7 or so nodes where each has an individual address. it's one of those intermittent things. Even if i recycle the power on the network, still certain nodes won't repsond that should default to a 'listen' stage when freshly programmed. My code works 95 times out of a 100 which is why i believe it could be hardware? I've not done anything with CAN speeds so I would assume they are set to default. It's not a major issue at the moment, I thought someone might have an obvious suggestion?

Cheers

[sjbaxter]

You should only have 2 x 120ohm resistors on a network. They should be at the furthest ends of the network spine. They are there to prevent signal reflections.

I have a network with 42 nodes that run without any problems at all ! I have worked on networks with 80+ nodes on them.

The network should look like:

[Guest]

Thanks for that, that is the arrangement i have. I have sorted the addressing out with a home made algorithm that seems to work pretty well. I'm looking in my code for an area that it could get stuck in, it appears that a power recycle doesn't do anything at times when the system is locked up (actually when some nodes are locked up). I get can errors displayed by a master node when 13 nodes are sending stuff out simulataneous but the system carries on doing what it should. how do you know the bus load? I do use hardware filtering.

I have noticed the system changes if you add and remove nodes (this either removes a node that is locked up, or it alter the can performance i guess).

I have to confess, I don't know what speed the bus is!!

a message is sent from each node about every second.

[sjbaxter]

You can measure bus load with some tools (i.e CANKing and the microchip CAN dev board give you a rough figure). You can calculate it based on the message length (in bits) roughly assume around 120 bits, the bus speed and number of messages sent in a second. Its a ROUGH estimation. You need a CAN controller with this built into the hardware to do it properly.

Nodes will appear locked up if they can't empty their TX buffers (it stays there retrying on the bus until it gets an ACK from someone or the TX Error count makes the node error passive or bus off) if you sit waiting for the buffer to empty before TX.

In this case, a hardware error will cause your code to block. I usually have a timeout on TX buffer empty check of a few milliseconds, it the buffer doesn't empty in that time I assume there is 'trouble on the bus' or no other node on the bus and retry again later. If a retry count reaches a certain value then I flush the tx queue, set an LED showing the status (BUS ERR) and try going bus on again in a couple of seconds.

Remember, CAN is not deterministic (i.e. timing is un-predictable), so if a message can't be sent, don't send it ! just try again later. That approach alone will prevent the nodes locking up.

If you get to that point and the messages still don't get sent, then it is a hardware or mis-match in timing problem.

When I created a PIC based USB-CAN interface, it took quite a bit of error checking and bus on/off control before I got a robust node that wouldn't cause errors, or be affected by errors, on the bus.

Your not getting a deadlock occuring in your 'protocol' between nodes are you ?

If you haven't already got some CAN monitoring device (ie. PC interface), I suggest you do. As troubleshooting/developing CAN networks on anything more than 2 or 3 nodes can be tricky.

I'm curious to know ... what is the project ?
_________________
Regards,
Simon.

[Guest]