Re: MCF547X bus error

Hi Dave,
  The memories are not contiguous due to being different sizes, etc, so there are lots of gaps to cover. 68K chip selects were again more useful because you could overlap them and the one with the highest priority overides the others. It doesn't seem to be the same on Coldfire. The 53 manual says overlapping chip selects cause both to be asserted and the cycle defualting to 32 bit unterminated, so not useful. The 54 manual does not mention what happens with overlaps.

An interrupt on its own will not free the bus. You have to pulse TA to terminate the hung cycle, but there may be multiple cycles queued up before the interrupt is serviced, so you have to give a TA for all of them.

Regards, Chris

2009/3/11 David A Perreault <briggsroad@...>

How about enableing a spare chip select to cover all the space not covered by your responding memories. Then tie the spare chip select back to an interrupt.

Dave


nop head wrote:

Is it me or are Freescale making it harder and harder to make a robust system?

I need to stop illegal accesses hanging the system. 15 years ago we had a 68340 with a bus error timer that terminated any bad cycles and caused an exception. Before that a simple counter on the BERR pin did the same thing.

A couple of years ago we moved to MCF537X. To get the same functionality we had to add an external bus timer which generated a TA and a level 7 interrupt if it saw a TS with no following FBCSn.

With the MC547X I find that it does not generate ALE for cycles that miss the Flex Bus chip select range, so my only option seems to be an external watchdog timer which, when it times out generates a TA pulse and an interrupt. A not insignificant amount of logic and design time that could be done much better inside the core with a trivial amount of silicon.

It does have three watchdog timers on the XL Bus, but they don't seem to be of any use for this situation. What would cause an XL bus timeout?

There is also a watchdog timer in the SIU, which misleadingly is shown as a separate timer, but is actually GPT0. But that only seems to generate a reset, making debugging the problem impossible.

Even with an interrupt it will be very difficult to pinpoint the errant instruction. I thought I could use the MMU to help me, but I find that when the MMU is enabled I lose the default cache settings. My default is no caching for I/O and I have two data ACR settings, one for write through non-volatile memory sections and another for buffered copy back for DRAM. So am I right in thinking that with the MMU enabled I have to have one of the data ACRs set to no caching for  the I/O addresses leaving me with only one other type of data cache mode?

Is it really this hard or have I missed something in the manual?

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.