ColdFire 5329 cache problems.

[russellsheehan]

ColdFire 5329, SDR SDRAM, boots from flash and runs with the cache disabled, boots from flash runs for a while and then hangs when cache is enabled.  Runs fine, cache or no, from the debugger.  The problem appears to be related to a part of the code which reads data from an FPGA across the flexbus, with that data then stored in a buffer in SDRAM.  

[TomE]

> hangs when cache is enabled.

You'll have to add print statements to the code to tell you what it is reading, what it is doing and what it is waiting for.

Do you have the cache set to write-through or write-back? Write-through gives better performance in our case, and means that you don't have to put any LCD screen buffers in cache-disabled memory.

Do you have ALL your I/O memory (internal peripherals and the Flexbus memory region) set to Cache Disabled? That and all memory used by any and all DMA peripherals (control regions and data buffers for at least the USB and the FEC). That is the simplest way to use the cache on these chips. If not you have to have complicated cache-flusing code in all the drivers.

Tom

[russellsheehan]

Tom,

My target has an FRAM non-volatile memory part, so I can also use that to store tracking data, along with print statements.  The cache is set for write-through operation.  I do have all address regions other than the SDR SDRAM, (peripheral space, flexbus, etc) set non-cacheable.  No DMA in this system, except for the FEC specific DMA engine.  All the buffers and buffer descriptors for FEC are located in the on-chip SRAM.

As part of addressing this issue, I removed a few lines of code in the RTOS (ThreadX, low level timing routines used by the Event Analyzer tool) and then an address exception error showed up in the debugger.  It showed up in the debugger as a mis-compilation of a method call that has been working in my system for over a year at least.  The method was one from a derived class (C++).  I re-implemented that class as stand alone (no inheritance) and the problem disappeared.  The system now (again) runs in the debugger, or booting from flash, cache enabled or not.

I am inclined to suspect the 5329 has some inherent design flaws (maybe that is why Freescale is dropping it?), but our hardware is BGA based so I can't pull out the logic analyzer and prove it.

Thanks for your feedback.

Russell G. Sheehan

[TomE]

Are you talking about the Program or Data Caches, and it what combination?

Does your code run with the Program Cache on and Data Cache off, but not with both?

These CPUs run very slowly if you don't have the Program Cache on.

Oops! I wrote a whole lot before I re-read your post where it says:

The system now (again) runs in the debugger, or booting from flash, cache enabled or not.

So the problem is solved I wrote a whole lot of stuff before I spotted that.

