MSCAN question for Coldfire VI

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MSCAN question for Coldfire VI

Jump to solution
686 Views
sudhanshumehta
Contributor IV

Hi,

I need urgent help if possible.

I am using Coldfile VI microcontroller (MCF51JM128VLH).

 

I am getting problem in sending some of CAN message. Problem is strange. 

I am using processor expert. 

 

I am able to send message ID= 0x000, Frame= dataFrame =0x00, message length =8, Data = {0x02, 0x00, 0xAA, 0x00, 0x00, 0x00, 0x00, 0x31}

 

But I am not able to send message ID= 0x000, Frame= dataFrame =0x00, message length =8, Data = {0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x31}

 

only difference in two messages is data byte number 3(underlined) which changed from 0xAA to 0x00.

If I try to send 2nd message, MSCAN retries to send the message.

 

my Processor expert and CPU configuration is attached.

 

 

Thanks

Sudhanshu

Labels (1)
0 Kudos
1 Solution
517 Views
TomE
Specialist II

> Any Idea, How to fix this. Processor expert settings are given in original post.

I didn't look at those pictures in your original post. The problem there is absolutely obvious, and matches my guess.

You're aiming for 125 kbits/sec and Processor Expert (I'm impressed with this part) is nice enough to show you that you're actually getting 123.077 kbits/sec which is out by 2% by eyeball and 1.56% by calculator. If Processor Expert was even smarter it would have showed that in red and drawn a big red cross on top of it.

It HAS given you a warning of "Warning: this frequency is out of r..." on the first page for some of the main clocks (not related to CAN), which you should look at, understand and resolve.

Back to CAN, If it was smarter again it would show you both the values loaded into the register (which it has done) and the number of bits that results in (which is always that plus one).

So now look at Section "11.5.2.7 Clock System" and "Figure 11-42. Segments within the Bit Time".

Now the first question is, what do you have "CLKSRC" set to? Then what do you have the Prescaler set to?

You didn't include this information in your post, so you'll have to work this all out properly yourself. You should try to understand this, it's good practice.

So referring to Figure 11-42 you have your CAN bit made up of:

Sync:   1 bit

TS1: Register Value 7: 8 bits

TS2: Register Value 3: 4 Bits

Total: 13 bits (as noted in Processor Expert)

RSJ: Register Value 1: 2 bits.

You've got an RSJ of "2" which by one set of calculations I have here means you can have the clock out by:

    RSJ/(20 * NBT)

Which in your case is 2/(20*13) = 0.77%

At 1.56% you're DOUBLE that and way outside what is allowed for it to work reliably.

Now I don't have your CLKSRC or your prescaler, or the generated code that would have told me that, but there's one thing that is very obvious.

The "Time Quanta per Bit" is 13. That constitutes a "divide-by-13" stage between the quanta-clock and the bit rate.

Dividing anything by "13" is a really bad idea! That never divides down evenly (unless you've got a 13MHz crystal, which you haven't and don't want).

Now I know you've got a 12MHz crystal and probably have 12, 24 and 48MHz available. So what are the clock dividers and prescalers giving as the total division ratio?

Working backwards, 123.077 * 13 = 1.6MHz, which is 1/7.5 of 12MHz (impossible), 1/15 of 24MHz and 1/30 of 48MHz. The CAN Prescaler can handle the latter two ratios. So CLKSRC must be selecting the high speed clock.

You really want a total division ratio of 48MHz/125kHz or 384. So you should have "Time quanta per bit" set to something that divides evenly into 384. Which is 12 * 32. Or 16 * 24.

So simply drop "TS1" to "6". That gives a "Time Quanta per Bit" of 12 instead of 13, and that will divide down exactly.

Tom

View solution in original post

0 Kudos
3 Replies
517 Views
TomE
Specialist II

Are there any error bits getting set? Are REC and/or TEC (whatever they're call ed on MSCAN) increasing?

If you've got a data-dependent problem, then maybe your baud-rate setting is marginal. The receiver can resynchronise to the transmit rate on every edge. The more edges in the data, the more baud rate error it can potentially handle.

You should aim to get the baud rate absolutely exact, as good as the crystal will allow. "Within 1 percent" isn't good enough. How much baud rate variation you can handle depends on the settings for the segment sizes and the SJW. On ALL devices on the bus. The tolerance may be 1% if all devices are programmed to allow a wide variation, or it may be as low as 0.25%.

Put an oscilloscope on the bus and look for devices signalling errors at the end of your device's transmission.

Tom

0 Kudos
517 Views
sudhanshumehta
Contributor IV

Hi Tom, 

thanks!!

Any Idea, How to fix this. Processor expert settings are given in original post.

Thanks

Sudhanshu

0 Kudos
518 Views
TomE
Specialist II

> Any Idea, How to fix this. Processor expert settings are given in original post.

I didn't look at those pictures in your original post. The problem there is absolutely obvious, and matches my guess.

You're aiming for 125 kbits/sec and Processor Expert (I'm impressed with this part) is nice enough to show you that you're actually getting 123.077 kbits/sec which is out by 2% by eyeball and 1.56% by calculator. If Processor Expert was even smarter it would have showed that in red and drawn a big red cross on top of it.

It HAS given you a warning of "Warning: this frequency is out of r..." on the first page for some of the main clocks (not related to CAN), which you should look at, understand and resolve.

Back to CAN, If it was smarter again it would show you both the values loaded into the register (which it has done) and the number of bits that results in (which is always that plus one).

So now look at Section "11.5.2.7 Clock System" and "Figure 11-42. Segments within the Bit Time".

Now the first question is, what do you have "CLKSRC" set to? Then what do you have the Prescaler set to?

You didn't include this information in your post, so you'll have to work this all out properly yourself. You should try to understand this, it's good practice.

So referring to Figure 11-42 you have your CAN bit made up of:

Sync:   1 bit

TS1: Register Value 7: 8 bits

TS2: Register Value 3: 4 Bits

Total: 13 bits (as noted in Processor Expert)

RSJ: Register Value 1: 2 bits.

You've got an RSJ of "2" which by one set of calculations I have here means you can have the clock out by:

    RSJ/(20 * NBT)

Which in your case is 2/(20*13) = 0.77%

At 1.56% you're DOUBLE that and way outside what is allowed for it to work reliably.

Now I don't have your CLKSRC or your prescaler, or the generated code that would have told me that, but there's one thing that is very obvious.

The "Time Quanta per Bit" is 13. That constitutes a "divide-by-13" stage between the quanta-clock and the bit rate.

Dividing anything by "13" is a really bad idea! That never divides down evenly (unless you've got a 13MHz crystal, which you haven't and don't want).

Now I know you've got a 12MHz crystal and probably have 12, 24 and 48MHz available. So what are the clock dividers and prescalers giving as the total division ratio?

Working backwards, 123.077 * 13 = 1.6MHz, which is 1/7.5 of 12MHz (impossible), 1/15 of 24MHz and 1/30 of 48MHz. The CAN Prescaler can handle the latter two ratios. So CLKSRC must be selecting the high speed clock.

You really want a total division ratio of 48MHz/125kHz or 384. So you should have "Time quanta per bit" set to something that divides evenly into 384. Which is 12 * 32. Or 16 * 24.

So simply drop "TS1" to "6". That gives a "Time Quanta per Bit" of 12 instead of 13, and that will divide down exactly.

Tom

0 Kudos