topic MCF5208 Access errors... in ColdFire/68K Microcontrollers and Processors

MCF5208 Access errors...

Dietrich — Sat, 01 Apr 2006 06:33:58 GMT

This message contains an entire topic ported from the WildRice - Coldfire forum. Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions. Freescale assumes no responsibility whatsoever with respect to Posted Material. For additional information, please see the Terms of Use - Message Boards and Community Forums. Thank You and Enjoy the Forum!

Jan 11, 2006, 2:15 PM

Post #1 of 11 (71 views)
Copy Shortcut
[ColdFire] MCF5208 Access errors... Can't Post

--------------------------------------------------------------------------------

I am in the process of porting to the 5208.

I'm currently having problems with access errors,
any other coldfire I've ever worked on would generate an access error trap
if you accessed unmapped memory.

(For example it is a Netburner rule that memory around 0 will not be valid so
Null pointer accesses will generate traps.)

The 5208 does not trap it just hangs.

This is a problem for us, because we do not directly control the
code that runs on our modules. (our customers write their own code)
so that if a customer makes a coding error and overflows a stack or
references a Null pointer the system will just hang, and it looks
like a bug in our
hardware.

I got a response from Freescale today that is disturbing...

>The way the internal buses work on the 5208 (and this will be the same
>on most of our parts going forward), the bus monitor that you are
>looking at will really only count for accesses in the internal register
>space. Once an access is passed on to one of the slave ports like the
>FlexBus, SDRAMC, or SRAM, the bus monitor isn't really in the picture
>anymore. So the bus monitor is really only going to terminate hung
>accesses in the internal register space (0xF0000000-0xFFFFFFFF).

>It sounds like you are accessing space within the FlexBus memory area
>that isn't mapped to a chip select, right? I just tried this on a board
>myself and there doesn't seem to be any way to gracefully recover except
>for a reset. I'm talking to the design team now about changing this for
>future devices and possibly even fixing it on the 5208/7 and 523x and
>537x parts if there are respins on any of those parts.

I've tried to setup the debug breakpoint monitoring stuff to catch these, but
that does not seem to work either.

On a 5272 if I setup the debug breakpoint to trap on access to some
memory range,
then it generates a debug trap if the specified range is mapped,
and an access error if the specified range is unmapped.

On the 5208 the debug breakpoint trap generates a debug trap if the
memory is mapped,
and just hangs if it is not mapped. This makes me thing that the
debug break point logic happens at
the end of the bus cycle.

I've also tried to setup a core fault interrupt register, and it does
not seem to work.
This makes sense as the CPU can't recognize an interrupt until it
finishes it's
present instruction. I've also put a variety of values into the BMT
register to no avail.

Has anyone else fought this problem and reached a solution?

Paul

--------------------------------------------------------------------

Jan 11, 2006, 3:27 PM

Post #2 of 11 (71 views)
Copy Shortcut
Re: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

Paul -

I don't have an answer for you... just another question. Would the
547/8x series of processors have the same issue? I've noticed something
similar but have not pursued yet.

Thanks for the heads up on this issue.

Regards,

Brett

Paul Breed wrote:

