I am running a stress test to isolate an issue on our product where I am running through cyclical connect/disconnects on an HFP/SCO connection. In this process, we change BT PAGEMODE between 0 and 2 depending on the state.
I am running this about every 20 secs. After about 100 cycles, I start seeing this ":ERRORTORE FAILED" message. And the pagemode does not change. If I recycle power to the module, it works again for a while. Is there an iWrap imposed limit on this. I believe the pagemode becomes non-volatile (although I do not need it to be).
Any workarounds ?
This error occurs because of the way iWRAP stores new settings in flash, and eventually runs out of contiguous flash space available in the Persistent Storage area. Part of this is due to a limitation in the underlying CSR firmware in terms of how much flash space is available for this type of storage. When iWRAP runs out of space available to write a new PAGEMODE value to flash, it can no longer store new settings. The only option is to perform a PS defrag operation, something which happens automatically during the stack boot process. This is why it works again after you reset the module.
Since the flash write/defrag limitation is inherent in the chipset, it may also be possible for you to keep a simple counter internally each time you write to flash with a SET command, and if you get near the write limit which may result in a "STORE FAILED" error, preemptively run "RESET" or "DEFRAG" when you detect that the module is not busy with a connection. (Note that "DEFRAG" will trigger a reset itself as well.) You might also detect the error and automatically reset the Bluetooth module when it occurs, although the proactive method that defrags intentionally when there are no active connections to be disrupted is probably better.
There are no commands available which provide RAM-only page mode updates, so the above workaround is the only solution
Is the limit somewhere around 100 SET commands ?
For my current testing, I removed the Pagemode commands. But it does flag for me that in actual use if the unit is never powered off, after a few months of use, its possible that we could hit that limit. And I will need to remedy that as you suggest.
A cycle count of 100 is in the right general area. I believe the specific iteration limit depends on what other values are stored in flash, and how much space is available for the PS system to fill other slots with new values before there's nothing left. Given a fixed configuration on a module, the limit should be essentially static. If you've tested this to be some particular repeatable number like 90 or 100, then I would use that as the hard limit, and preemptively defrag or reset when you reach something a bit lower, like 70 or 80.