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.
First let me describe a little bit about our system:
It is not von-neuman, and the main code executes from OTP (One Time Programable) memory. there is also a small amount of XRAM, and code can also be executed from there too.
When executing from OTP, we are unable to use MOVX to read or write CODE. We can use MOVC read CODE.
When executing from XRAM, we are unable to use MOVX to read or write XDATA. We can use both MOVC and MOVX to read CODE.
Despite being OTP, we do have the ability to dynamically patch an small number of quads of OTP code at any address to whatever value we choose.
My belief is that all the elements that are needed to execute a MON51 stub from OTP are present. We can patch code to jump to the stub on a break point, and code can be read through the MOVC to keep adjacent instructions coherent in the patch?
My question is, does anyone have any experience or deep working knowledege of the MON51 that can point me to section that inserts the jumps that set and clear break points? Are there any thoughts about how to modify this with minimum impact on the stub?
Thanks in advance,
Chris.
The XRAM is mapped into the code space, but the restrictions are:
1) when executing from XRAM, MOVX *cannot* be used to read (or write) XRAM space.
2) When running from CODE (OTP) space, MOVX *cannot* be used to read CODE (OTP) space.
3) We can never write to CODE (OTP) space.
4) MOVC can never be used to read XRAM, even if code is executing from it.
As to if you could classify that as von-Neumann I'm not sure? They do share the same address space, but they're pretty selfish when it come to actually using it!
As long as the MON51 uses "CLR A, MOVC A,@A+dptr" to read the code space (which it looks like it does), I'm pretty confident that Reinhard's suggestion will work (Thank you! I managed to completely miss that hook first time round).
I will report back if it works or not, but the build and run cycle involves burning a new FPGA so it is not quick.
There is another thing that concerns me however. I remember reading somewhere about single stepping being implimented with an interrupt? our timing and latency is a little obscure, so code that relies on the timing of instructions or interrupts may not work. Can anyone point me to the article?
Thanks again for your responses: Its been a great help so far.
"The XRAM is mapped into the code space"
I think it could help if you tidied-up your teminology a bit:
The 8051 architecture has two external address spaces: 1. XDATA - this has read+write access, and is addressed by the MOVX instruction; 2. CODE - this has read-only access, instructions are fetched from here, and MOVC provides read-only access.
These terms are defined by the 8051 architecture, and are totally independent of your target hardware - the memory that's addressed by MOVX is always "XDATA" as far as the 8051 is concerned!
Therefore, it's best not to think of anything in your target hardware as "XRAM" - especially as you say it can be mapped into the 8051's CODE space!
I speak from experience here, having worked with the Triscend E5, which allowed any part of its external memory to be mapped (and re-mapped) into the 8051's CODE or XDATA spaces - or both!
to clarify then:
1) both OTP and RAM are available in the 'XDATA' and the 'CODE' space.
2) Instructions may be executed from OTP or RAM.
3) MOVC can always read OTP memory (only).
4) MOVX will read OTP memory when executed from RAM.
5) MOVX will read and write RAM when executed from OTP.
Hope that helps. best not mention the ROM or I'll properly confuse you ;)
"best not mention the ROM or I'll properly confuse you"
No worries there: the Triscend had on-chip "external" RAM, on-chip ROM, off-chip RAM, and off-chip Flash - all of which were variously mapped between CODE and XDATA!! :-0
Chris,
did you actually try to configure MON51 already. BEFORE_GO, AFTER_GO and WR_CODE give you full control about the memory interface.
I'm in the process. The MON51 is compiled and in a hardware image, but we've broken our MOVX instruction on all memory buses at the moment. Its going to be after the weekend now before I find out if it worked I'm afraid...
Can I take the oportunity to ask if there are any licensing implications of including a MON51 binary in a ROM image? this might be another route open to us.
3) We can never write to CODE (OTP) space
if that is really the case and you can not switch your memory map to do a write into code space you will not have any chance to use mon51.
I remember reading somewhere about single stepping being implimented with an interrupt?
No, the serial interrupt is only usesd to be able to change from run mode to stop mode (Stop Button). So as long as you are in run mode code will be executed at full speed.
Here is my expiriance with mon51: regardless what you have configured in mon51 you need at least 256 bytes (one page) which is fully VNM. So there must be some space where MOVX and MOVC is reading the same address! If that is not the case mon51 will not work.
Thomas
"I remember reading somewhere about single stepping being implimented with an interrupt?"
It is quite possible that some debugging schemes use an interrupt but, aparrently, not MON51.
(the Triscend did have a breakopint interrupt, if I remember correctly...)