rlieb
Joined: 19 Jul 2012 Posts: 2
|
PIC18F4680 CAN bus |
Posted: Thu Jul 19, 2012 8:15 am |
|
|
Hi all,
I want two 18F4680 to talk to each other via ECAN (modified ex_can.c).
Both run @40M (of a 10M xtal).
Code: |
BRGCON1 = 0x00;
BRGCON2 = 0xba;
BRGCON3 = 0x07;
|
In principle it works. But what do I have to do with the registers to overcome a unplugged cable?
The only hint I found in the manual is, that it should be dealt within the error interrupt.
At the moment it needs >40 seconds to come back to life after. And I still get CANERR interrupts.
Regards |
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Thu Jul 19, 2012 9:03 am |
|
|
The error flags of the CAN and ECAN are confusing. They, apparently, behave as specified in the CAN specification, but that doesn't seem to be in a way that's useful in the real world. The error flag is set when either the receiver or transmitter reports more than a specified number of errors. In the case of the transmitter that's 96 errors... why? Don't know, it just is.
When you disconnect a CAN node, nothing much will happen provided it doesn't try to send. It cannot detect a disconnected bus without sending. When it does try to send, it doesn't receive any acknowledgement and so it retries until either it *is* connected to something - note ANY node will acknowledge any packet, not just ones its listening for, so just becuase the message was acked, that doesn't mean it got through to the intended receiving node/s - or your code gives up and stops aborts the transmission. Becuause of buffering - there are three transmit buffers in the default config of both CAN and ECAN peripherals - you cannot be certain which message you try to send generated an error, only that an error occurred while trying to send a message. Also until the error condition clears, the ECAN will not allow further messages to be buffered for transmit, and the CCS CAN driver firmware then blocks, waiting for a free buffer.
When you do get another node to respond, such as when you connect the bus up correctly, then the transmit error count is decremented for each message successfully sent. The error flag is cleared when the count reaches zero again. How long that takes depends on how often you send messages. In my case that's around 5 seconds, in your system its obviously longer.
I have tried to use the interrupt to abort sending messages and restart when one is successfully received, thus managing the error state of the ECAN. I hav egiven up trying to get it to work as no matter what I did I could not get reliable CAN comms after clearing an error. In the end I gave up and simply let it to its own thing. I have my own design of CAN to USB adaptor box for PC monitoring/control of our systems, and its a nice party trick to do a count down to when the error light goes out. Techs not familar with this are suitably impressed!
My advice: don't fight it. Understand what it does and why it does it, but let it do its own thing.
RF Developer |
|