| View previous topic :: View next topic |
| Author |
Message |
spesh
Joined: 28 Mar 2006
Posts: 10
|
| PIC18F6680 CAN Errors - How to clear ? |
 Posted: Thu Oct 06, 2011 7:43 am |
 |
|
I am developing some CAN software using the PIC18F6680. Everything seems to work fine until I deliberately transmit at the wrong bit rate. After this, if I reset the bit rate to the correct one I am unable to receive any more messages even though I can see them going to/from the slave on my scope. The PIC therefore must be transmitting the CAN frames OK but it is unable to receive any more.
My main question is : what is the prefered method for recovering from such an error. Which SFRs do I need to clear (i.e. which ones will stop the CAN module from receiving). Also, how do I clear the RXERRCNT as this is a R/O register.
Thanks
Alan |
|
 |
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Thu Oct 06, 2011 9:36 am |
|
|
As far as I can see you can't actively clear the register, nor do you need to to get the CAN/ECAN module to work. The error count will count down as the module receives good messages.
I've tried to detect errors and stop transmitting if they occur. I've not been able to get it to work reliably for some unknown reason so I've stopped worrying about the error counts, other than for CAN monitoring purposes.
What I was trying to do was to avoid hanging up a singleton node. This is because if a lone node tries to send, there is no other node to acknowledge, which is a transmit error. It will eventually exceed the error counts and the module will effectively refuse further message requests as its send buffers will be full. The module will then continually resend the highest priority message in its buffers. If any other CAN node is connected, it acknowledges the message and the buffered messages in quick succession and the first node can continue. I was trying to avoid this by detecting the errors and shutting down sending until the counts had "recovered" sufficiently. I never got this working sufficiently well to decide what "recovered" meant. The trouble seemed to be that the CAN module got confused in some way and lost data. I found it simpler to live with the hanging up...
In your context I have to ask why you are changing bit rates on the fly? CAN nets are meant to operate at one rate. If a node needs to connect to the net it has to operate at the net's rate. Otherwise any nodes operating at a different rate will generate errors of one sort or another.
If you are doing something like a CAN monitor then its probably sensible to treat a bit rate change as a complete CAN module restart. Turn it off, turn it back on and reconfigure from scratch.
RF Developer
RF Developer. |
|
|
spesh
Joined: 28 Mar 2006
Posts: 10
|
|
| Posted: Thu Oct 06, 2011 1:05 pm |
|
|
Thanks for that. That's all useful information about your own experiences. I am basically developing an interface board which has to talk to one CAN device at a time and as part of the testing I tried transmitting messages to the slave at a known wrong bit rate just to see if it would recover.
When you mention a "complete CAN module restart", what exactly do you mean by this ? I am using the CAN drivers which come with the CCS compiler ("can-18xxx8.c") and use a modified version of the can_init() function which I pass the desired bit rate to. Would this do the CAN module restart you mention ?
Thanks
Alan |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Fri Oct 07, 2011 1:55 am |
|
|
| spesh wrote: | | I am basically developing an interface board which has to talk to one CAN device at a time and as part of the testing I tried transmitting messages to the slave at a known wrong bit rate just to see if it would recover. |
Yes, that qualifies as a "CAN monitor" type application :-)
| Quote: | | When you mention a "complete CAN module restart", what exactly do you mean by this ? I am using the CAN drivers which come with the CCS compiler ("can-18xxx8.c") and use a modified version of the can_init() function which I pass the desired bit rate to. Would this do the CAN module restart you mention ? |
No, I don't think it would. I also use the same driver, and I haven't modified it (well I did to try and solve the errors thing) to change baudrate. Instead I call can_init() which sets the drivers default of 125kbps - unless you override the defines of course - and then call can_set_mode(CAN_OP_CONFIG) followed by directly setting the BRGCON regs with my baud settings. I also set my message filters at this point and final put the can into normal mode.
Anyway back to the point. can_init() requests config mode, and then waits for the can module to get in to config. That means waits for the bus to go quiet. But if the module is stuck continually resending due to errors it probably wont go to config. So, I don't think can_init() on its own will work.  Instead I'd try forcing the can module into disabled using can_op_mode(CAN_OP_DISABLE) effectively turning it off altogether. Apparently it should honour this immediately hopefully regardless of state. Whether it actually does is another matter of course; I've not tried it.  If it does work, then calling can_init() or your modified version hopefully will bring the CAN module back online. This is all warm start behaviour, which may differ from a cold start. Microchip rarely appear to specify warm start behaviour. It might be that ONLY a hardware reset, or even worse a power cycle, will totally clear the CAN module. I hope that is not the case. As I wrote before, I've found it safest not to fiddle with the CAN module if I can avoid it: set it up and leave it running, and leave the lid firmly on the worm can.
RF Developer |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
