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
http://www.keil.com/support/man/docs/uv3/uv3_cm_load.htm
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.
The load options in http://www.keil.com/support/man/docs/uv3/uv3_cm_load.htm do not address the problem. I need to know what's actually in flash memory, not what I think is in flash memory or what Uvision thinks is in flash memory.
I'm using SiLabs usb debugger for their 8051 chips. The otherwise terrible SiLabs IDE has no problem refreshing it's view of flash directly from flash (what a concept!).
I'm using SiLabs usb debugger for their 8051 chips. The otherwise terrible SiLabs IDE has no problem refreshing it's view of flash directly from flash
Than what is the problem, you just staed that it woeks.
Is it that you are incapable of working outside the Keil IDE?
I have used the SiLab ide for issues like this. It takes considerable time to make sure the everything is set up properly in the SiLab ide to match the settings of Uvision in order to create the exact image. This can take hours.
I don't want to use some crappy IDE, when the best tool just needs to refresh it's view of flash. This is not a difficult concept.
"I need to know what's actually in flash memory, not what I think is in flash memory or what Uvision thinks is in flash memory."
What does a flash have in it at the time of manufacture?
Is that known to The AlMighty CReator,
imean the manufacturer..
wonder what this talk is for... once it is been "accepted" to interface for a particular purpose, the flash will be connected to the same, to load the intended program, is it not so,
< b>Flash also needs to know what is in 8051.
"It takes considerable time to make sure the everything is set up properly in the SiLab ide to match the settings of Uvision in order to create the exact image"
As a workaround, can you not just load the image built by uVision into the SiLabs IDE for this?
"I don't want to use some crappy IDE, when the best tool just needs to refresh it's (sic) view of flash."
Have you contacted Keil support about this?
Do you simply need to know what's there, as Christoph Franck is saying, or do you also want to continue symbolic debugging of the newly-loaded image?
For the former, doesn't the memory display window read directly from the target?
For the latter, how does the SiLabs IDE know where to get its symbol information to match the new image?
What interface are you using between uVision and your target?
Whats meant by symbolic debugging of the newly-loaded image,