> I am in the process of porting to the 5208.
>
> I'm currently having problems with access errors,
> any other coldfire I've ever worked on would generate an access error
> trap
> if you accessed unmapped memory.
>
> (For example it is a Netburner rule that memory around 0 will not be
> valid so
> Null pointer accesses will generate traps.)
>
>
> The 5208 does not trap it just hangs.
>
> This is a problem for us, because we do not directly control the
> code that runs on our modules. (our customers write their own code)
> so that if a customer makes a coding error and overflows a stack or
> references a Null pointer the system will just hang, and it looks like
> a bug in our
> hardware.
>
> I got a response from Freescale today that is disturbing...
>
> >The way the internal buses work on the 5208 (and this will be the same
> >on most of our parts going forward), the bus monitor that you are
> >looking at will really only count for accesses in the internal register
> >space. Once an access is passed on to one of the slave ports like the
> >FlexBus, SDRAMC, or SRAM, the bus monitor isn't really in the picture
> >anymore. So the bus monitor is really only going to terminate hung
> >accesses in the internal register space (0xF0000000-0xFFFFFFFF).
>
> >It sounds like you are accessing space within the FlexBus memory area
> >that isn't mapped to a chip select, right? I just tried this on a board
> >myself and there doesn't seem to be any way to gracefully recover except
> >for a reset. I'm talking to the design team now about changing this for
> >future devices and possibly even fixing it on the 5208/7 and 523x and
> >537x parts if there are respins on any of those parts.
>
> I've tried to setup the debug breakpoint monitoring stuff to catch
> these, but
> that does not seem to work either.
>
> On a 5272 if I setup the debug breakpoint to trap on access to some
> memory range,
> then it generates a debug trap if the specified range is mapped,
> and an access error if the specified range is unmapped.
>
> On the 5208 the debug breakpoint trap generates a debug trap if the
> memory is mapped,
> and just hangs if it is not mapped. This makes me thing that the debug
> break point logic happens at
> the end of the bus cycle.
>
> I've also tried to setup a core fault interrupt register, and it does
> not seem to work.
> This makes sense as the CPU can't recognize an interrupt until it
> finishes it's
> present instruction. I've also put a variety of values into the BMT
> register to no avail.
>
> Has anyone else fought this problem and reached a solution?
>
>
>
> Paul
>
>
>
>
>
>
> --------------------------------------------------------------------

--
Brett Swimley
Sr. Design Engineer
Advanced Electronic Designs
406-585-8892

brett DOT swimley AT aedinc DOT net

--------------------------------------------------------------------

Jan 12, 2006, 5:51 AM

Post #3 of 11 (69 views)
Copy Shortcut
RE: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

Paul
Most of the CF cores have access control registers that can be used to
trap access attempts to non-existent memory. It has been quite a while
since I looked at the 5200 series chips, so I don't remember what they
have for ACRs. If you configure the chip through the CACR to inhibit
access to memory that is not configured by the ACRs, you get an
exception rather than a hang.

From a more global prospective, if you can't trust all the applications
that will be loaded into your target, you should probably be looking for
a chip with an MMU and an OS with protection domains. This will prevent
an errant process from stepping on the rest of the system. I would
suggest the V4e chipsets (5471 etc...). As for OS selection, our OS
(vxWorks) does not yet have MMU support for the coldfire architecture.
I'd be reluctant to recommend a competitors product but I'm sure someone
out there will.

Rich Carter
Wind River Systems
603-897-2071

> -----Original Message-----
> From: On Behalf Of Paul Breed
> Sent: Wednesday, January 11, 2006 5:16 PM
> To: Carter, Richard
> Subject: [ColdFire] MCF5208 Access errors...
>
> I am in the process of porting to the 5208.
>
> I'm currently having problems with access errors, any other
> coldfire I've ever worked on would generate an access error
> trap if you accessed unmapped memory.
>
> (For example it is a Netburner rule that memory around 0 will
> not be valid so Null pointer accesses will generate traps.)
>
>
> The 5208 does not trap it just hangs.
>
> This is a problem for us, because we do not directly control
> the code that runs on our modules. (our customers write their
> own code) so that if a customer makes a coding error and
> overflows a stack or references a Null pointer the system
> will just hang, and it looks like a bug in our hardware.
>
> I got a response from Freescale today that is disturbing...
>
> >The way the internal buses work on the 5208 (and this will
> be the same >on most of our parts going forward), the bus
> monitor that you are >looking at will really only count for
> accesses in the internal register >space. Once an access is
> passed on to one of the slave ports like the >FlexBus,
> SDRAMC, or SRAM, the bus monitor isn't really in the picture
> >anymore. So the bus monitor is really only going to
> terminate hung >accesses in the internal register space
> (0xF0000000-0xFFFFFFFF).
>
> >It sounds like you are accessing space within the FlexBus
> memory area >that isn't mapped to a chip select, right? I
> just tried this on a board >myself and there doesn't seem to
> be any way to gracefully recover except >for a reset. I'm
> talking to the design team now about changing this for
> >future devices and possibly even fixing it on the 5208/7 and
> 523x and >537x parts if there are respins on any of those parts.
>
> I've tried to setup the debug breakpoint monitoring stuff to
> catch these, but that does not seem to work either.
>
> On a 5272 if I setup the debug breakpoint to trap on access
> to some memory range, then it generates a debug trap if the
> specified range is mapped, and an access error if the
> specified range is unmapped.
>
> On the 5208 the debug breakpoint trap generates a debug trap
> if the memory is mapped, and just hangs if it is not mapped.
> This makes me thing that the debug break point logic happens
> at the end of the bus cycle.
>
> I've also tried to setup a core fault interrupt register, and
> it does not seem to work.
> This makes sense as the CPU can't recognize an interrupt
> until it finishes it's present instruction. I've also put a
> variety of values into the BMT register to no avail.
>
> Has anyone else fought this problem and reached a solution?
>
>
>
> Paul
>
>
>
>
>
>
> --------------------------------------------------------------------

