RE: Mysterious exceptions

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/