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

access violation to reserved memory

Hi every one
I encounter with this error during debugging my program in Keil:

*** error 65: access violation at 0x0FFE443C : no 'write' permission

I am using LPC1768. this area that compiler effort to access is reserved in LPC1768 Memory Map.

My program is using dynamic sized variables and I also changed heap and stack size in

Startup; but there were the same errors

Why this kind of error occurs? Can every one help me?

  • If you are running the simulator, the root cause is that the chip is not fully supported.

  • The Keil processor simulator is not able to simulate everything in every processor. It's common to get memory access errors when trying to access hardware that the simulator can't simulate.

    Try to run your program on a real processor instead. Or maybe spend some time using the search function on this site - then you would find other people asking similar questions. And you would find the answers they have been given.

  • I also debug the program in the chip and the same errors as in simulator occurred.

  • I searched in this site but didn't find any thing about the violation errors to reserved memory.if you can help me about it ,i will be appreciative

  • when I debug it on real chip a hard fault occurs ...

  • If you get a memory violation on the real chip, then it's time to start debugging your code.

    Make sure the memory regions specified in the project file really matches the memory in the chip.

    Make sure all your pointers are valid.

    Make sure you don't get a stack overflow.

    Make sure you don't make out-of-bounds accesses to buffers.

    Make sure all variables shared between multiple tasks or between interrupt handlers and main code are properly protected from concurrent updates - and are declared volatile when needed.

    Make sure no part of the processor is overclocked.

    Have your functions validate the input parameters.

    Have your functions validate the produced results.

    In short: start to debug your code.

  • thanks for your help.
    these parameters you said to check via debugging are new for me.can you explain how to check them or can you introduce me some references or links to learn how to check all these parameters.
    thanks

  • Make sure the memory regions specified in the project file really matches the memory in the chip:

    the error occurs in memset()command in debugging.
    also I guess that heap size is low, so I increased it as the chips memory allowed me. i encountered with the same error but not in the same line of my code. code execution continues more than before, and the error occurred in different line whenever reaches to memset() command. in this line of code, memset() is allocating 5800 doubles.
    I also used LPC1788 for more SRAM Memory, and increased heap size more and more but this error always occurs when execution reaches to allocating 5800 doubles by memset command.

  • "the error occurs in memset()command in debugging."

    Excellent. So just verify the size of the block you try to memset(), and verify the target address. It shouldn't take long to figure out if you try to memset() memory that doesn't exist.

    You are playing with the heap size - but are you verifying if your heap allocations actually returns the requested memory? You should catch allocation failures directly on the allocation instead of handing over the pointer to memset() and have memset() fail.

    5800 doubles? Have you computed the total memory size needed for them? Is your heap large enough for that? Have you taken into account, that every heap allocation needs to consume a number of bytes extra for book-keeping?

    "reaches to allocating 5800 doubles by memset "

    Not sure what you mean by this sentence - memset() isn't allocating any memory. It just initializes the content of memory your program already needs to "own".

  • 5800 doubles needs almost 23KB memory.in lpc1788 i can use at least 64KB of RAM. do you think that this large amount can be problem of my program?

    as you said, i debug the program and search in this site, i guess that this local array(5800 doubles) needs more _data_group memory. can it be true? if it is true, how can i increase the memory referred to _data_group.
    i just consume 10KB of my RAM. can I allocate remained RAM to Local variables? can it solve my problem?

    thanks for your helps.

  • i also changed heap size more than 24KB and also increase stack size.i don't know how i can determine how much heap and stack size the program needs, so i just increased it as much as possible! i know it's not a good method.

  • A float would require 4 bytes. A double - for a compiler that supports the double data type and doesn't downgrade it to a float - would require at least 8 bytes. So an array of 5800 double would be at least 46400 bytes. That's twice your heap size.

    Why are you experimenting? The compiler can tell you the required size of the array with the operator sizeof. And malloc() would not return a real pointer value if the heap is too small so the allocation fails. Any call to malloc() or calloc() should verify the returned value.

    So how can you not know if the program is able to perform all required heap allocations?

  • yes, you are right.so, how can i use compiler to tell me required heap size?
    i don't know what you mean by the last line:
    So how can you not know if the program is able to perform all required heap allocations?

    also what is your opinion about _DATA_GROUP that i mentioned in last post?

    thanks.

  • >>i don't know how i can determine how much heap and stack size the program needs

    So evaluate it. Instrument the malloc/free so you know the types and maximal usage cases. Evaluate the maximum stack depth, see how much it needs dynamically by marking the stack and seeing the high-water mark, look at the static analysis/call tree generated by the linker, and your own assessment of what the heck your code does or might be expected too.

    The kinds of double array described takes 46KB

    As Per notes now can you not check the allocated pointer before using them, the library should clearly indicate if the heap is exhausted or too fragmented to fulfill the request. Add some diagnostics and instrumentation so you know what your code is doing, and how it is failing.