Jan 12, 2006, 7:31 AM

Post #4 of 11 (68 views)
Copy Shortcut
Re: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

Paul -

We had one other thought here.

I'm not familiar with the 5208, but is there a chance you could get a
workaround going with a Watchdog timeout? Or, does the processor hang
to the point where even the Watchog doesn't trip?

Good luck,

Brett

Paul Breed wrote:

> I am in the process of porting to the 5208.
>
> I'm currently having problems with access errors,
> any other coldfire I've ever worked on would generate an access error
> trap
> if you accessed unmapped memory.
>
> (For example it is a Netburner rule that memory around 0 will not be
> valid so
> Null pointer accesses will generate traps.)
>
>
> The 5208 does not trap it just hangs.
>
> This is a problem for us, because we do not directly control the
> code that runs on our modules. (our customers write their own code)
> so that if a customer makes a coding error and overflows a stack or
> references a Null pointer the system will just hang, and it looks like
> a bug in our
> hardware.
>
> I got a response from Freescale today that is disturbing...
>
> >The way the internal buses work on the 5208 (and this will be the same
> >on most of our parts going forward), the bus monitor that you are
> >looking at will really only count for accesses in the internal register
> >space. Once an access is passed on to one of the slave ports like the
> >FlexBus, SDRAMC, or SRAM, the bus monitor isn't really in the picture
> >anymore. So the bus monitor is really only going to terminate hung
> >accesses in the internal register space (0xF0000000-0xFFFFFFFF).
>
> >It sounds like you are accessing space within the FlexBus memory area
> >that isn't mapped to a chip select, right? I just tried this on a board
> >myself and there doesn't seem to be any way to gracefully recover except
> >for a reset. I'm talking to the design team now about changing this for
> >future devices and possibly even fixing it on the 5208/7 and 523x and
> >537x parts if there are respins on any of those parts.
>
> I've tried to setup the debug breakpoint monitoring stuff to catch
> these, but
> that does not seem to work either.
>
> On a 5272 if I setup the debug breakpoint to trap on access to some
> memory range,
> then it generates a debug trap if the specified range is mapped,
> and an access error if the specified range is unmapped.
>
> On the 5208 the debug breakpoint trap generates a debug trap if the
> memory is mapped,
> and just hangs if it is not mapped. This makes me thing that the debug
> break point logic happens at
> the end of the bus cycle.
>
> I've also tried to setup a core fault interrupt register, and it does
> not seem to work.
> This makes sense as the CPU can't recognize an interrupt until it
> finishes it's
> present instruction. I've also put a variety of values into the BMT
> register to no avail.
>
> Has anyone else fought this problem and reached a solution?
>
>
>
> Paul
>
>
>
>
>
>

Brett Swimley
Sr. Design Engineer
Advanced Electronic Designs
406-585-8892

brett DOT swimley AT aedinc DOT net

--------------------------------------------------------------------

Message Edited by Dietrich on 04-01-2006 11:40 AM

Message Edited by Dietrich on 04-04-2006 09:40 PM

Re: MCF5208 Access errors...

Dietrich — Sat, 01 Apr 2006 06:35:56 GMT

Jan 12, 2006, 8:01 AM

