I'm trying to simulate a simple design (written in assembler), in uVision4, that has a few memory mapped peripherals and uses P2 for GPIO. In "options for target" I set "Off-chip Ddata memory" to: Start: 0x0000 Size: 0x0100 When I run the simulator, external memory access is being done using P2, which causes problems when the value of P2 changes for GPIO. While searching the forum posts I found some mention of P2 addressing being the default for PDATA access, but found nothing about how to disable this for the simulator. Perhaps a parameter passed to S8051? Any ideas or insight would be appreciated.
Do you think that the processor have any option to configure which processor port that should be used for addresses and/or data, when accessing external memory?
If you really want to use "any" port, then you can implement helper functions:
uint8_t read_byte(uint8_t addr); void write_byte(uint8_t addr,uint8_t val);
And have them use whatever port pins you want. But then you obviously need to take care of R/W and latching, besides just driving or reading address and/or data values.
Um, perhaps I have not been clear enough. This is a simulator configuration question. I'm trying to find out if there is a way to configure the S8051 module so that P2 is not used for external memory addressing, since in my design (and many others I suspect) only the address lines supplied by P0 give a more than sufficient address space, and GPIO pins are at a premium. Thanks, -Reed
This is a simulator configuration question. I'm trying to find out if there is a way to configure the S8051 module so that P2 is not used for external memory addressing, since in my design (and many others I suspect) only the address lines supplied by P0 give a more than sufficient address space, and GPIO pins are at a premium.
I know of no '51 processor that will toggle !R/!W without loading 'something' on P2. Thus it is not the simulator, but your 'design' that is faulty.
Erik
Really?
Aren't there some processors that only support an 8-bit external address?
Isn't that effectively just PDATA addressing?
There's nothing wrong with the design. It works quite well. All access to external memory is done with movx a,@R0 or movx @R0,a So the only values on P2 are the reset value or what was written on the last GPIO access. External memory on the Intel 8052AH is off chip. The designers of S8051 module made an assumption about how the external memory would be connected to the MCU. Their assumption doesn't match my configuration. I'm asking if there is anyway to change the configuration so that the value on P2 isn't used to address external memory in the simulator.
So you're talking about the simulator taking the value from P2 - is that it?
movx @R0,a So the only values on P2 are the reset value or what was written sorry, if the P2 stuff can handle rewrites, you are right
External memory on the Intel 8052AH is off chip where did you find that antique
Correct. It seems setting PPAGEENABLE equ 1 might do what I want but I'm not quite grocking the documentation. It seems there are a few things that have to be changed in sync to make this work...
Late '80's CNC equipment:)
Customer wants changes to existing hardware, no source code. Oh the things we do for money.
So after poking about I a bit I see that it is possible. Unfortunately I never figured out how to make the change other than by patching S8051.dll, version 3.84.0.1. In case any one else has the same problem or some Keil guru can find the correct way to trigger the desired behavior my notes follow.
During initialization of S8051.dll a structure is created that starts with four DWORDS:
3809288 4F452C0 -> "PPAGE" 380928C 4F64780 -> 0x00000409 3809290 0 3809294 FFFFFFFF
The value 0xFFFFFFFF in the above structure seems to correspond to the PPAGE value as documented by Keil, but I was never able to effect a change in this value by manipulating any of the PPAGE or PDATA values referenced in startup.a51 or the Pdata base field in the BL51 Locate options dialog. This may be a bug, but the documentation around this is too skechy to be sure. At any rate if you patch the above mentioned dll as follows:
find: 0x89 0x70 0x0C 0x8B 0x15 0x10 (should only be one instance) replace: 0xEB 0x01 0x90 0x8B 0x15 0x10
External memory will be accessed using a fixed value of zero instead of the current value of P2.
This may be a bug that does not make sense. a Simulation SHOULD access external memory with P2 & pO or it would not be a simulation.
in other words, you want the simulator to do what YOU want, not simulate what the CHIP does.
From the MCU, MOVX opcode documentation:
...
In the first type, the contents of R0 or R1 in the current register bank provide an eight-bit address multiplexed with data on P0. Eight bits are sufficient for external I/O expansion decoding or for a relatively small RAM array. For somewhat larger arrays, port pins can be used to output higher-order address bits. These pins would be controlled by an output instruction preceding the MOVX.
I can assure you that P2 doesn't express the upper 8 bits of the address during MOVX A, @Ri or MOVX @Ri, A for these processors.
The best documentation for the PPAGE parameter is here:
http://www.keil.com/support/docs/2394.htm
And from examining S8051.DLL it seems that this behaviour is implemented. What is not clear is how to actually set this parameter and verify it has been set to the intended value. Without looking at the source code for S8051.DLL or internal Keil documentation, I doubt there is much more that you can add to this conversation that will be useful.
you are right, the P2 bits are part of the address, but if you ignore them with a 256 bit address P2 is unaffected.
I have just never operated with that small an external RAM and thus never thought of it in that way.
so P2 IS part of the address, but not affected, so you cn ignore it if you so desire.
Even old dogs can learn new tricks