Dwayne Dietrich

MCF5208 Access errors...

Discussion created by Dwayne Dietrich Employee on Mar 31, 2006
Latest reply on Mar 31, 2006 by Dwayne Dietrich
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

Outcomes