[U-Boot-Users] exception setting for TQ860L

[U-Boot-Users] exception setting for TQ860L

[Oravec Ivan]

Hello,
 
is there some special setting necessary to see any possible exception. What
is the default state for CCM board.
Can Linux overwrite setting done by u-boot.
There is running application on Linux and at higher temp there is a SW
watchdog generated. Now I would like to see the root cause if possible.
If I change SYPCR:SWRI, card is frozen. If SWRI is active HRESET is
triggered and card restarts.
 
thank you    
best regrads
ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20050826/29090ee7/attachment.htm 

[U-Boot-Users] exception setting for TQ860L

[Jerry Van Baren]

Oravec Ivan wrote:
> Hello,
>  
> is there some special setting necessary to see any possible exception. 
> What is the default state for CCM board.
> Can Linux overwrite setting done by u-boot.
> There is running application on Linux and at higher temp there is a SW 
> watchdog generated. Now I would like to see the root cause if possible.
> If I change SYPCR:SWRI, card is frozen. If SWRI is active HRESET is 
> triggered and card restarts.
>  
> thank you   
> best regrads
> ivan

The root cause is that you have a hardware problem causing your system 
to stop executing code properly.  My speculation is a memory timing 
issue.  Power supply issues are another possiblility.  I don't recall 
ever having a crystal problem, they typically are unreliable starting up 
at very cold temps, not hot.

Since the WDT apparently gets things started again, this would point to 
a transient problem, which implies timing problems.

Do you have your processor set up to (a) reset or (b) halt on a 
checkstop?  If reset, it is likely you are _not_ getting a checkstop 
exception and you will need to look elsewhere.  If halt, I would look at 
the system when it breaks and see why it did a checkstop (usually a 
double bus fault).  Note that looking at the system when it breaks is 
much more difficult than it sounds.  A JTAG debugger can be helpful. 
Hooking a logic analyzer to the bus and seeing what the address and data 
are when an error signal occurs is another approach (typically even more 
difficult than JTAG but can be more useful in debugging the underlying 
hardware problem).

gvb