Post #5 of 11 (67 views)
Copy Shortcut
Re: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

Brett,

I noticed a similar issue with the 547x. Accesses to invalid memory
addresses would hang the processor for ~30 seconds on our 547x running at
133/266MHz. The issue was resolved by configuring the XLB arbiter address
tenure timeout and data tenure timeout to values smaller than the defaults.
To trap these invalid accesses I enabled the XLB arbiter interrupt on either
an address tenure timeout or a data tenure timeout.

Ken

>Would the 547/8x series of processors have the same issue?
--------------------------------------------------------------------

Jan 12, 2006, 9:13 AM

Post #6 of 11 (64 views)
Copy Shortcut
RE: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

All previous 52xx cores would allow you to enable the bus time out
monitor and then generate
a access error trap if you timed out. The 5208 is set up differently.

The manual seems to indicate that you can set up an interrupt to
happed if the bus times out,
alas I've been unable to make that work with the CPU, if I point the ethernet
at a bad area I get an interrupt, but not if I point the core CPU.

I can recover witht he watchdog, but it just tells me something happened,
not what and where like the access error trap.

Paul

At 05:51 AM 1/12/2006, you wrote:
>Paul
>Most of the CF cores have access control registers that can be used to
>trap access attempts to non-existent memory. It has been quite a while
>since I looked at the 5200 series chips, so I don't remember what they
>have for ACRs. If you configure the chip through the CACR to inhibit
>access to memory that is not configured by the ACRs, you get an
>exception rather than a hang.
>
> >From a more global prospective, if you can't trust all the applications
>that will be loaded into your target, you should probably be looking for
>a chip with an MMU and an OS with protection domains. This will prevent
>an errant process from stepping on the rest of the system. I would
>suggest the V4e chipsets (5471 etc...). As for OS selection, our OS
>(vxWorks) does not yet have MMU support for the coldfire architecture.
>I'd be reluctant to recommend a competitors product but I'm sure someone
>out there will.
>
>Rich Carter
>Wind River Systems
>603-897-2071
>
>
> > -----Original Message-----
> > From: On Behalf Of Paul Breed
> > Sent: Wednesday, January 11, 2006 5:16 PM
> > To: Carter, Richard
> > Subject: [ColdFire] MCF5208 Access errors...
> >
> > I am in the process of porting to the 5208.
> >
> > I'm currently having problems with access errors, any other
> > coldfire I've ever worked on would generate an access error
> > trap if you accessed unmapped memory.
> >
> > (For example it is a Netburner rule that memory around 0 will
> > not be valid so Null pointer accesses will generate traps.)
> >
> >
> > The 5208 does not trap it just hangs.
> >
> > This is a problem for us, because we do not directly control
> > the code that runs on our modules. (our customers write their
> > own code) so that if a customer makes a coding error and
> > overflows a stack or references a Null pointer the system
> > will just hang, and it looks like a bug in our hardware.
> >
> > I got a response from Freescale today that is disturbing...
> >
> > >The way the internal buses work on the 5208 (and this will
> > be the same >on most of our parts going forward), the bus
> > monitor that you are >looking at will really only count for
> > accesses in the internal register >space. Once an access is
> > passed on to one of the slave ports like the >FlexBus,
> > SDRAMC, or SRAM, the bus monitor isn't really in the picture
> > >anymore. So the bus monitor is really only going to
> > terminate hung >accesses in the internal register space
> > (0xF0000000-0xFFFFFFFF).
> >
> > >It sounds like you are accessing space within the FlexBus
> > memory area >that isn't mapped to a chip select, right? I
> > just tried this on a board >myself and there doesn't seem to
> > be any way to gracefully recover except >for a reset. I'm
> > talking to the design team now about changing this for
> > >future devices and possibly even fixing it on the 5208/7 and
> > 523x and >537x parts if there are respins on any of those parts.
> >
> > I've tried to setup the debug breakpoint monitoring stuff to
> > catch these, but that does not seem to work either.
> >
> > On a 5272 if I setup the debug breakpoint to trap on access
> > to some memory range, then it generates a debug trap if the
> > specified range is mapped, and an access error if the
> > specified range is unmapped.
> >
> > On the 5208 the debug breakpoint trap generates a debug trap
> > if the memory is mapped, and just hangs if it is not mapped.
> > This makes me thing that the debug break point logic happens
> > at the end of the bus cycle.
> >
> > I've also tried to setup a core fault interrupt register, and
> > it does not seem to work.
> > This makes sense as the CPU can't recognize an interrupt
> > until it finishes it's present instruction. I've also put a
> > variety of values into the BMT register to no avail.
> >
> > Has anyone else fought this problem and reached a solution?
> >
> >
> >
> > Paul
> >
> >
> >
> >
> >
> >
> > --------------------------------------------------------------------
--------------------------------------------------------------------

