Kinetis Flexcan : compatibility with previous version?

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

Kinetis Flexcan : compatibility with previous version?

1,871 Views
robertob
Contributor I

Datasheet report  "100% backward compatibility with previous Flexcan version".

 

I think this is not true by a software point of view.

 

See for example  MC56F8323 flexcan module.

Message structure buffer are very different (same bits but in different position).

 

Registers like FCMAXMB (maximum message buffer) are not present in the Kinetis Flexcan module because are included in other 32 bit-register like CANx_MCR (lower 7 byte).

 

And so on.

 

Regards

 

0 Kudos
5 Replies

1,235 Views
freegeek
Contributor III

Perhahaps the comment related to the flexcan used on the existing Coldfire MCU families rather than the DSCs

0 Kudos

1,235 Views
mnorman
NXP Employee
NXP Employee

That's correct.  The FlexCAN modules on the Kinetis devices is a newer but backward compatible version of the controller used on previous 32-bit MCUs.  The DSC version of FlexCAN is older and not software compatible with the 32-bit MCU CAN modules.

 

-mnorman

0 Kudos

1,236 Views
Alberto_g
Contributor III

I recall there was an issue with ColdFire CAN, controller is always self receiving its own tx messages.

DSC works ok.

Does anybody know if this was fixed?

0 Kudos

1,236 Views
GottiLuca
Contributor IV

Dear Alberto-g ,

 

I never used the Kinetis or ColdFire Flexcan . About the DSC Flexcan, instead, i've used for at least 4-5 years .

 

On the DSC Flexcan, a messages transmitted is "self received" on an rx mailbox if the ID-masks for that mailbox matches a  transmitted ID ...

 

0 Kudos

1,236 Views
Alberto_g
Contributor III

I use CANBus on DSC too and it works as it should. My question was about the new Kinetis, since I had this problem with Coldfire M52235.

I had a quick look at the K60 reference manual. It states:

 

17
SRXDIS
Self Reception Disable
This bit defines whether FlexCAN is allowed to receive frames transmitted by itself. If this bit is asserted,
frames transmitted by the module will not be stored in any MB, regardless if the MB is programmed with
an ID that matches the transmitted frame, and no interrupt flag or interrupt signal will be generated due to
the frame reception. This bit can only be written in Freeze mode as it is locked by hardware in other
modes.

 

So it seems the issue was addressed. I am waiting for a TWR kit, let's see.

 

Regards.

0 Kudos