We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm relatively new to Keil and C167. I got an error: "error 65: access violation" while debugging an assembly program using simulator. I tried these 2 sets of assembly code 1) Using EXTS
EXTS #4, #3 mov r1, #0x0A mov r2, #0x1000 mov [r2], r1
mov DPP2, #0x0010 mov r1, #0x0A mov DPP2:0x1000, r1
Have you reconfigured and rebuilt the monitor to match your application mapping during debugging? The config.h file in the monitor directory contains the memory mapping macros. I always have a separate monitor project with each application project so the two are always in sync. Best luck Scott
Hi Scott, How do you create a separate monitor project with each application project? What I have been trying to do is, perhaps, something very simple, but I haven't been successful yet. All I'm trying to do is write some data into memory locations from 0x30000 onwards. I tried using EXTS and DPP. Maybe the way I'm doing is wrong... Can u suggest me what would the things I would have to do(in the assembly code and in the project settings) so that I can access(read from and write to) any part of the 1MB memory provided on the MCB167 Net board. It is very urgent now. Thanks. Deepak.
Deepak, I create a 'monitor' subdirectory under the application subdirectory, with version subdirectories if needed. In 'monitor' are the following 'source' files: BOOT167.A66 Boot code INST167.A66 Installation code CONFIG.INC Configuration macros BOOT.BAT Make BOOTCOPY.BAT Output distribution ABSTRACT.TXT Documentation These are all copied from C:\Keil\c166\monitor where there are instructions for their use/modification and a number of pre-built monitors for different development boards. I have a UV2 project which runs the boot.bat file which assembles and links everything. The bootcopy.bat then copies the output files back to the keil\c166\monitor subdirectory where the toolchain expects them to be. The abstract.txt file is displayed under the UV2 project options menu in the debugger monitor window. I make certain it describes the address map accurately. I find it very helpful to formalize the memory map in a separate document which shows the address ranges, monitor data and code areas and any block 'mirrors' which occur. This is often the first thing I do in the project. Once it is done and the config.inc matches it along with the project startup code (start167.166) I seldom have to change them or worry about addressing problems. Best luck, Scott