Jan 12, 2006, 9:32 AM

Post #7 of 11 (64 views)
Copy Shortcut
Re: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

Ken -

Thanks for the info. I will look into this and see if this resolves my
issue.

Regards,

Brett

Ken Johnson wrote:

>Brett,
>
>I noticed a similar issue with the 547x. Accesses to invalid memory
>addresses would hang the processor for ~30 seconds on our 547x running at
>133/266MHz. The issue was resolved by configuring the XLB arbiter address
>tenure timeout and data tenure timeout to values smaller than the defaults.
>To trap these invalid accesses I enabled the XLB arbiter interrupt on either
>an address tenure timeout or a data tenure timeout.
>
>Ken
>
>
>
>>Would the 547/8x series of processors have the same issue?
>>
>>
>--------------------------------------------------------------------

Brett Swimley
Sr. Design Engineer
Advanced Electronic Designs
406-585-8892

brett DOT swimley AT aedinc DOT net

--------------------------------------------------------------------

Jan 12, 2006, 9:45 AM

Post #8 of 11 (65 views)
Copy Shortcut
Re: [Listserv] [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

You could always add an external bus monitor
implemented in a PLD... for a lot more money
than what was saved in the die area used by
on-chip external bus monitor. Personally, I
think removing it from MMU-less parts was a
mistake, because it complicates development
and would incite me to look at competitor's
part. On the other hand, other MCF52xx have
the BM only monitoring external accesses, so
addressing an unused location within the
register space would also hang the processor.
Aaargh! What's up Freescale, this used to
work just fine in the 683xx days!

Marc

Jan 12, 2006, 2:26 PM

Post #9 of 11 (62 views)
Copy Shortcut
Re: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

I believe I have a partial work around.
I map chipselect to the unused areas and the
use the chipselect to trigger an external interrupt to capture the location.

This keeps the chip from hanging, reading for an area that is not
actively decoded
has unpredictable results, but it should be caught immediately when the
interrupt goes off.

Another note for those working with the 5208, for the first time
the chipselects are restricted to specific address ranges.

Make sure you read the notes in

6.2.1 RAMBAR
18.4.5 SDRAMC
17.3.2.1 Flexbus

The information is not in the body of the text but as a separate note.

Paul

--------------------------------------------------------------------

Jan 12, 2006, 10:16 PM

Post #10 of 11 (62 views)
Copy Shortcut
Re: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

I've done a bunch more work on the access error stuff.
Results and comments below:

My 5208 Nominal Memory Map
0x00000000 to 0x3FFFFFFF not used
0x40000000 to 0x41FFFFFF Mapped to SDRAM
0x41FFFFFF to 0x7FFFFFFF not used
0x80000000 to 0x80003FFF Internal RAM via Rambar
0x80004000 to 0xBFFFFFFF not used
0xC0000000 to 0xC01FFFFF Mapped to Flash
0xC0200000 to 0xFC000000 not used
0xFC000000 to 0xFFFFFFFF maped into CPU registers

The problem with this is that the FlexBus areas 0x0 to 0x3FFFFFFF and
0xC0200000 to 0xDFFFFFFF will cause the processor to hang when accessing these
areas. So I thought if I could map these areas to a CS and then detect these
accesses I would be able to live with that.

To test this I tried to fix the lowest gap area.
CS1 was assigned the range 0 to 3FFFFFFF to map unused lower flexbus area.
Note that CS1 was not used externally and could be assigned to be GPIO, I
am only using the automatic TA generation facilities of CS1.
To watch over this lower flexbus area the the debug trap system was
setup to watch this range with:

WDEBUG( 7, 0 );
WDEBUG( 6, 0xff7f );
WDEBUG( 0x0D,0 );
WDEBUG( 0x0C,0x3FFFFFFF );
WDEBUG( 7, 0x80002008 );

Where WDEBUG is a macro that writes to the debug registers described in
the users manual chapter 26.

I also set up the bus monitor:

SetIntc((long)&XBSFaultHandeler, 62, 7, 7 );
sim.scm1.bmt=0x0C;
sim.scm2.scmisr=3;
sim.scm2.cfier=1;

Then we set up the following deviant cases, not perfect, but
representative of the
kinds of faults one sees:
.text
.EQU BADADDRESS, 0xFBFFFFF0

.global Fault1
.global Fault2
.global Fault3
.global Fault4
.global Fault5
.global FaultValue
DoNormalReturn:
rts

FaultValue:
move.l #BADADDRESS,%d0
move.l %d0,%d1
rts

Fault1:
move.l BADADDRESS,%d0
nop
rts

Fault2:
move.l %d0,BADADDRESS
nop
rts

Fault3:
move.l #BADADDRESS,%d0
move.l %d0,%a7
rts

Fault4:
move.l #BADADDRESS,%d0
move.l %d0,%a7
nop
jsr DoNormalReturn

Fault5:
jmp BADADDRESS
nop
rts

Results:
Fault Memory address tested for all 5 fault modes.

0 All ok
0x3FFFFFF0 All OK
0x42000000 All OK
0x7FFFFFF0 All OK
0x80004000 All OK
0x8FFFFFF0 All OK
0x90000000 All Ok
0xBFFFFFF0 All Ok
0xC0200000 Missed all faults but #5, result is a hang
0xDFFFFFF0 Missed all faults, hung for all
0xE0000000 Missed fault#3 as I expect A7 was decremented into Flexbus space.
0xE0000010 All Ok
0xFBFFFFF0 Case #1,#2 failed with write or read to improper area, all other ok

I deemed the test a success if it generated one of the following:
Access error trap
Debug trap
Bus monitor interrupt.

So in the present state it looks like the only problem are is the flexbus area
from 0xC0200000 to 0xDFFFFFFF

On Friday I will try tieing an unused chip select to an interrupt line
and see if I can catch the lions portion of this area.

While not the ideal solution it looks like it is workable until Freescale
figures out how to catch access traps on the 5208.

Paul

--------------------------------------------------------------------

Jan 13, 2006, 11:11 AM

Post #11 of 11 (60 views)
Copy Shortcut
Re: [ColdFire] MCF5208 Access errors... [In reply to] Can't Post

--------------------------------------------------------------------------------

This should be my final post on this subject....
It won't make a lot of sense unless you also read last nights post on
this subject.

I have a configuration that catches all five of my test fault cases for
all addresses....

The Rambar, and SDRAMC cases are caught by the core fault detection interrupt.

The Flex bus is caught two ways....

For access in the 0 to 3FFF FFFF range
I assign a chipselect in this region and tie it to an IRQ line that I
setup to be negative edge sensitive.
Thus any access there will be terminated, but will immediately cause
an interrupt.

For the C000 0000 to EFFF FFFF range I do the following:
1)I set up my flash chipselects to cover the entire region.
2)I use the debug breakpoint trap hardware to detect any accesses
in the region that is supposed to be unmapped.

In my present test case I'm only using flexbus CS0, in the future if
I'm actually going to use additional flexbus chipselects, I need to
bunch them together
and then use one additional CS to map the unused region with the
debug trap stuff
still providing the protection.

I've tested this scheme on the 5208 EVB board with the CS1 (the unused RAM CS)
tied to IRQ4 for the protection described.

It caught all 5 fault cases for all the address corner cases I
described in yesterday evenings mail.

Paul

Message Edited by Dietrich on 04-01-2006 11:39 AM

Message Edited by Dietrich on 04-04-2006 09:39 PM