MCF547X bus error

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

MCF547X bus error

nop head
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?



[hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list.
Reply | Threaded
Open this post in threaded view
|

Re: MCF547X bus error

Judith M. Perreault
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?
>
>
>
> [hidden email] Send a post to the list.
> [hidden email] Join the list. [hidden email]
> Join the list in digest mode. [hidden email] Leave the list.

---
[hidden email]              Send a post to the list.
[hidden email]        Join the list.
[hidden email]    Join the list in digest mode.
[hidden email]     Leave the list.

Reply | Threaded
Open this post in threaded view
|

Re: MCF547X bus error

nop head
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 <[hidden email]>
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?



[hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list.

---
[hidden email]              Send a post to the list.
[hidden email]        Join the list.
[hidden email]    Join the list in digest mode.
[hidden email]     Leave the list.


[hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list.
Reply | Threaded
Open this post in threaded view
|

Re: MCF547X bus error

nop head
Dave,
 Sorry, my last reply was rubbish. The spare chip select will of course terminate the cycle, but only for one duff region.

Chris

2009/3/11 nop head <[hidden email]>
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 <[hidden email]>

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?



[hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list.

---
[hidden email]              Send a post to the list.
[hidden email]        Join the list.
[hidden email]    Join the list in digest mode.
[hidden email]     Leave the list.



[hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list.
Reply | Threaded
Open this post in threaded view
|

Re: MCF547X bus error

Allon Stern

On Mar 11, 2009, at 8:52 AM, nop head wrote:

> Dave,
>  Sorry, my last reply was rubbish. The spare chip select will of  
> course terminate the cycle, but only for one duff region.
>
> Chris

Is this true? On the 5282 you define a chip select's base address and  
mask. You can define a large region and a discontiguous mask to  
define multiple regions for one chip select.

-
allon
---
[hidden email]              Send a post to the list.
[hidden email]        Join the list.
[hidden email]    Join the list in digest mode.
[hidden email]     Leave the list.

Reply | Threaded
Open this post in threaded view
|

Re: MCF547X bus error

nop head
Well yes I could have a power of two separate regions but not in a way that could fill all the gaps in my memory map.

I could also remove gaps by letting memories mirror, but then errant memory accesses would just go undetected. A big step backwards from where we were 20 years ago.

2009/3/11 Allon Stern <[hidden email]>

On Mar 11, 2009, at 8:52 AM, nop head wrote:

Dave,
 Sorry, my last reply was rubbish. The spare chip select will of course terminate the cycle, but only for one duff region.

Chris

Is this true? On the 5282 you define a chip select's base address and mask. You can define a large region and a discontiguous mask to define multiple regions for one chip select.

-
allon
---

[hidden email]              Send a post to the list.
[hidden email]        Join the list.
[hidden email]    Join the list in digest mode.
[hidden email]     Leave the list.


[hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list.
Reply | Threaded
Open this post in threaded view
|

Re: MCF547X bus error

nop head
I take it all back!

The XL Bus timeouts catch any gaps in the memory map. They terminate the cycle and can give an interrupt. It was just the default timeout value is about 16 seconds so I thought it wasn't working.

It seems the CPU will only hang if you have a flex bus chip select configured for external termination and nothing provides TA.

2009/3/11 nop head <[hidden email]>
Well yes I could have a power of two separate regions but not in a way that could fill all the gaps in my memory map.

I could also remove gaps by letting memories mirror, but then errant memory accesses would just go undetected. A big step backwards from where we were 20 years ago.

2009/3/11 Allon Stern <[hidden email]>


On Mar 11, 2009, at 8:52 AM, nop head wrote:

Dave,
 Sorry, my last reply was rubbish. The spare chip select will of course terminate the cycle, but only for one duff region.

Chris

Is this true? On the 5282 you define a chip select's base address and mask. You can define a large region and a discontiguous mask to define multiple regions for one chip select.

-
allon
---

[hidden email]              Send a post to the list.
[hidden email]        Join the list.
[hidden email]    Join the list in digest mode.
[hidden email]     Leave the list.



[hidden email] Send a post to the list. [hidden email] Join the list. [hidden email] Join the list in digest mode. [hidden email] Leave the list.