Forums

MSCAN problem

Started by Unknown October 1, 2002
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/




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



Attachment (not stored)
J1939_task.h
Type: application/octet-stream

Attachment (not stored)
J1939_task_wa.c
Type: application/octet-stream


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:a...@pmc-controls.com]
Sent: Tuesday, October 01, 2002 8:01 AM
To: Richard Ki; m...@yahoogroups.com
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:  a...@pmc-controls.com
http://www.pmc-controls.com
-----Original Message-----
From: Richard Ki [mailto:r...@saeautom.sk]
Sent: Tuesday, October 01, 2002 3:03 AM
To: m...@yahoogroups.com
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:r...@saeautom.sk]
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:  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 ">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:  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.


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
__________________________________________________



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



> 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?



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/


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/> .