On the Motorola FAQ site we have posted the following FAQ on the MSCAN peripheral. Problem: My version of the DSP56F80X Users manual recommends that the EXTAL clock be used for the MSCAN clock source. But I wish to use the IP bus clock to get greater flexibility in the rates I can clock CAN bus. I have also found that using the IP bus clock seems to be more reliable in noisy environments. Can I use IPbus clock as the source for the MSCAN module? Answer: The answer is yes you can choose the IPbus clock as the clock source for the MSCAN module by setting the CLKSRC bit in the CANCTL1 register to a one. In fact since the time the manuals were printed we have further tested both the IPbus and the EXTAL_CLK clocking modes of the MSCAN peripheral and found that the IPbus is superior and is now the recommended choice. The IPbus exhibits less clock jitter than the EXTAL_CLK and it has also been found to have greater noise immunity than the EXTAL_CLK source in very noisy environments or board designs. Hence choosing the IPbus clock mode makes for more reliable CAN communications. In addition choosing the IPbus clock mode enables CAN bus transfer rates of greater than 500Kbits/sec. The EXTAL_CLK mode can be used if desired and will meet the CAN bus jitter requirements, but is no longer the recommended source for the MSCAN module clock. This issue can manifest itself in behaviour where the MSCAN has transmission problems. The problem comes from internally misaligned clocks between the IPbus clock used by the MSCAN peripheral and the EXTAL_CLK being used for transmission. Bottom line is if you are experiencing odd behaviour on the MSCAN peripheral and are using the EXTAL_CLK as the CLKSRC clock one of the first things to do is change the source to the IPbus and see if this corrects the issue. Thanks. - Bill -----Original Message----- From: Art Johnson [mailto:] Sent: Wednesday, October 09, 2002 4:50 AM To: dandan67; Subject: RE: [motoroladsp] Re: MSCAN (less of a) problem No, in our tests here the Tx error counter (TEC) stops (like it is supposed to) when trying to transmit into a terminated but empty network. This is according to the description in AN2283/D, "Motorola Scalable Controller Area Network (MSCAN) Interrupts" note number 5 on page 36: 5. The TEC is unchanged when: - Transmitter is Error Passive AND Transmitter detects an Acknowledgement error because of not detecting a dominant [0] ACK AND Transmitter doesn't detect a dominant [0] bit while sending its Passive Error Flag ...(rest of note 5 not shown) Transmitting into a terminated but empty network should satisfy the above, because the CAN transmitter will not get a dominant [0] ACK, and it will also not get a dominant [0] bit while sending its Passive Error Flag. It has worked this way in all our tests here. The only way we have been able to generate Bus Off conditions is to short the CANH line either to CANL or to ground. From the content of your message it sounds like you have already read my message "MSCAN problem" on October 3, 2002, that describes a problem and its work around regarding the MSCAN Rx Warning/Error and Tx Warning/Error interrupts. Can you give us any further details on your test setup? There must be some explanation of why our results are different from your results when transmitting into a terminated but empty network. Thanks. Regards, Art Johnson Senior Systems Analyst PMC Prime Mover Controls Inc. 3600 Gilmore Way Burnaby, B.C., Canada V5G 4R8 Phone: 604 433-4644 FAX: 604 433-5570 Email: http://www.pmc-controls.com <http://www.pmc-controls.com -----Original Message----- From: dandan67 [mailto:] Sent: Tuesday, October 08, 2002 3:33 PM To: Subject: [motoroladsp] Re: MSCAN (less of a) problem > Although the DSP56F80x user's manual recommends to select the > cystal clock source rather than the IPBus clock source > (Page 8-26, Rev. 3), but it is not true. After > switched to the IPBus clock source, we found the CAN > transmit/receive is super reliable, even we put the > device in higher rediated environment such as keying > high energy walkie-talkie above 5 inches of DSP. We > have not experienced any transmitter lockout. This was a complete show stopper for our product yesterday morning but today, after switching off the EXT_CLK and going to the IPBus clock we're back up and running reliably, as in ZERO unexplained retransmits. My firmware group cannot thank you enough for posting this information here. Dan Danknick Celerity R&D PS: Anyone else seen the Tx error counter run straight into Bus Off land when trying to transmit into a terminated but empty network? _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/ <http://rd.yahoo.com/M!9695.2310151.3725769.2113459/D=egroupweb/S05771855:H\ M/A26184/R=0/*http://ad.doubleclick.net/jump/N879.ameritrade.yahoo/B1054521.1\ 1;sz00x250;adc=ZHS;ord34163950?> <http://us.adserver.yahoo.com/l?M!9695.2310151.3725769.2113459/D=egroupmail/S=\ :HM/A26184/rand6717075> _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp <http://www.yahoogroups.com/group/motoroladsp> More Groups: http://www.dsprelated.com/groups.php3 <http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> . |