RE: Virtual Watchdog Timeout

Daniel,

 

Can you provide some more information?  You need to combine the XPC value and address to get the physical address of where the exception occurred.  Look in your MAP file to track down the function that caused the problem.  For example, I modified the ErrorHandling/Define_error_handler.c sample to throw exceptions from a function compiled to xmem, and got the following in the Stdio window:

 

Domain error (run time exception -710) occurred at 003:e2e9                     

  - Execution being passed back to program...                                   

Range error (run time exception -711) occurred at 004:eaa6                      

  - Execution being passed back to program...                                   

 

And when I look into the MAP file for the sample, I have the following:

 

0003:e2bf      180   acos                            \MATH.C                          1765

…

0004:ea8f      138   fmod                            \MATH.C                          2227

 

And sure enough, when I look at the program I see that those are the functions called to demonstrate exception handling.

 

You might also want to generate an LST file when you compile your program, so you can see exactly what code exists near a given address.

 

Hope that helps you to narrow down the problem.  If you’d like, you can email me off-list with the MAP for your program and a dump of the runtime exceptions being reported, and I’ll help you to track down the failures.

 

-Tom

 

From: [email protected] [mailto:[email protected]] 
Sent: Friday, November 06, 2015 9:04 AM
To: [email protected]
Subject: [rabbit-semi] Virtual Watchdog Timeout

 

  

I have very annoying Virtual Watchdog Timeout issues sometimes in my RCM6700 software that otherwise works perfectly. But every once in awhile I will load a build onto a RCM (that works fine with zero WDT on another RCM in the programmer), and it will just give me VWDT errors over and over and just crash (very annoying when the RCM is installed in a enclosure and it has to be taken apart to get to the card) 

 

I have a crash handler, but it gives me the address of the crash handler for the error (it seems) not the address of the ostensibly responsible code. Is there any way to figure out where exactly the software is getting stuck from the address the runtimeErrorHandler spits out?

 

My error handler prototype is: 

 

void myRuntimeErrHandler(int error_code, int more_info,int xpc_val, int address)

 

Any help with this would be greatly appreciated. I'm loosing faith in these RCM processors fast with their inability to report what is actually gone wrong even when you write a error handler to report just that to you!