Need accurate info or drivers for MSCAN + MCF51JM

[ianm_]

I have to make CAN work on the MCF51JM128. Seems easy enough. I downloaded the Freescale MSCAN Drivers:

    http://www.freescale.com/webapp/sps/download/license.jsp?colCode=MSCAN_MCF51JM&location=null&fas...

I opened the /samples/JM128 sample.mcp, and... got a boatload of errors. That's because it was created before "Device Initialization" existed? But the consequence is that everything I find is outdated.

The MCF51JM datasheet isn't much help either, in other words, it is VERY HARD to find accurate information and code.

In a couple of responses TomE said that people used outdated code and that is wasn't worth their trouble making USB-CAN applications "because there was much better code out there". But I don't find any code. Neither does TomE point to the resources he refers to.

So this is a desperate last effort. Is there something that is obvious to everybody I have missed? I certainly hope so. Thanks!

[TomE · Accepted solution]

> But the consequence is that everything I find is outdated.

Click on the following Freescale Document Link:

Life Cycle Stage Codes

So where is ColdFire in its Life Cycle?

If you look on the Forum Home Page you'll see that ColdFire no longer gets its own "Button" The first three are CodeWarrior, i.MX and Kinetis. Even "16 bit Microcontrollers" gets a button. You have to look in the "More Spaces" list to find ColdFire where it is currently between "8-bit" and "Other".

If you're a large enough customer you should lean on your local FAE (your local distributor) for help. We've done that in the past and have had better outcomes than the "Self Service" you get here.

> I downloaded the Freescale MSCAN Drivers:

Is this a new project or an old one that didn't need CAN before, but does now?

If it is a new project I'd suggest you start on the newer Freescale chips, which are the ARM-based Kinetis ones. Many of these chips are designed to be an "Upgrade Path" away from the ColdFire and HCS series parts, and so have similar pinouts, features and peripherals. So I'd suggest you look at the current support and examples provided for these chips, starting from the "MSCan Driver" link on this page:

http://www.freescale.com/webapp/sps/site/overview.jsp?code=KINETIS_EA_SERIES

Which is:

http://cache.freescale.com/files/microcontrollers/software/device_drivers/MSCAN_KEA_DEVD.zip

You might be able to cut/paste/extract the driver code from that into a Coldfire project.

Even if it is an "upgrade" to an existing product it might be worth evaluating changing to an ARM-based chip.

> In a couple of responses TomE said that people used outdated code...

I'm sure I did. Can you include links to those posts so I don't have to hunt for them to see what I said? I might have hidden something useful to you in one of them or references from them.

You should also look at adapting these drivers for your purpose:

http://lxr.free-electrons.com/source/drivers/net/can/mscan/?v=2.6.33

I've also sent you a Private Message.

Tom

[ianm_]

Thanks for the extensive reply. The code you linked I had found, but it was old too and now that I have it endorsed, I'll base my code off of it.

Yes, this is an old project acquiring new purposes. I'll straighten out the manager about not using a more modern chip, but for this project, as it is low volume, it's probably not worth stocking a new part.

We're looking into ARM based processors, having seen STM32 variants that beat PIC processors on price. Pin compatibility with Coldfire is probably not a priority.

Again, many thanks for adding a voice to the info.

[TomE]

> The code you linked I had found, but it was old too and now that I have it endorsed, I'll base my code off of it.

Don't take my linking to it as any form of endorsement. I haven't used it. I found it under the Kinetis pages and assumed it might have been newer that the ColdFire release. The MSCAN module has been used in lots of different Freescale chips over the years. It is even turning up in one of the i.MX chips in place of the more usual FlexCAN modules.

There's nothing wrong with old code. It is likely to have been working for longer than any new stuff. The main problem with the ColdFire sample code is that the projects won't build with the newer versions of CodeWarrior due to assembler changes. If you have a working system and can treat the sample code as driver source that needs to be ported then it doesn't really matter where it comes from.

CAN is relatively simple. There are some unexpected complexities in getting the right baud rate, and everyone finds dividing the "bit" into |quanta" in order to get the sample bit confusing. Otherwise it isn't much more than a complicated UART and you should try to treat it as such.

If you're looking at the ARM sources, watch out for any big-endian vs little-endian problems. I would recommend the Linux stuff as it is likely to have better error handling and error recovery than other sample code. It also has proper data and well thought out control interfaces.

Tom