Hi all. I am testing one of atme arm7 libraries in keil 4 debugger. Initially i was receiving a write access violation error at the start of debugging and the debugger kept getting stuck in the remap section: *** error 65: access violation at 0x00000018: no 'execute/read' permission. Then i learnt that i could manually bypass this problem by manually mapping the addresses in Debug->memory map. i also made a text file and entered these lines:
MAP 0X00000000, 0X001FFFFF READ EXEC MAP 0X00200000, 0X002FFFFF READ WRITE MAP
I saved this file as DEBUG.INI and fed it to the debugger as initialization for mapping. It compiled with no error and once the debugger starts it shows those memory areas it has recognized itself togather with the two areas i have assigned. But **error 65 still persists and i still need to manually enter those lines for the debugger to start working. I am using At91sam7x256 with one of standard atmel libraries. I know those address areas might not be spesifically accurate for this chip but when i enter them manually in the memory map the debugger is okay. Why dosen't work with the DEBUG.INI file?
So debugging, or simulating?
I am Debugging with the simulator and it works just fine.but i need to enter those lines manually each time i want to test the code after any recompile. Debug.ini doesn't seem to have any effect. Thanks
None of the examples I can find have that third lone MAP instruction.
MAP instruction is used to display the current map. Have a look at this: http://www.keil.com/support/man/docs/uv3/uv3_cm_map.htm
any clue as why the debug.ini file is not working?
I somehow found a way to work around this issue. Every time i start debugging in the simulator i open the debug initialization file by accessing Debug->Function Editor(Open Ini File). Then i press compile and save in the editor which has just opened.i do this every time and the debugger starts working normally. it is way better than having to manually enter memory ranges in the memory map dialogue box after every minute change to the code. Maybe this is the normal practice. I wonder if the file extension i have used for DEBUG.INI is the culprit.