DSPRelated.com
Forums

Problem with sending 7 and 8 Byte Frame in CAN

Started by rogergill_99 September 4, 2002
With my target board, and the DSP56F803 Evaluation board, I am
experiencing problems with the MSCAN module when sending 7 and 8 byte
frames.

The problem I have is when I send 7 byte frames, often I do not get
an ACK sequence from other connected devices, and when I send an 8
byte frame, I never get an ACK sequence. This causes the MSCAN
module to resend the frame forever.

Running at 6 byte frames down to zero byte frames does not seem to
show this problem.

I am running the CAN at a scope verified rate of 125kbps. I was
running the MSCAN clock off the IPBUS (40 mhz) but after reading that
the PLL might have too much clock jitter, I have reverted to the 8MHZ
on board crystal oscilator. Both clock sources acted the same.

The details for the sampling are:
TSEG1 = 13
TSEG2 = 2
1 Sample
CAN BAUD Divider = 4

I would appreciate any help with this problem.

Roger



--- In motoroladsp@y..., "rogergill_99" <rogergill_99@y...> wrote:
> With my target board, and the DSP56F803 Evaluation board, I am
> experiencing problems with the MSCAN module when sending 7 and 8
byte
> frames.
>
> The problem I have is when I send 7 byte frames, often I do not get
> an ACK sequence from other connected devices, and when I send an 8
> byte frame, I never get an ACK sequence. This causes the MSCAN
> module to resend the frame forever.
>
> Running at 6 byte frames down to zero byte frames does not seem to
> show this problem.

We will look into this. Please stand by.

The only other problems known to exist with MSCAN on the 56800 family
of DSPs is:

When extended frames are transmitted over the can bus, 4 least
significant bits of the frame ID are visible in bits 4-7 of the Data
Length Register. These bits in the DLR should always read as 0s
according to the manual.

Example: When frame with ID of E8DF03FC and length of 01 is received
by the MSCAN module, the DLR register contains value of 0x00C1
instead of 0x0001. The workaround is simple (AND DLR with 0x000f
whenever reading it). SDK can drivers already implement this.

> I am running the CAN at a scope verified rate of 125kbps. I was
> running the MSCAN clock off the IPBUS (40 mhz) but after reading
that
> the PLL might have too much clock jitter, I have reverted to the
8MHZ
> on board crystal oscilator. Both clock sources acted the same.

We recommend that you use the IPBus clock. It has less jitter
because it is driven off of the PLL. For more details see the 56800
FAQs at http://e-www.motorola.com/cgi-bin/faq.cgi, searching on the
keyword "MSCAN".

> The details for the sampling are:
> TSEG1 = 13
> TSEG2 = 2
> 1 Sample
> CAN BAUD Divider = 4
>
> I would appreciate any help with this problem.
>
> Roger


FYI:
 I am using the 56F807 chip, without the type of problem you observe.  I am running at 1Mbps off of the internal clock.
 
It sounds as though you have a bit rate problem, since more bytes in the block will cause any clock skew to be more noticable.
 
Since the Ack is at the end of the message, It may not be timed properly in the presence of severly mismatched clocks.
 
Is the Synchronization Jump Width set to Maximum???
 
Are you sure the internal clock is set to 40Mhz?  The SDK seems to default it to 36Mhz???
 
For an internal clock of 40Mhz and bit rate of 1Mbps I am using:
 
// for SJW = 3 (skip=4) and quanta size of 1/20 microSec (prescaler = 2)
#define CANBTR0_VALUE 0xc1
// for 1 sample and tseg1 = 12 and tseg2 = 7 (there is one additional quanta required for the Sync_Seg).
#define CANBTR1_VALUE 0x6B
Hope this helps!
 
Jerry.

 -----Original Message-----
From: rogergill_99 [mailto:r...@yahoo.com]
Sent: Wednesday, September 04, 2002 11:16 AM
To: m...@yahoogroups.com
Subject: [motoroladsp] Problem with sending 7 and 8 Byte Frame in CAN

