|
I have following problem with DSP56807 CAN controller: Using 56807 in CAN application in classic way : 'TX empty' interrupt routine fills the MSCAN registers with new message from the FIFO buffer. Received CAN messages are processed in 'Rx full' interrupt routine... The problem is with transmitting. Everything working well while not 'too big' data transfer on CAN bus. Application should receive cca 300 CAN messages in 1 sec. When this data transfer is present on bus, some of CAN messages transmitted from MSCAN are missing, strictly speaking they are taken from FIFO, written to CAN controller but not transmitted to bus (i don't see them on the CAN bus monitor)... I tried to find problem in software but didn't find nothing, looks like a DSP56807 MSCAN problem. Has somebody the similar problem or do somebody know where the problem can be? Thanks, Richard Kis [mailto:] http://www.saeautom.sk/ |
|
|
MSCAN problem
Started by ●October 1, 2002
Reply by ●October 1, 20022002-10-01
|
We are also having a problem with the CAN transmitter in a DSP56F807 chip.
Our problem occurs when we cause an error such as a missing ACK. In this case the program crashes very badly. We are working to determine the cause of the problem, it might be in our source code, or it might be a CAN controller problem. We have discovered another problem with the MSCAN controller in the DSP56F80x chips. This problem, and a work-around to fix the problem, are described in the attached email. 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 -----Original Message----- From: Richard Ki [mailto:] Sent: Tuesday, October 01, 2002 3:03 AM To: Subject: [motoroladsp] MSCAN problem I have following problem with DSP56807 CAN controller: Using 56807 in CAN application in classic way : 'TX empty' interrupt routine fills the MSCAN registers with new message from the FIFO buffer. Received CAN messages are processed in 'Rx full' interrupt routine... The problem is with transmitting. Everything working well while not 'too big' data transfer on CAN bus. Application should receive cca 300 CAN messages in 1 sec. When this data transfer is present on bus, some of CAN messages transmitted from MSCAN are missing, strictly speaking they are taken from FIFO, written to CAN controller but not transmitted to bus (i don't see them on the CAN bus monitor)... I tried to find problem in software but didn't find nothing, looks like a DSP56807 MSCAN problem. Has somebody the similar problem or do somebody know where the problem can be? Thanks, Richard Kis [mailto:] http://www.saeautom.sk/ _____________________________________ 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 More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ | |||
|
From:
"Art Johnson" <> Date: Mon Sep 16, 2002 10:20 pm Subject: Work around for DSP56F807 MSCAN Error Interrupt failures To: "Mann Michael-r47920" <> | |||
|
I have developed a work around that solves this problem. On doing further testing I noticed that when the failure occurred, one of the following conditions was always true: 1) MSCAN_RWRNIF and MSCAN_RERRIF were both active, or 2) MSCAN_TWRNIF and MSCAN_TERRIF were both active What the work around does is to count how many Rx Warning/Error or Tx Warning/Error interrupts have occurred recently (in the last 25 milliseconds). If this number is excessive (ie more than 10), then both of the interrupts (Rx Warning/Error or Tx Warning/Error) are disabled. The interrupts are re-enabled in the mainline code when the Warning interrupt flag is clear. There are also counters that are incremented when this happens, so you can see that the interrupt failure was caught and corrected. The attached .h and .c files have full details on this work around. I ran this program while doing the same tests as before, and the program never locked up. I then stopped the program using the debugger and looked at the values of the MSCAN registers and global memory locations. The results are as follows: Register/ Memory Loc. Value ctl0 0x0010 ctl1 0x0081 btr0 0x00C6 btr1 0x007B rflg 0x0010 rier 0x006D tflg 0x0007 tcr 0x0000 idac 0x0000 rxerr 0x0087 txerr 0x0000 J1939_rx_warnings 36 J1939_rx_errors 30 J1939_rx_err_idis 6 J1939_tx_warnings 6 J1939_tx_errors 10 J1939_tx_err_idis 2 J1939_bus_offs 18 This work around may also be applicable to other Motorola devices using this style of MSCAN module, specifically the MSCAN12 definition in the MC68HC12 which was used as the basis for the DSP56F80x MSCAN module. If Motorola agrees with this work around, it should probably be added to AN2283. Please let me know if you have any questions or would like any further information regarding this work around. 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 -----Original Message----- From: Mann Michael-r47920 [mailto:] Sent: Saturday, September 14, 2002 10:01 PM To: Art Johnson Cc: Hoefle Richard-rvfr10; Hickman Pat-rdnp50 Subject: RE: DSP56F807 MSCAN Error Interrupt failures Got your email. Have forwarded it, along with AN2283, to my tiger team. We will start working on this Monday morning. -----Original Message----- From: Art Johnson [mailto:] Sent: Friday, September 13, 2002 3:19 PM To: Mann Michael-r47920; Hickman Pat-rdnp50 Cc: Ken Andreasen; JB Bjorknas; Greg Clark; Kevin Ackerley (E-mail); Ed Baillie (E-mail) Subject: DSP56F807 MSCAN Error Interrupt failures We are having failures associated with the DSP56F807 MSCAN Error Interrupts. This is on a Rev D chip (date code ZKAA0140). I will describe the failure in general terms first, and then go into greater detail. What is happening is that we are intentionally generating error interrupts by shorting the CANH and CANL lines to ground, to see that the system recovers from the failures. Occasionally, the system will lock up, and using the debugger I have found that the Error ISR gets executed continuously, so the rest of the program never executes. Our test setup consists of one device transmitting messages, and one device that is receive only. These lockups are occurring on the transmitting device. I can create this lockup fairly repeatably, by shorting the CANH line to ground over and over again. The system will lockup about 1 time out of 20. I have attached the relevant .h and .c files from our program. I wrote the Error ISR according to AN2283. Note that removing the following 2 lines from the Error ISR had no effect on the failures: // Only handle enabled error interrupts rflg &= p_dspmscan->rier; When the failures occur, I stop the program, set a breakpoint at the beginning of the Error ISR, and resume the program. When the program stops at the breakpoint, I look at the values of the MSCAN registers and global memory locations. The results are as follows, for 3 times that I generated the failure: Register/ Memory Loc. Value #1 Value #2 Value #3 ctl0 0x0010 0x0010 0x0010 ctl1 0x0081 0x0081 0x0081 btr0 0x00C6 0x00C6 0x00C6 btr1 0x007B 0x007B 0x007B rflg 0x0050 0x0050 0x003C rier 0x006D 0x006D 0x0060 tflg 0x0007 0x0007 0x0007 tcr 0x0000 0x0000 0x0000 idac 0x0000 0x0000 0x0000 rxerr 0x0087 0x0081 0x0012 txerr 0x0000 0x0007 0x0000 J1939_rx_warnings 22087 24324 24324 J1939_rx_errors 22087 24324 24324 J1939_tx_warnings 0 3 14433 J1939_tx_errors 1 2 14432 I can get the program to recover from the failure, if I use the debugger to set the "rier" register to 0 and resume the program (ie disable all interrupts in the Receiver Interrupt Enable Register). What seems to be happening is that an internal interrupt signal is "stuck on", and doesn't get cleared by the Error ISR. I believe that I have carefully followed all the requirements for writing MSCAN ISRs, as described in AN2283. Please let me know if you have any suggestions on what could be causing these failures, and any work around to fix the problem. 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 | |||
| |||
| |||
|
|
Reply by ●October 1, 20022002-10-01
|
For these kinds of problems, I would suggest to file a technical request with our help line (http://e-www.motorola.com/support/index.html ). This will allow our engineers to look into these issues and help you.
Sincerely,
Leonard N. Elevich Motorola DSPO
-----Original
Message-----
We are also
having a problem with the CAN transmitter
in a DSP56F807 chip. Our problem occurs when we cause an error such as a
missing ACK. In this case the program crashes very badly. We are working
to determine the cause of the problem, it might be in our source code, or it
might be a CAN controller problem. 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: m...@yahoogroups.com To Post: m...@yahoogroups.com To Leave: m...@yahoogroups.com Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 ">Yahoo! Terms of Service. |
Reply by ●October 1, 20022002-10-01
|
We have found the random transmit error which caused CAN transmitter locked out when selected external clock source as CAN clock source. 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. The problem we guess was a synchronization issue which external clock lost the coordination with PLL output clock that clocks all internal logic when in certain circumstances. Please make sure you select IPBus clock by setting CLKSRC bit = 1 in MSCAN Control Register 1 (CANCTL1) as MSCAN clock source. Charlie W. --- Art Johnson <> wrote: > We are also having a problem with the CAN > transmitter in a DSP56F807 chip. Our problem occurs > when we cause an error such as a missing ACK. In > this case the program crashes very badly. We are > working to determine the cause of the problem, it > might be in our source code, or it might be a CAN > controller problem. > > We have discovered another problem with the MSCAN > controller in the DSP56F80x chips. This problem, > and a work-around to fix the problem, are described > in the attached email. > > 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 > > -----Original Message----- > From: Richard Ki [mailto:] > Sent: Tuesday, October 01, 2002 3:03 AM > To: > Subject: [motoroladsp] MSCAN problem > I have following problem with DSP56807 CAN > controller: > > Using 56807 in CAN application in classic way : 'TX > empty' interrupt > routine fills the MSCAN registers with new message > from the FIFO buffer. > Received CAN messages are processed in 'Rx full' > interrupt routine... > The problem is with transmitting. Everything working > well while not 'too > big' data transfer on CAN bus. Application should > receive cca 300 CAN > messages in 1 sec. When this data transfer is > present on bus, some of > CAN messages transmitted from MSCAN are missing, > strictly speaking they > are taken from FIFO, written to CAN controller but > not transmitted to > bus (i don't see them on the CAN bus monitor)... I > tried to find problem > in software but didn't find nothing, looks like a > DSP56807 MSCAN > problem. Has somebody the similar problem or do > somebody know where the > problem can be? > Thanks, > Richard Kis > [mailto:] > http://www.saeautom.sk/ > _____________________________________ > 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 > > More Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/ > ATTACHMENT part 2 message/rfc822 > Subject: Work around for DSP56F807 MSCAN Error > Interrupt failures > Date: Mon, 16 Sep 2002 15:20:11 -0700 > From: "Art Johnson" <> > To: "Mann Michael-r47920" > <> > CC: "Hoefle Richard-rvfr10" > <>, > "Hickman Pat-rdnp50" <>, > "Ken Andreasen" <>, > "JB Bjorknas" <>, > "Greg Clark" <>, > "Kevin Ackerley (E-mail)" > <>, > "Ed Baillie (E-mail)" < > I have developed a work around that solves this > problem. On doing further testing I noticed that > when the failure occurred, one of the following > conditions was always true: > 1) MSCAN_RWRNIF and MSCAN_RERRIF were both active, > or > 2) MSCAN_TWRNIF and MSCAN_TERRIF were both active > > What the work around does is to count how many Rx > Warning/Error or Tx Warning/Error interrupts have > occurred recently (in the last 25 milliseconds). If > this number is excessive (ie more than 10), then > both of the interrupts (Rx Warning/Error or Tx > Warning/Error) are disabled. The interrupts are > re-enabled in the mainline code when the Warning > interrupt flag is clear. There are also counters > that are incremented when this happens, so you can > see that the interrupt failure was caught and > corrected. > > The attached .h and .c files have full details on > this work around. I ran this program while doing > the same tests as before, and the program never > locked up. I then stopped the program using the > debugger and looked at the values of the MSCAN > registers and global memory locations. The results > are as follows: > > Register/ > Memory Loc. Value > ctl0 0x0010 > ctl1 0x0081 > btr0 0x00C6 > btr1 0x007B > rflg 0x0010 > rier 0x006D > tflg 0x0007 > tcr 0x0000 > idac 0x0000 > rxerr 0x0087 > txerr 0x0000 > J1939_rx_warnings 36 > J1939_rx_errors 30 > J1939_rx_err_idis 6 > J1939_tx_warnings 6 > J1939_tx_errors 10 > J1939_tx_err_idis 2 > J1939_bus_offs 18 > > This work around may also be applicable to other > Motorola devices using this style of MSCAN module, > specifically the MSCAN12 definition in the MC68HC12 > which was used as the basis for the DSP56F80x MSCAN > module. If Motorola agrees with this work around, > it should probably be added to AN2283. > > Please let me know if you have any questions or > would like any further information regarding this > work around. 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 > > -----Original Message----- > From: Mann Michael-r47920 > [mailto:] > Sent: Saturday, September 14, 2002 10:01 PM > To: Art Johnson > Cc: Hoefle Richard-rvfr10; Hickman Pat-rdnp50 > Subject: RE: DSP56F807 MSCAN Error Interrupt > failures > Got your email. Have forwarded it, along with > AN2283, to my tiger team. We will start working on > this Monday morning. > > -----Original Message----- > From: Art Johnson [mailto:] > Sent: Friday, September 13, 2002 3:19 PM > To: Mann Michael-r47920; Hickman Pat-rdnp50 > Cc: Ken Andreasen; JB Bjorknas; Greg Clark; Kevin > Ackerley (E-mail); Ed > Baillie (E-mail) > Subject: DSP56F807 MSCAN Error Interrupt failures > We are having failures associated with the DSP56F807 > MSCAN Error > Interrupts. This is on a Rev D chip (date code > ZKAA0140). I will > describe the failure in general terms first, and > then go into greater > detail. > > What is happening is that we are intentionally > generating error > interrupts by shorting the CANH and CANL lines to > ground, to see that > the system recovers from the failures. > Occasionally, the system will > lock up, and using the debugger I have found that > the Error ISR gets > executed continuously, so the rest of the program > never executes. > > Our test setup consists of one device transmitting > messages, and one > device that is receive only. These lockups are > occurring on the > transmitting device. I can create this lockup > fairly repeatably, by > shorting the CANH line to ground over and over > again. The system will > lockup about 1 time out of 20. > > I have attached the relevant .h and .c files from > our program. I wrote > the Error ISR according to AN2283. Note that > removing the following 2 > lines from the Error ISR had no effect on the > failures: > // Only handle enabled error interrupts > rflg &= p_dspmscan->rier; > > When the failures occur, I stop the program, set a > breakpoint at the > beginning of the Error ISR, and resume the program. > When the program > stops at the breakpoint, I look at the values of the > MSCAN registers and > global memory locations. The results are as > follows, for 3 times that I > generated the failure: > > Register/ > Memory Loc. Value #1 Value #2 Value #3 > ctl0 0x0010 0x0010 0x0010 > ctl1 0x0081 0x0081 0x0081 > btr0 0x00C6 0x00C6 0x00C6 > btr1 0x007B 0x007B 0x007B > rflg 0x0050 0x0050 0x003C > rier 0x006D 0x006D 0x0060 > tflg 0x0007 0x0007 0x0007 > tcr 0x0000 0x0000 0x0000 > idac 0x0000 0x0000 0x0000 > rxerr 0x0087 0x0081 0x0012 > txerr 0x0000 0x0007 0x0000 > J1939_rx_warnings 22087 24324 24324 > J1939_rx_errors 22087 24324 24324 > J1939_tx_warnings 0 3 14433 > J1939_tx_errors 1 2 14432 > > I can get the program to recover from the failure, > if I use the debugger > to set the "rier" register to 0 and resume the > program (ie disable all > interrupts in the Receiver Interrupt Enable > Register). What seems to be > happening is that an internal interrupt signal is > "stuck on", and > doesn't get cleared by the Error ISR. > > I believe that I have carefully followed all the > requirements for > writing MSCAN ISRs, as described in AN2283. Please > let me know if you > have any suggestions on what could be causing these > failures, and any > work around to fix the problem. 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 > ATTACHMENT part 2.2 application/octet-stream name=J1939_task.h > ATTACHMENT part 2.3 application/octet-stream name=J1939_task_wa.c __________________________________________________ |
|
|
Reply by ●October 3, 20022002-10-03
|
I found and fixed the problem, it was in our code. The CANbus (J1939) communication task was written by another developer here, and when I looked at his code I found that transmit buffers were being filled up at various places and times in the program. This obviously created the possibility of conflicts in this shared resource. I rewrote the task so that CAN transmit requests are put into a queue, and a single part of the program gets the entries from the queue and puts the required data into the MSCAN transmit buffers. Since doing this the CAN transmitter operates flawlessly, regardless of the errors we throw at it. As I mentioned in my first "MSCAN problem" message on October 1, 2002, I did find and fix a serious problem with the MSCAN error interrupts. We wrote our Interrupt Service Routines exactly according to AN2283/D, "Motorola Scalable Controller Area Network (MSCAN) Interrupts" (please see my message "MSCAN useful information" from last month). We were intentionally generating error interrupts by shorting the CANH and CANL lines to ground, to see that the system recovers from the failures. Occasionally, the system locked up, and using the debugger I found that the Error ISR was being executed continuously, so the rest of the program was never executed. I developed a work around that solves this problem. On doing further testing I noticed that when the failure occurred, one of the following conditions was always true: 1) MSCAN_RWRNIF and MSCAN_RERRIF were both active, or 2) MSCAN_TWRNIF and MSCAN_TERRIF were both active What the work around does is to count how many Rx Warning/Error or Tx Warning/Error interrupts have occurred recently (in the last 25 milliseconds). If this number is excessive (ie more than 10), then both of the interrupts (Rx Warning/Error or Tx Warning/Error) are disabled. The interrupts are re-enabled in the mainline code when the Warning interrupt flag is clear. There are also counters that are incremented when this happens, so you can see that the interrupt failure was caught and corrected. The code to implement this work around is in the message attached to my first "MSCAN problem" message on October 1, 2002, the one just after 8:00am. Please let me know if you have any questions or comments regarding this work around. Thanks very much, to everyone who provided feedback to my request for information. It was a tremendous help to know that others were able to operate the CAN transmitter successfully when all sorts of error conditions were thrown at it. 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 -----Original Message----- From: Leonard N. Elevich [mailto:] Sent: Tuesday, October 01, 2002 12:26 PM To: Art Johnson; 'Richard Ki'; Cc: Greg Clark Subject: RE: [motoroladsp] MSCAN problem For these kinds of problems, I would suggest to file a technical request with our help line (http://e-www.motorola.com/support/index.html ). This will allow our engineers to look into these issues and help you. Sincerely, Leonard N. Elevich Motorola DSPO -----Original Message----- From: Art Johnson [mailto:] Sent: Tuesday, October 01, 2002 8:01 AM To: Richard Ki; Cc: Greg Clark Subject: RE: [motoroladsp] MSCAN problem We are also having a problem with the CAN transmitter in a DSP56F807 chip. Our problem occurs when we cause an error such as a missing ACK. In this case the program crashes very badly. We are working to determine the cause of the problem, it might be in our source code, or it might be a CAN controller problem. We have discovered another problem with the MSCAN controller in the DSP56F80x chips. This problem, and a work-around to fix the problem, are described in the attached email. 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 -----Original Message----- From: Richard Ki [mailto:] Sent: Tuesday, October 01, 2002 3:03 AM To: Subject: [motoroladsp] MSCAN problem I have following problem with DSP56807 CAN controller: Using 56807 in CAN application in classic way : 'TX empty' interrupt routine fills the MSCAN registers with new message from the FIFO buffer. Received CAN messages are processed in 'Rx full' interrupt routine... The problem is with transmitting. Everything working well while not 'too big' data transfer on CAN bus. Application should receive cca 300 CAN messages in 1 sec. When this data transfer is present on bus, some of CAN messages transmitted from MSCAN are missing, strictly speaking they are taken from FIFO, written to CAN controller but not transmitted to bus (i don't see them on the CAN bus monitor)... I tried to find problem in software but didn't find nothing, looks like a DSP56807 MSCAN problem. Has somebody the similar problem or do somebody know where the problem can be? Thanks, Richard Kis [mailto:] http://www.saeautom.sk/ _____________________________________ 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 More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ _____________________________________ 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 More Groups: http://www.dsprelated.com/groups.php3 |
Reply by ●October 8, 20022002-10-08
|
> 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? |
|
|
Reply by ●October 9, 20022002-10-09
|
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 -----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 More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ |
Reply by ●October 9, 20022002-10-09
|
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/> . |
