MCF547X bus error

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.