|
I'm writing an application that requires all of the ram to be verified. To do this I wrote some assembly to write 0x55 to every byte, read it, write 0xAA to every byte, read again. My problem is that when I run my program in the debugger it complains that there is no memory at address 0x220E and beyond. I'm pretty sure the ram is between 2000 and 3FFF as described in the data sheets and the PRM file in my project also agrees. it has the following in it: SECTIONS /* List of all sections specified on the "Build options" tab */ RAM = READ_WRITE 0x00002000 TO 0x00003FFF; ROM_C000 = READ_ONLY 0x0000C000 TO 0x0000FF7F; ROM_4000...... and so on Does anybody know why my debugger is complaining? |
|
|
memory map/debugger problem
Started by ●March 17, 2005
Reply by ●March 17, 20052005-03-17
|
In a message dated 3/17/05 9:17:46 P.M. Eastern Standard Time, writes: Does anybody know why my debugger is complaining? ============================= The debugger probably has his stack there and does a jsr to some subroutine and pushes a return address over your 55 and aa. Got to stay away from there |
Reply by ●March 17, 20052005-03-17
|
Ahrg! I found that the stupid program doesn't let you write to a memory address that is not defined as a variable. I found a check box that removes this constraint. Thanks --- In , BobGardner@a... wrote: > > In a message dated 3/17/05 9:17:46 P.M. Eastern Standard Time, > oog25@h... writes: > > Does anybody know why my debugger is complaining? > > > ============================= > The debugger probably has his stack there and does a jsr to some subroutine > and pushes a return address over your 55 and aa. Got to stay away from there |
Reply by ●March 21, 20052005-03-21
|
Ok, I've got my program working in the debugger, but I'm having problems when I run it on the chip. I'm guessing it has something to do with the monitor program on the chip.. it says that the monitor changes the address of RAM to end at 0x3FFF and go down (towards 0x0000). The stack pointer is also said to be at 3FC0. When i start writing directly to ram (using asembler) I can only get from 0x2000 to 0x2010, any further than that and the program will hang. The number of variables I have exceeds 10 bytes so I shouldn't be writing over anything but those first few. Anybody know whats going on here? --- In , "the_oog6789" <oog25@h...> wrote: > > Ahrg! I found that the stupid program doesn't let you write to a > memory address that is not defined as a variable. I found a check > box that removes this constraint. > > Thanks > > --- In , BobGardner@a... wrote: > > > > In a message dated 3/17/05 9:17:46 P.M. Eastern Standard Time, > > oog25@h... writes: > > > > Does anybody know why my debugger is complaining? > > > > > > > > > > ============================= > > The debugger probably has his stack there and does a jsr to some > subroutine > > and pushes a return address over your 55 and aa. Got to stay away > from there > > > > > > |
Reply by ●March 21, 20052005-03-21
|
Sorry, don't know enough about your working context to make a specific suggestion, but I had a CodeWarrior related issue where a program would work in the debugger but not on the chip. The issue was I edited the .PRM file to place my RAM in the 0x2000 to 0x3fff slot. The debugger ran this code fine, but to make it work on the actual chip I had to edit Start12.c to set the INITRM register to 0x20 to actually get the RAM hardware mapped to this 0x2000 section. Bottom line, the debugger doesn't care if INITRM is set correctly, but the chip most certainly won't run the code unless it can actually see the RAM, ie. INITRM matches the desired RAM map. And the Codewarrior compiler or linker doesn't seem to handle INITRM automatically for every type of target, although you can see some interesting "ifdef" references to INITRM in Start12's Startup() function. Remember INITRM has to be set before the stack pointer is actually used. Maybe you're running into some variation of this. Bill T. http://www.kupercontrols.com --- In , "the_oog6789" <oog25@h...> wrote: > > Ok, I've got my program working in the debugger, but I'm having > problems when I run it on the chip. I'm guessing it has something > to do with the monitor program on the chip.. it says that the > monitor changes the address of RAM to end at 0x3FFF and go down > (towards 0x0000). The stack pointer is also said to be at 3FC0. > > When i start writing directly to ram (using asembler) I can only get > from 0x2000 to 0x2010, any further than that and the program will > hang. The number of variables I have exceeds 10 bytes so I > shouldn't be writing over anything but those first few. > > Anybody know whats going on here? portions of this message have been removed] |
Reply by ●March 21, 20052005-03-21
|
Michael Barr wrote a great article a few years ago about RAM tests. A simple $55/$AA test like what you describe actually isn't very effective at finding typical memory failures. I highly recommend the article! http://www.embedded.com/2000/0007/0007feat1.htm (If you're writing the RAM test for manufacturing, the article will tell you how to make your test much more effective. We're getting great results with Mr. Barr's techniques here. If you're writing the RAM test for school, putting a bit of what you learn from this article into your writeup will dazzle your professor, which is always a good move! :-) On Mon, Mar 21, 2005 at 03:11:23AM +0000, the_oog6789 wrote: > When i start writing directly to ram (using asembler) I can only get > from 0x2000 to 0x2010, any further than that and the program will > hang. The number of variables I have exceeds 10 bytes so I > shouldn't be writing over anything but those first few. I'm not sure I follow the last sentence there. Do you *know* you're overwriting the program's variables? Since I'm not sure I follow you, here is some general advice: When writing RAM tests, I always find it surprisingly easy to accidentally "test" the RAM where my program lives. The result is a crash as the program destroys itself. See if you can get a map file from your compiler, and match it up with the memory map from the monitor program you're using. The union of the two is the areas you must avoid. If you have the COP enabled, make sure your program tickles it every now and then during the RAM test so the CPU isn't reset. Stephen -- Stephen Trier Technical Development Lab Cleveland FES Center |
