Re: Mysterious exceptions

Hello Randy!

Thank you for the advises.
I put the ICTRL initalisation code to my debugger, and now I get the 
exceptions even if I start up the board by the debugger. So the 
problem lies somewhere between being serialised or not.
I have code on all possible exception entries.
I looked at all my initialisation code and I have no clue where more 
should I put 'sync' to.
After which register writing should I put a sync instruction?
I put it after writing to PLPRCR, SCCR, after disabling dual mapping, 
SIUMCR, SYPCR, BBCMCR, L2UMCR. As for the memory controller, I think 
the memory controller activated after writing to the OR0. So I 
initialise first the OR1..OR3 registers, then the BRx, and at last the 
OR0 and then comes a sync. Is it OK?
Is the mtspr instruction a execution-syncronising? Do I have to put a 
sync between a mtlr and a blr instructions?


--- In [email protected], Dees Randy-rsaf30 <randy.dees@f...> 
wrote:
>
> keep in mind that enabling debug mode (by attaching the BDM cable) 
disables software access of all of the Development Control registers, 
including the ICTRL register. Only the debugger can write the 
Development Control registers in debug mode and writes by user 
software are ignored.
> 
> The ICTRL controls whether the RPCU runs in serial mode or in 
pipelined mode. the default is serialized, unless the ICTRL register 
is written with ICTRL[SER]=0b1. if a debugger is connected, then this 
register is only writeable from the debugger, so it should be 
initialized by debugger scripts to set the same ISCT_SER value that 
the user software uses. The RCPU has multiple execution units that can 
be used in parallel. Pipelining the core allows the different 
execution units be used at the same time. there are separate units for 
 load/store, integer unit, integer multiply/divide, branch processor, 
or floating point unit. 
> 
> a common cause of exceptions is using the contents of a memory 
before they get written by the core. registers in the core RCPU are 
protected from use until the contents are valid, but off-core 
registers or memory are not "reserved". common problems that could 
cause issues and need a "synchronizing" instruction (such as isync or 
sync on the RCPU) are:
> 1. Writing instructions into a memory and then jumping to the memory 
before the Load/store unit finishes writing the instructions into the 
memory.
> 2. change the bus properties of an external memory (in the memory 
controller - number of wait states, burst length, base address, etc.) 
and then trying to use that memory before the mode change actually 
occurs (or it changes modes while it's being used - very bad).
> 
> there are other examples, but these are the most common.
> 
> Debug mode also forces the bus monitor on.
> 
> make sure you put a handler at all of the exception addresses to 
watch for unexpected exceptions that you are not handling. 
> 
> randy
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Friday, November 18, 2005 9:51 AM
> To: [email protected]
> Subject: [MPC500] Mysterious exceptions
> 
> 
> Hello!
> 
> I now flashed an application program and I began (again) to receive 
> spurious exceptions. It seems my program somewhere goes astray and 
it 
> doesn't start the application as expected. I put some code to the OS 
> itself to cause an exception, and the result is that if I put this 
> code than it is executed, I see it in the exception log window (2nd 
> serial port), but when I remove it seems the code is not executed.
> (I cannot describe it better since I don't have a debugger)
> I suspected the exception handler or the interrupt handler have bug, 
> but this problem never occurred for ages, and came up again when I 
> reorganized the initialization sequence in the OS.
> 
> MOREOVER, If I attach the wiggler cable to the BDM port, and start 
the 
> mccraigor OCDaemon program, then the problem never occurs!!! Even if 
> I don't use the program at all!
> The difference is being the cable connected and not connected is 
that 
> the wiggler pulls the DSCK pin high with -SRESET causing the 
processor 
> to enable debug mode. I saw it on an oscilloscope.
> The OS anyway tries to disable the debug mode via resetting all bits 
> in the DER.
> 
> My question is that what is the side effect of the cable being 
> connected? What happens inside the RCPU if the cable is connected?
> 
> 
> Best regards
> Attila
>






------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page
http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/dN_tlB/TM
--------------------------------------------------------------------~-> 

-----------------------------------------------------------
To learn more about Freescale Microcontrollers, please visit
http://www.freescale.com/mcu


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/MPC500/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/