MCF5407CAI162 replacement

[FNapo]

Hello,

I need to replace MCF5407CAI162 reference in a design. I searched on the website a replacement, but none reference was preferred.

Is there an another reference which can match in order to minimize HW modification with this change ?

We look for a reference which matches with I/Os number, Package size and main characteristics.

Thank you for your help.

[FNapo]

Hello,

Thank you for your answers. Yes, you are right, the software is quite critical. At the moment of my question, I didn't have information about the embedded software. I tried to do MPU/MCU benchmark to be compatible with the current architecture.

The actual ColdFire use parallel flash memory in 16-bits, SDRAM memory like local memory accessible in 8, 16 or 32-bits and transfer memory SRAM accessible in 8, 16 or 32-bits by the MPU. So I need to find a new reference with:

- An integrated 32-bit SDRAM controller
- Capable to be interfaced with external components with 16,32 bits address and data bus
- Operating at the same frequency or even faster
- With an interrupt controller & Chip select module

I found some references, but it's overside in relation to need.

Best Regards,

Florent 

[Hui_Ma]

Hello,

If you would consider transfer product platform from ColdFire V4 to ARM core,  please check i.MX RT1170 CrossOver MCU product.

RT1170 with below external memory feature:

Please refer this fact sheet about RT1170 product detailed info.

Thanks for the attention.

Mike

[FNapo]

oversized*

[TomE]

> oversized

Having "too much performance" is usually a good problem to have.

Is the existing system running on a "named" operating system, like Linux (or uCLinux) or one of the usual embedded OS suppliers? Is it running an in-house OS with complexities like threading, or is it running "a dumb event loop"? Answering that is a big part of the selection criteria.

The suggested parts (i.MXRT1170) run at 800MHz or more. Very powerful.

These are very capable, but extremely complicated chips. We've used an i.MXRT1060.The Reference Manual is over 3600 pages long, and that doesn't include the CPU (that's in the ARM manuals). That is nowhere near long enough as it is mainly "lists of registers" without saying how they work. The IOMUX chapter alone (to set up the I/O pins) goes from Page 317 to 1008. Just the list of IOMUX registers alone goes for 27 pages. You have to set them up before the chip starts working. There are 28 pages just listing all the clocks in this chip (and they're all configurable). Every peripheral is like that.

It took us about 2 years to get our OS working on it properly. We had to rewrite all the drivers as the peripherals in these chips are unlike the previous ones, and a lot harder to use. The drivers had bugs, the chip had lots of complicated problems we had to work around, and the sample code had problems we had to fix, or in most cases, fix by complete rewrites.

This cost us a lot of time, and still hasn't been addressed:

https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/i-MXRT1060-SEMC-SDRAM-Data-Corruption/m-p/182549...

Just getting working SPI code took me months. The LPSPI module is very complicated, and the NXP code didn't handle most of the options. The supplied initialization code performs an "M*N search" through all possible baud rates using the dividers to find the "best one". That took milliseconds! I made it 150 times faster.

I'd suggest you look for the simplest chip you can find that will do the job, or get one with a proven and working operating system you can use without having to rewrite it.

Tom

[TomE]

Hui Ma is correct, but it is worse than that. You're wanting to minimise the hardware change, but what about the software? Is your code that portable that that doesn't matter?

The MCF5407 was first released in April 2000. The only current "Active" V4 Coldfire CPUs are the MCF544xx ones, which date from about 2010. NXP's Longevity Program (search for that to get the list) gives 10 years from 2007 for the MCF5445X and 15 years from 2010 for the MCF5441x chips. That's the guarantee, but these parts are all still "Active", so could be used now.

Development systems are usually only available for a few years after product release, so getting a development board for a "new" MCF54xx chip might be hard or impossible.

The best bet is to use a new ARM-based microcontroller. That means going from a big-endian 68000-based CPU to a little-endian ARM-based one. Making that change depends on how well written (and endian independent or handling) your existing code is.

I would expect that all of the peripherals are very different, so none of your existing device driver code will work.

You will need a completely new development system (IDE, debugger, compiler, libraries).

If you were running portable Application code on Linux (or en embedded OS that runs on ARM and Coldfire) then you could just port that code to a new underlying system. That would have needed you to be using something like the MCF5485, which has an MMU. The MCF5407 doesn't. Unless running uCLinux. Which might be obsolete.

The packaging has changed in the last quarter century. From QFP for MCF5407 to MAPBGA for MCF544xx.

Tom

[Hui_Ma]

Hi,

Unfortunately, we don't have dedicated pin to pin compatible products for MCF5407CAI162.

Due to all ColdFire products are quite old, there lack of support resource.

The ColdFire products(V4 core) are not recommended for new design. 

Could you share what's the end application?

We are willing to find suitable up-to-date reference design for your reference.

best regards,

Mike