Re: Virtual Watchdog Timeout

Daniel,

Note that it wasn't just that part of the address, it includes the XPC value (or LXPC, I believe, on Rabbit 4000 and later).  The Rabbit uses segmented memory, so to figure out the physical address you need to overlap the bottom 4 bits of the XPC with the address.  So looking at 04:e2e9, you're actually at physical address 0x122E9.

By viewing the MAP file, I determined that the address 04:e2bf is the start of the function acos().  The next entry in the MAP file was an address that came after the exception location, so I can be fairly confident that the exception occurred INSIDE the acos() function.

The exception happened at 04:e2e9, 42 bytes into the function.  If I had configured Dynamic C to generate a LST file for the compiled program, I could look into it and find the exact line of C code that was throwing the exception.  The LST file shows the C code and all of the assembly generated for it.

Hope that helps.

You are correct, that it can be very difficult to debug an issue where some value is overwritten, since the program doesn't crash until the part that makes use of the corrupted value.

-Tom


On Nov 19, 2015, at 7:54 AM, [email protected] [rabbit-semi] wrote:
> Can you help me understand the relationship between the addresses being thrown as the exceptions and the MAP file? You had address e2e9, but then the MAP file had e2bf as the address for the acos function that was causing the exception. I find this to generally be the problem I see. No real relationship between the address that gets thrown and anything meaningful to look at in the map file...