Automotive MCUs

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm currently looking to specify two MCUs for an automotive application.
The first will be driving an small OLED and the second will be driving
solenoids (and some other duties). Both connected via CAN. Normally I would
use an ARM based MCU (familiarity and tools) but apart from a single TI
CM3, 99% are not automotive qualified / have the temperature range.  

After lots of searching Freescale seems to be the dominant provider and an
S9S12G128 / MPC5602P combination seems to fit the requirements. The tool
cost for Freescale seem to be pretty high, although ‘special ' versions
of CodeWarrier seem to be listed as "Free" not sure what that means? Free
with dev kits? That may mean that I use two of the same despite extra costs

Microchip also provide dsPIC33 which seem competitive but they don't seem
to have some of the robustness features; ECC memory for one. Also I've read
that the FLASH write cycles can be very low although I didn't notice it on
a previous project.  

The product won't be large volumes (x100 at most) Does anyone have any
experience with Freescale products when compared to Microchip for
automotive applications? Freescale MCUs, apart from some of the S12's don't
seem to be available from suppliers (digikey, mouser…etc). Also the
performance of the S12 may be a small concern, especially when compared to
the dsPICs.  

Any general advice would be appreciated.  
Posted through

Re: Automotive MCUs
On Tuesday, November 5, 2013 6:31:54 AM UTC-8, treborlecs wrote:
Quoted text here. Click to load it

This is in passenger compartment, right?  Why would you put an OLED display under the hood?  If so, you don't need high temp. grade for this.

Quoted text here. Click to load it

This can be lower performance.

Quoted text here. Click to load it

You only need ECC for dynamic ram.  How much memory do you need under the hood?

Quoted text here. Click to load it

Not a problem unless you are changing the FLASH in run time.

Re: Automotive MCUs
On 11/5/2013 8:31 AM, treborlecs wrote:

Quoted text here. Click to load it

If this is intended for OEM product, then you don't have much freedom in  
choosing MCUs or tools. First, look what is approved or would be  
acceptable with your customer.

Vladimir Vassilevsky
DSP and Mixed Signal Designs

Re: Automotive MCUs
On Tuesday 05 November 2013 15:31 treborlecs wrote:

Quoted text here. Click to load it
Have a look at the Fujitsu MB96Fxxx family. These are automotive style MPUs  
and come with a free compiler. I have been using these and their predecessor  
(MB90Fxxx) for more than 10 years now.
Reinhardt Behm

Re: Automotive MCUs
On 05/11/13 15:31, treborlecs wrote:
Quoted text here. Click to load it

Details of CodeWarrior versions are pretty clear on the Freescale website:


Look for the "CodeWarrior Development Suite comparison" link.

Basically, the free version has restrictions on the size of the code you  
can work with - but I've found the limits more than high enough for  
real-world projects.

CodeWarrior is quite good, now that they have dropped their own IDE and  
moved over to Eclipse.  In an incredibly thoughtless decision, they  
decided to drop the Linux versions after 10.3, which has annoyed a lot  
of people.  (Don't these guys know that a lot of modern embedded and  
automotive development is done on Linux and for Linux?).  It is also  
extraordinarily daft policy that C++ is only available on the  
"professional" version (at $5000 for a full license).

The library is a bit weird, and the wizard-generated startup and  
interrupt code is sometimes truly awful, but that's not uncommon in  
toolchains.  The compiler does a solid job.

Quoted text here. Click to load it

We've never had trouble getting Freescale parts, though we usually use a  
real distributor.

Re: Automotive MCUs
On 11/5/2013 7:31 AM, treborlecs wrote:
Quoted text here. Click to load it

A single device can't serve both purposes (perhaps because of location
requirements of each)?

Presumably, you are hard pressed on temperature at the *high* end
and not the low?  What risk do you run if the devices are "borderline"
in terms of *specified* performance?

Quoted text here. Click to load it

Usually, the kits are limited in terms of the complexity of the
"programs" you can write.  Either in terms of size of binary
created, number of source files, etc.  If you are trying to do
this on a hobbyist's budget, there are often ways to coax a
"limited" tool to meet your needs -- though often at some bit
of inconvenience on your part (e.g., cut the application in half
and link the two halves through a jump table, etc.)

Quoted text here. Click to load it

Are you *sure* you need ECC memory?  What are you protecting against?
General memory failures?  Or, *specific* "precious" data?  In the
latter case, you can implement your own ECC algorithms and access
those parameters through a mechanism that you create.

You are probably not going to be able to use FLASH like RAM.
Instead, you want to be using it for configuration information
and things that don't change often.  E.g., storing the frequencies
of radio station presets (which don't change often -- and probably
can't PHYSICALLY be changed often!)

If you need to store something in FLASH that changes often, you
might have to keep a "live copy" that you update as often as you
want and arrange for that to get stashed in FLASH "just before
powering off" or even "periodically" -- as long as that ends up
less than your high frequency update rate.

Quoted text here. Click to load it

Only you can decide if a particular device will meet your requirements
(capabilities, etc.).  Ask yourself what it is about the dsPICs that
sets them apart/above the other choices.  Then, see if there is a
way to *not* need that capability -- thereby reducing the dsPICs
advantage and making other options more usable.

If you are looking for small volumes, a big part of your design
decision will be *getting* the parts.  The "perfect" part is useless
if it's not obtainable (for you).

Re: Automotive MCUs
On Wednesday, November 6, 2013 3:31:54 AM UTC+13, treborlecs wrote:
Quoted text here. Click to load it

SiLabs have CAN Automotive spec devices.

 These should do the Solenoid instance, and depending on how small the 'small OLED' is, may even have a part for that too. Come up to 128KF and 8KR

Infineon XMC1xx series can spec to 105'C, but is not full automotive.

Re: Automotive MCUs
On 05/11/13 14:31, treborlecs wrote:
Quoted text here. Click to load it
Freescale have automotive qualified ARM parts with CAN which may be  
worth looking at.

Normally the 'special' codewarrior is subject to a maximum code size,  
32kB or 64kB depending on the part IIRC.

You can also use GCC if you like.

Quoted text here. Click to load it

We use a range of freescale parts, and they are all available from Digikey.
Although for some parts, you may have an MOQ if you want a particular  
package and temperature rating.

Regarding performance, Some of the S12 variants have an XGATE  
co-processor (E.g mc9s12xep100).


Re: Automotive MCUs
On 06/11/13 10:43, Andy Sinclair wrote:
Quoted text here. Click to load it

I believe that you can use the supplied gcc to compile code bigger than
than the code size limit, but you can't debug it with the "special"
edition of CodeWarrior.  The same applies to using C++ - gcc supports
it, but not the "special edition" debugger.

Re: Automotive MCUs

Quoted text here. Click to load it

According to the spec, dsPIC33 can run up to 120C at full speed and 150C at half speed.  We pick them for wide temp range of -40 to 150C for an outdoor product, but perhaps not as hot as under the hood.

Quoted text here. Click to load it

DsPIC33 has 24 bits accumulator and single cycle multipler.  It should be handy for apps such as audio/voice codec, with the build-in D2A.

Site Timeline