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.
Hello,
I'm debugging a firmware update problem and notice that uVison2 and 3 do not refresh the dissasembly or code memory views.
In other words, my app writes the new code into flash, but Uvision still thinks the old code is there.
Is there a way to get the latest version of uVision to refresh it's view of flash?
Thanks,
Mark
if I understand this correctly, you are saying that you tell the debugger to load A. Then A loads B.
If that is the case, how is the debugger to 'know' that you have another code in memory?
Erik
If that is the case, how is the debugger to 'know' that you have another code in memory?<p>
Well, if the debugger has access to a real emulator (ICE would be nice, but JTAG might do, to), it could simply read out the ROM every time.
If the debugger only has access to a toy emulator (anything that's connected to the PC via RS232 and runs at 56k qualifies), of course, it cannot do this for performance reasons.
"Well, if the debugger has access to a real emulator (ICE would be nice, but JTAG might do, to), it could simply read out the ROM every time."
If it read the ROM, all it would have would be the binary executable - no symbol info! So you'd still need some way to tell it to stop using the Debug info for 'A' and switch to the debug info for 'B'...
If it read the ROM, all it would have would be the binary executable
Sometimes, that's all you need. Usually, it's better than nothing at all.
I ran into pretty much the same problem while writing a firmware upgrade function for the ADuC845 - the emulator doesn't even consider that ROM contents might change, so there's no way to check execution of an flash EEPROM write operation. I don't need symbol info - I only need to know if ROM address 0x1234 has the value 0xAB after I issue the appropriate write command.
"Sometimes, that's all you need. Usually, it's better than nothing at all."
I think it would get confusing, though, if the debugger was trying to use the symbols for image 'A' whilst looking at image 'B'...!! :-0
I think it would get confusing, though, if the debugger was trying to use the symbols for image 'A' whilst looking at image 'B'...!!
I would like the debugger to leave the decision on what I find confusing up to me. :)
Seriously - when debugging firmware upgrade functionality, I look at addresses, not symbols.
(ICE would be nice, but JTAG might do, to), Some JTAGs (all I know of) WILL do.
OOPS was not clear WILL, do as to reading memory contents not as to 'connecting' source and memory contents after "a loade it did not know of", . I can not even visualize any debugger that would be able to 'connect' code that has been loaded by other means than the debuggers load command to the memory contents.
Thats Right!
"I think it would get confusing, though, if the debugger was trying to use the symbols for image 'A' whilst looking at image 'B'...!! :-0"
Does Debugger do mistakes, i mean, be playful enough to off-spin ?