So which compiler and which version did that to you (I'm guessing CW), and are there any postings on this problem in the CW forums?

Anyway, yYou might be interested in some of the following:

> I am inclined to suspect the 5329 has some inherent design flaws

Plenty, but few that can't be worked around with the right configuration, tweaking of external hardware or lots of manky software workarounds.

> (maybe that is why Freescale is dropping it?)

What do you mean by "Dropping"? Have you got any official information on that?

Freescale (and pretty much everyone else on the planet with the exception of Intel) are using ARM chips. That's simple outsourcing. It means they don't have to spend billions continuously updating their specific CPU architecture to the latest bells and whistles, documenting same, bug fixing and then supporting it with compilers and development software. The CPU Core and its documentation "is now ARM's problem". Compiler updates for one product apply to everyone using that core. Debuggers are bought from third parties that support chips from multiple vendors with the same cores and ARM debug infrastructure.

It isn't all plain sailing. Have you seen the Errata Lists for the ARM cores? There are19 items for the Cortex A8 in the i.MX53 and 47 on the Cortex A9 (i.MX6Q).

Enough ranting, back to your problem (now fixed, so back to variations on "inherent design flaws").

Turning the cache on allows the CPU to stress the memory system a lot harder. It enable cache-line burst reads and writes. If you have anything wrong with your memory controller programming that means the burst cycles don't work properly, then you won't see that until you enable bursts by turning the caches on. Read through the following for the steps I went through to find a memory corruption problem I had on the MCF5329:

MCF5329 with random SDRAM 1k "bit rot" corruptions

The SDRAM corrupts when writing data to the Flexbus using an unconnected chip-select.

Writing 32-bits of zero to an all-ones address has it fail nearly instantly. It depends on the number of zero data bit.

26 bits doesn't fail, and it gets progressively worse with 27, 28, 29, 30, 31 and 32 zero bits. It doesn't matter which data lines are zero, just the number of them. The "all ones address" is important as the FlexBus puts out the address on the data bus and then switches to driving the data. All-ones to all-zeros is a worst-case for something.

That was fixed by changing the SDRAM bus drive strength. It default to the "strong" setting and that was generating bad over and undershoots, upsetting the SDRAM. That was compounded by there not being any documented "drive strength control" registers for these buses. The registers were there, just named and documented misleadingly.

These chips can't handle "brownouts" on their power supplies and have other lockup problems if you're using the 32 bit data bus for FLASH and SDRAM instead of using the half-speed "split bus" configuration. Check SECF196 and EB740:

Re: MCF5329 (MCF5xxx) + SDR DRAM = lockup, anyone else?

The simple PIT timers have never worked properly (correction, they can work, but the documentation has never said how to program them to work properly, and there are no shipped drivers out there that get it right, Linux included):

Re: PIT hw boo-boo. Read if you need accurate PIT (CF)

Then there are problems with the LCD controller. Search this forum for everything I've written on these chips. You'll be reading for a while :-).

Tom

[russellsheehan]

Tom,

The 5329 has an integrated Instruction/Data cache and I don’t know of any direct control mechanisms. I attempted to segregate its use by locating all of my data buffers in a memory range set non-cacheable (and thus saving the cache for instructions only) but that did not help with my lockup problem and only seemed to slow the system down.

I am building with Green Hills Multi and using the ThreadX RTOS.

Our hardware guy states Freescale is showing the 5329 as ‘Not recommended for new designs’, so that to me indicates ‘End of life’ is near.

I too have concerns with the interaction between the cache controller and SDRAM. I think we have a worst case scenario because we are using a low power, mobile, Single Data Rate SDRAM which needs the somewhat kludgy ‘trace length dependent’ read timing synchronization stuff.

When I really feel guilty about something and want to beat myself up, I try to read the Freescale documentation on the cache and SDRAM controller. Penance indeed.

Thanks again for the information,

R. G. Sheehan

[TomE]

> Our hardware guy states Freescale is showing the 5329 as ‘Not recommended for new designs’,

> so that to me indicates ‘End of life’ is near.

Freescale documents this quite well. The very hard part is finding the documents.

Starting on the MCF5329 page and eventually finding the right "Parametrics" tab here:

ColdFire V3 Microprocessor with LCD driver, E|Freescale

That shows "Not Recommended for New Designs". OK, so how long then? Click on "Show Parametrics", then drag "Last Order Date" into the "Show" column and Apply. That doesn't work, showing the "No Longer Manufactured" ones dated in 2013, but not listing the others.

I had the proper documents on my screen on Friday, but can't find them today...

OK, so click on the "Overview" tab and then on "Product Longevity Program" to get to"

Product Longevity|Freescale

That one shows the MCF5329 as having a 15 year life starting from January 2007. So you're good until 2022.

Worse off are those using the MCF523X and MCF521X. They have 10 year lives starting in September 2005, so from that list there's only one month left!

The MCF5251 has 10 years from Feb 2007. Most of the rest of them are 15 years.

> When I really feel guilty about something and want to beat myself up, I try to read

> the Freescale documentation on the cache and SDRAM controller.  Penance indeed.

They're easy compared to the i.MX53 DRAM controller. It has SIXTY FOUR THIRTY-TWO BIT REGISTERS controlling how it works.

Tom