Re: MCF547X bus error

--001636c5a2d84824e20464d70a84
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 <[email protected]>

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

--001636c5a2d84824e20464d70a84
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Dave,<br>=A0 The memories are not contiguous due to being different size=
s, etc, so there are lots of gaps to cover. 68K chip selects were again mor=
e useful because you could overlap them and the one with the highest priori=
ty overides the others. It doesn&#39;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.<br>
<br>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.<br>
<br>Regards, Chris<br><br><div class=3D"gmail_quote">2009/3/11 David A Perr=
eault <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]">briggsroa=
[email protected]</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"bord=
er-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-l=
eft: 1ex;">
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 inte=
rrupt.<br>
<br>
Dave<br>
<br>
<br>
nop head wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><=
div class=3D"h5">
Is it me or are Freescale making it harder and harder to make a robust syst=
em?<br>
<br>
I need to stop illegal accesses hanging the system. 15 years ago we had a 6=
8340 with a bus error timer that terminated any bad cycles and caused an ex=
ception. Before that a simple counter on the BERR pin did the same thing.<b=
r>

<br>
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 interr=
upt if it saw a TS with no following FBCSn.<br>
<br>
With the MC547X I find that it does not generate ALE for cycles that miss t=
he Flex Bus chip select range, so my only option seems to be an external wa=
tchdog 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 mu=
ch better inside the core with a trivial amount of silicon.<br>

<br>
It does have three watchdog timers on the XL Bus, but they don&#39;t seem t=
o be of any use for this situation. What would cause an XL bus timeout?<br>
<br>
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 re=
set, making debugging the problem impossible.<br>
<br>
Even with an interrupt it will be very difficult to pinpoint the errant ins=
truction. I thought I could use the MMU to help me, but I find that when th=
e MMU is enabled I lose the default cache settings. My default is no cachin=
g for I/O and I have two data ACR settings, one for write through non-volat=
ile memory sections and another for buffered copy back for DRAM. So am I ri=
ght in thinking that with the MMU enabled I have to have one of the data AC=
Rs set to no caching for =A0the I/O addresses leaving me with only one othe=
r type of data cache mode?<br>

<br>
Is it really this hard or have I missed something in the manual?<br>
<br>
<br>
<br>
</div></div><a href=3D"mailto:[email protected]" target=3D"_blank">cold=
[email protected]</a> Send a post to the list. <a href=3D"mailto:coldfire-j=
[email protected]" target=3D"_blank">[email protected]</a> Join the=
 list. <a href=3D"mailto:[email protected]" target=3D"_blank">co=
[email protected]</a> Join the list in digest mode. <a href=3D"mai=
lto:[email protected]" target=3D"_blank">coldfire-leave@wildrice.=
com</a> Leave the list. <br>

</blockquote>
<br>
---<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">coldfire@wildric=
e.com</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0Send a post to the list.<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">coldfire-jo=
[email protected]</a> =A0 =A0 =A0 =A0Join the list.<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">coldfire-=
[email protected]</a> =A0 =A0Join the list in digest mode.<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">coldfire-l=
[email protected]</a> =A0 =A0 Leave the list.<br>
<br>
</blockquote></div><br>

[email protected]=09Send a post to the list.
[email protected]=09Join the list.
[email protected]=09Join the list in digest mode.
[email protected]=09Leave the list.
--001636c5a2d84824e20464d70a84--