I'm trying to put the monitor in an EPROM so I don't have to download over USB (using FX2 device). I've done everything that I think is needed, but still get monitor error 22 - no code memory at 1212h. The hex file does not contain any data at address 1212! The load completes (i.e. download hits 100%) but debugger won't start up. I do see that during the download, one time, the processor does a read from address 1212h which is probably not an instruction fetch but a read from code memory (since it reads one byte from that region and that's all, while executing up around CXXX). Has anyone successfully gotten the monitor to run on their board?
This sounds like a problem with the monitor data area. That area MUST be von Neumann. The following knowledgebase article tells how to test that memory area to be sure it really is von Neumann. http://www.keil.com/support/docs/2104.htm Jon
I've done everything in the app note. I have Von-neumann memory in the right areas. There is no code in the hex file at address 1212h, but the debugger complains about that address - why? 0000 - 0fff = EPROM 1000 - 1fff = Von Neumann sram 2000 - 2fff = my FPGA 3000 - Bfff = Von Newmann sram C000 - DFFF = EPROM I build monitor for external, sio1, c0. INT_ADR_OFF is 8000 DEF_PC_VAL is 8000 B51 locate uses CODE at 3000, XDATA at 5000. Both are small. This program downloads, gets to 100%, but won't start up. The EPROM boots and runs, and "talks" to the monitor. Funny thing is that 1200 is the original default (or in some configurations) location for vectors and default PC (in inst_mon.a51 where INT_ADR_OFF is defined). It's as if something in the Keil debugger is trying to use address 1212 even though it should not be required.
I followed the note and turned off "Load Application at Startup". The response is Connected to Monitor-51 """"""""""""""""" instead of Connected to Monitor-51 V3.0 when I download monitor using USB control panel. So something is wrong with the basic monitor configuration. I have von neumann memory at 9F00 as required (actuall 0x9000 - 0x9FFF), so the monitor scratchpad should be ok. I can see reads and writes to that area and they look ok (read after write matches). So the monitor "talks", but not perfectly - or the source for the code downloaded is different. So I downloaded MY hex file from USB control panel - the same one used to program the PROM - and I get the proper message! I disable the EPROM with EA before doing this, so ALL memory in von-neumann. With EA =1 when I boot from EPROM, C000 and up is eprom, and 0000-0x0FFF is EPROM. Rest is ram, code or data. With EA=1 on FX2 part, internal sram is data only, not code/data, from 0x0000 to 0x1FFF. So we boot from EPROM and that area is not writable. The INT_ADR_OFF is set to 0x8000, so the debugger should not try and write to the code space (through XDATA) at address 0, but instead can mess with the tables at address 8000. Any ideas? Difference must be that the monitor
I have been working on this problem for THREE WEEKS. I really need the monitor source code so that I can trace through the code a bit, bet better listings, see why the "Connected..." message is messed up, get real M51 files so I know what areas are really used, etc. I get the "No code memory at 1212H" message repeatedly during load, but that address is only accessed ONE TIME. So the debugger continues to complain about that address, without even accessing it. If it keeps track of bad addresses internally, then it makes sense of course, but if not then I should be seeing repeated accesses to 1212H but I do not.
Connected to Monitor-51 """"""""""""""""" instead of Connected to Monitor-51 V3.0 This is the kind of thing you'll get when the monitor data area is not working correctly. Have you actually written a program to verify that the von Neumann area used for the monitor can be written and read from XDATA and from CODE space? Jon
I really need the monitor source code... I really hate to tell you this, but everyone who has said this to me was 10x more lost with the monitor source code. At the end of the day, the monitor source code didn't help at all because the problem wasn't there. It was in configuration/setup that was assumed correct but actually wasn't. What FX2 hardware are you using? Jon
Yes, we can download code from the debugger and run it. The 9F00 area used by the monitor code is totally functional. We download large programs... and have been doing so for months. the hardware is good.
It's our own board. If I had a listing of the monitor library source then I could see what region the code is in when it reads address 1212h. There should not be any accesses to this area, and there is no data in the hex file in this region. If I could tell that the processor was trying to push something on the stack, for example, then I'd know that the stack pointer must be messed up. Perhaps you could compile the library with some higher level of debug turned on, so that the resulting map file includes lots more data about what routines are where in memory. After spending weeks on this I don't think that I'd be any worse off with the source. I've really exhausted all the usual problems. I followed everything in the app note, and the monitor is "sort of" recognized, and all the code does download - just doesn't run at the end. Does the EPROM area near address zero have to be writeable? My understanding is that all the jumps in the vector table are redirected to similar jumps (a duplicate table) at address 8000. If the code tries to change locations at that address then of course it won't work since it's not von neumann in that region.
A phone call would be most effective in figuring this out. Is that possible? We could review everything that I've done, step by step, and perhaps find something. I could arrange to be here at odd hours if that helps. (949) 851-6989 x105