If you also want to update a few parameters in program space and also have to store a significant amount of data in nonvolatile XRAM things begin to look different. Assume you want to change the a few bytes of the lower 16 KB of program space contents rarely, say, once every three months, but have to write and subsequently read the content the remainder of a 512KB space every 10 seconds. There are probably many ways to skin this cat, but the way in which I did it was to transfer the data into the FRAM using DMA during the window between the falling edge of ALE and the rising edge of (nRD AND nWR). That seems to have worked OK, but I also tried it by momentarily stopping the MCU oscillator during the required window for DMA writes into the nonvolatile memory space. Since FRAM didn't demand any more time than BBRAM, this seemed much more secure. Thank goodness I didn't require timers or the serial port during this phase of the operation. Data was transferred in bulk from the FRAM using a large macro that performed 256 byte transfers using auto-incremented DPTR, yet didn't transfer any data through the MCU. That way words could be transferred using the addresses generated in that macro, yet the DMA transfer could stop the process whenever necessary. I even got it to work using an interrupt during that macro, since the instructions in the macro were short and entirely interruptable. Other phases of the process did rely on the timers, hence, couln't be handled in that way.

It works out just fine.

I did develop the code using that old-fashioned monitor, ULTRAMON51, BTW, having hooked the FRAM up in exactly the way the author suggested, though his recommendation was for BBRAM. I just found the differing voltage thresholds for the shutdown of writes to be too different from the internal brownout RESET in the MCU to be a stumbling block, so I decided on the FRAM. I had already done it with a BBRAM of the same (256k x 16) as the FRAM, which enabled the transfer words directly from the FRAM to the 16-bit destination port. The non-volatility of the FRAM enables the system to recover from an upset during a data transfer, since it keeps transfer block count and data in non-volatile memory. It's probably a bit overengineered, but it hasn't fallen down yet. It is, after all, a low-volume device.

This would also work well for BASIC52, since it keeps the interpreter in program space, yet, IIRC, executes tokenized BASIC from XRAM. I can think of a few other situations wherein this would also serve well, allowing the code space to remain static, while the data space is modified repeatedly. In my app, the page write delay would have killed the whole process because I had to transfer 20 KB lickety split and subsequently load up 320KB (yes, bytes) of data before I was able to transfer it on.

RE