Im trying to get my 87C51 to read and write data to a peripheral (D71055). I'm using uVision3 and everything works fine with the debugger- I can see the data at the memory locations (0xF801) changing correctly as well as the other program functions. When I actually program the 87C51 chip and test it everything else works OK, but theres nothing on the D71055) I'm using volatile unsigned char xdata D71055_port_a_at_0xF800 volatile unsigned char xdata D71055_port_b_at_0xF801
ps. I've had success (data at 0xF801 reflects whats at 0xF800 correctly) with using a monitor program (paulmon) but I dont want to have that in my chip.
Yes it was a mis-post sorry, the source code has a space either side of the _at_ as shown here. volatile unsigned char xdata D71055_port_a _at_ 0xF800 volatile unsigned char xdata D71055_port_b _at_ 0xF801
It seems to work just fine if I use the monitor program to download the code (with cseg modified to new start location in startup code and vector adress changed accordingly) into external RAM or Flash ROM and then jump to the code using the monitor program.
you are referring to a general 87c51 (no prefix, no trailing letters), thus I do not know if this is true for your device, but many derivatives require a SFR bit set to access external mwemory.
Erik
"I use the monitor program to download the code ... into external RAM"
The 8051 has no instruction to write to its CODE space - therefore you must have some cunning hardware that maps this RAM to XDATA for the download, then back to CODE for execution.
It looks like your monitor handles this correctly (you say it works), but your application doesn't
The problem wasn't xdata in the end, it was simply the hardware not having time to come out of reset (87C51 was correctly writing data to the IO chips but they weren't responding). I inserted a software delay before my main program configured the IO chip and it worked. This is why the monitor program worked (time taken to jump to the code start was ample to allow IO chips to reset) Thanks for the help guys
Thanks for feeding-back the conclusion!
Yes, timing is a classic cause of differences between "debug" and "real" versions...!