This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

error 65: Access Violation

Hi,

I am simulating my code using the uVision v2.33.

When I am exiting a function i get the following error:

error 65: Access violation at address 0x00BA0180. and the simulator jumps to disassembly window.

I have read the forum and the doc abt access violation errors but am not able to understand why I am getting the error on exiting a function?

I am searching for an answer in the C166 manuals and the ST10f269 manual. But am directionless right now.

If anyone is familiar or knows the problem area, please share it with me.

Regards
Deepak

  • First question, do you expect something at address 0xBA0180? Sounds like you don't or at least the simulator doesn't thinks so. I would suggest that you enable the trace option for the simulator and look to your code perhaps you have a bad pointer.

  • Probably stack corruption or stack overflow.
    Something scrambled the return address that would have pointed from that function to the code that called it. Instead, it jumped somewhere into the blue, or more precisely into a region where, according to your debugger setup files, there is no code to be executed. So something must have modified stack contents.

    To really see what's going on, you'ld have to keep an eye on the uVision Call stack display and the SP register while you step slowly from beginning to exit of that function. And switch to machinecode-level debugging (in the disassembly window) near the end.

  • Thanks for the guidance.

    I made some progress by single stepping through the Disassembly listing..

    BUT PLEASE DON"T STOP READING FROM HERE, COZ STILL NEED YOUR GUIDANCE SO PLEASE CONTINUE READING..

    A)
    I
    found out that the return address is not getting correctly popped out of the System Stack on executing the RETS instruction at the end of the function.

    This led to an arbitrary value getting written to the IP at which place there is no code.. so gettign the access violation.

    To find out where exactly the SP is getting garbled I single stepped once more and found out that the IP jumps to a function in between even though that function is not called for.

    The exact assemply listing is below..

    181: ngFireInput_temp = ngFireInput;
    182:
    183:
    0000058C D7000E00 EXTS #0x000E,#1
    00000590 F2F40D2B MOV R4,DPP0:0x2B0D
    00000594 F6F47889 MOV DPP2:0x0978,R4

    on executing the MOV instruction at the address 00000590 above, the code jumps to a location 00000028. This location happens to be the entry point of "isalpha" fn.

    The execution continues and there is popping of the stack at the end of the fn even though there was no corresponding PUSHING.. this was causing the stack pointer to go haywire..

    B)
    Now
    I am looking for a reason why the code is jumping after executing the MOV.. one reason that I can think of is that the variable ngFireInput is of int type but is located at the address 0x0E2B0D which is an ODD address !!
    Could this be causing a TRAP to be generated??

    1. If this is the reason how can I fix it?
    2. Why would the locater locate an int at an ODD address. Integers are to be aligned at even addresses if I am right?

    Please if you can give some insight on the problem while I am tryin to fix it

    Regards

  • Why did you make another post?

    You need to put your trap routine at the proper address as the controller will jump to 0x000028 for any Class B trap. Perhaps you should include the Keil "traps.c" as an example and then add your specific code to each routine such as reading the TFR to see what the reason for the trap. If the bit ILLOPA is set then you have an odd word access problem.

    As far as your variable example I look at how the variables are being declared in the memory map for a clue. Perhaps you need to send a test case to Keil.