I made a development board with DS5000FP and downloaded Mon51 for DS5000 on SRAM by using DS5000 bootstap loader. Debugger when it is started can load the compiled code to 0x2000 address where I put my code. After the start up a yellow arrow stay at 0x0000 address. When I start to run program, the mon51 doesn't give handle to user program and resume the yellow arrow's position to 0x0000 address. I tried another thing to give program handle to user program with G 0x2000 but same result i got. Mon51 looks like works perfectly except doesn't give the handle to program
Thanks Dave for your concern but i still trying to fix the problem, i tried the things you said before. Unfortunately with no succes. Even reconfigured the Mon51.hex file but at the end i reached same problem. Probably i skip one important step ????. Anyway I modifying system to von-neumann wiring. Regards, Tugrul
I got the same problem with Mon51 in a DS5000. Have anyone got a successful instalation?
When you say 'give the handle to program', what exactly do you mean? Make sure you are following the procedures listed in this KB article: http://www.keil.com/support/docs/2446.htm Make sure the watchdog timer for the DS5000 has been disabled. Make sure your sample project is not overwriting the monitor Xdata area at 1F00h.
I mean the program seems to start run and after awhile the arrow stays at 0000 location. I put a simple assemble code at start adress of my program like making a port of DS5000 to pull high or low but it doesn't do that. But systam also work at ISD mode. I also did all checking at the link no way. Actually ı didn't remember the watchdog staff I will try is next week cause I am now in germany
Hello, The MON51.HEX file available for download from Keil, dated September 18th 2002, does not function properly. A new version of mon51.hex must be built. Follow the instructions in: http://www.keil.com/support/docs/2446.htm to modify the install.A51 file. In addition, rename the mon51.lib file supplied by Keil to something else and then rename mon51x.lib to mon51.lib. The mon51x.lib file is also supplied by Keil and was a corrected version of the origianl mon51.lib file, see http://www.keil.com/support/docs/2106.htm for details related to mon51x.lib. Finally, build a new version of mon51.hex by running install.bat with command line parameters of 0 7F. (install 0 7F) This worked for me in both small and large memory model applications on the DS5000 and DS5000T.
Hello, I had the same problems as mentioned by the other developers at this discussion thread. Thanks to advice of mr. Jon Ward (see Discussion forum thread No 5042 : "mon51_vs_DS5000") a managed to compile mon51.hex for DS 5000, but still have problems when debugging my application with MON51 on DS 5000 via uVision (see below). Could you tell me what am I doing wrong ? Could you send me your mon51.hex ? Thanks jfoot@volny.cz --------------------------------------- I compiled mon51 using install 0 7f with mon51x.lib instead of mon51.lib as was recommended. After it I loaded mon51 to my DS 5000 (using kit.exe with MCON set to E8), then I loaded my application which started at 0x2000 with ini file like this : $=0x2000 g,main (it seems to have a certain importancy when just the two commands are used in ini file for mVision debugger using mon51) Situation now differs from described previously. Program counter is correctly set on first instruction of function main and local variables are correctly initialized to zeros. I am able to single step my application ant put breaks. When I want to single step my program via MVision programs falls after a while to command : C:0x2000 022010 LJMP STARTUP1(C:2010) What is interesting, when I am using the command "Run to cursor line" in mVision and thus, simulate "single stepping", I can see that my application runs because of changing content of accumulator and registers seen in Register windows, In addition, changes (seen in Watch window) appear to be in agreement (partly) with my application. Then I fixed my eyes on MCON a DALLAS family micons. I must admit that I caused a bit misunderstanding in my last contribution to Keil's discussion forum. I have searched in Dallas data book for detailed information on my DS 5000 and where is what I've found : I 've got module DS 5000 32 - 16, in 40 pIN DIP, which consist of chip called DS 5000 FP and internal 32 kbyte NVRAM. As far as MCON is concerned : bits MCON.7-4 are used for partitioning like this : PA3 PA2 PA1 PA0 Partition Address 0 0 0 0 0000H 0 0 0 1 0800H 0 0 1 0 1000H 0 0 1 1 1800H 0 1 0 0 2000H 0 1 0 1 2800H 0 1 1 0 3000H 0 1 1 1 3800H 1 0 0 0 4000H 1 0 0 1 4800H 1 0 1 0 5000H 1 0 1 1 5800H 1 1 0 0 6000H 1 1 0 1 6800H 1 1 1 0 7000H 1 1 1 1 8000H I would say that all DS 5000 are using this scheme. Settings of MCON can only differ when considering internal NVRAM of module DS 5000, which can be 8 kbyte or 32 kbyte. This information called "range adress" is to set in MCON.3 to 1 if used DS5000 has 32 kbyte of NVRAM (which is my case) instead of only 8 kbyte. The remaining bits of MCON should be set as follows : MCON.2 - to 0 if the DS 5000 doesn't contain a real time clock MCON.1 - it's PAA bit vith known meaning MCON.0 - security lock - initation of security set, if security is not set it has value = 0 Regarding these information I modified install.a51 only as follows : USER_PGM_START EQU 2000H USER_PGM_MCON EQU 38H ; 1800h uses 32 kbyte NVRAM USER_XRAM_MCON EQU 0E8H ; 7000h uses 32 kbyte NVRAM then compiled new mon51 using : 0 7f and loaded it into DS 5000. Then I started mVision, loaded my aplication and I put a breakpoint at the end of main function and started degug (till th