I have a production application that requires persistent storage. I have been using the bbram keyword, but my needs have changed and I wish to use xmem instead.
Presently, I have about a 16K struct that I am saving in persistent storage. I am putting in a “fencepost” (0xcaa93004 as the first and last 32-bit long’s) so I can tell if the area is “sane” or has been clobbered.
I used TN248 as a starting point. So here is the problem. For my production software, the memory gets clobbered whenever I power-cycle the Rabbit. If I use bbram keyword, it works fine, but if I use xmem if does not.
So I wrote a test program, reading and writing the exact same struct.
I use xalloc (type = XALLOC_BB), xmem2root and root2xmem for allocating, reading and writing the data respectively.
The test program works PERFECTLY even after a power cycle. The production software does not.
Furthermore, when I check the pointer value returned from xalloc, the test program reports 0xc8b0, but the production software reports 0x59012.
However, these addresses ARE CONSISTENT through multiple power-cycles of the Rabbit board, so I’m thinking - who cares, as long as the address is consistent through multiple reboots.
I’m trying to make XMEM work reliably first. I have to then perform some refactoring as the area in persistent storage need to grow to about 32k, after which I can no longer shadow the entire block to processor RAM. I have to use the far_memcpy to move sections of it at a time for my production application.
Questions:
- Why is the memory getting over-written in one case and not in the other?
- Instead of using xalloc to reserve the xmem and then shadow it to root memory? Is there a better way to just have this data fixed in xmem?
I can attach the test program but since it works, I’m not sure there is much point in that.
Thanks in advance