« Return to Thread: MCF547X bus error
Re: MCF547X bus error
by Judith M. Perreault
::
Rate this Message:
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.
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.
« Return to Thread: MCF547X bus error
| Free embeddable forum powered by Nabble | Forum Help |