With my target board, and the DSP56F803 Evaluation board, I am
experiencing problems with the MSCAN module when sending 7 and 8 byte
frames.

The problem I have is when I send 7 byte frames, often I do not get
an ACK sequence from other connected devices, and when I send an 8
byte frame, I never get an ACK sequence.  This causes the MSCAN
module to resend the frame forever.

Running at 6 byte frames down to zero byte frames does not seem to
show this problem.

I am running the CAN at a scope verified rate of 125kbps. I was 
running the MSCAN clock off the IPBUS (40 mhz) but after reading that
the PLL might have too much clock jitter, I have reverted to the 8MHZ
on board crystal oscilator.  Both clock sources acted the same.

The details for the sampling are:
TSEG1 = 13
TSEG2 = 2
1 Sample
CAN BAUD Divider = 4

I would appreciate any help with this problem.

Roger



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



--- In motoroladsp@y..., "Johnson, Jerry" <jljohnson@g...> wrote:
> FYI:
> I am using the 56F807 chip, without the type of problem you
observe. I am
> running at 1Mbps off of the internal clock.
>
> It sounds as though you have a bit rate problem, since more bytes
in the
> block will cause any clock skew to be more noticable.
>
> Since the Ack is at the end of the message, It may not be timed
properly in
> the presence of severly mismatched clocks.
>
> Is the Synchronization Jump Width set to Maximum???
>
> Are you sure the internal clock is set to 40Mhz? The SDK seems to
default
> it to 36Mhz???

The External RAM target in SDK stationery has a default PLL
multiplier of 18, producing a clock of 72 MHz and 36 MIPs
performance. The FLASH target in SDK stationery has a default PLL
multiplier of 20, producing 80 MHz and 40 MIPs.

> For an internal clock of 40Mhz and bit rate of 1Mbps I am using:
>
> // for SJW = 3 (skip=4) and quanta size of 1/20 microSec (prescaler
= 2)
> #define CANBTR0_VALUE 0xc1
> // for 1 sample and tseg1 = 12 and tseg2 = 7 (there is one
additional quanta
> required for the Sync_Seg).
> #define CANBTR1_VALUE 0x6B
>
> Hope this helps!
>
> Jerry.
>
> -----Original Message-----
> From: rogergill_99 [mailto:rogergill_99@y...]
> Sent: Wednesday, September 04, 2002 11:16 AM
> To: motoroladsp@y...
> Subject: [motoroladsp] Problem with sending 7 and 8 Byte Frame in
CAN
> With my target board, and the DSP56F803 Evaluation board, I am
> experiencing problems with the MSCAN module when sending 7 and 8
byte
> frames.
>
> The problem I have is when I send 7 byte frames, often I do not get
> an ACK sequence from other connected devices, and when I send an 8
> byte frame, I never get an ACK sequence. This causes the MSCAN
> module to resend the frame forever.
>
> Running at 6 byte frames down to zero byte frames does not seem to
> show this problem.
>
> I am running the CAN at a scope verified rate of 125kbps. I was
> running the MSCAN clock off the IPBUS (40 mhz) but after reading
that
> the PLL might have too much clock jitter, I have reverted to the
8MHZ
> on board crystal oscilator. Both clock sources acted the same.
>
> The details for the sampling are:
> TSEG1 = 13
> TSEG2 = 2
> 1 Sample
> CAN BAUD Divider = 4
>
> I would appreciate any help with this problem.
>
> Roger >
<http://rd.yahoo.com/M"8862.2128520.3581629.2225242/D=egroupweb/S
057718
> 55:HM/A82709/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-
1039-334>
>
>
> _____________________________________
> 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: motoroladsp-subscribe@y...
>
> To Post: motoroladsp@y...
>
> To Leave: motoroladsp-unsubscribe@y...
>
> 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/> .