Battery Backed SRAM

On the RCM5600W are all three of the SRAMs battery backedup?

  1. 32 Byte VBAT-RAM (Only one specifically called out in documentation as battery backed)
  2. 128KB Rabbit 5000 internal SRAM (?)
  3. 1MB External SRAM (has VBATIO input, but nothing specific in documentation)

I believe that only the 32byte VBAT_RAM is battery backed. Both the internal 128K RAM and the external 1MB RAM are high speed and lot low power enough to support battery backup.

Although looking at the RCM5600W in my box of parts, the device fitted is a CY62157EV30LL-45BVXI which claims to have a typical standby current of 2uA and max 8uA which should be fine.

The main issue here would be modifying the board options in the system libraries so that the external RAM is marked as BBRAM as only a 32KB chunk of it seems to be marked as such at the moment.

The RCM5600W/RCM6600W modules do not include a battery, but there is provision for customer-supplied battery backup. Battery backup keeps the Rabbit 5000/6000 real-time clock running while also preserving content of the RCM5600W/RCM6600W families’ battery-backable 32 KB SRAM as well as the RCM6650W module’s external SRAM. Note that for the RCM5600W family, Dynamic C supports battery backup for only a 32 KB portion of the external SRAM

Sorry if I seem obtuse, but I am missing something here. I have installed a battery on my RCM5600W Interface board and verified it maintains the RTC. I checked the schematic and the 1MB SRAM Vcc is supplied by VBATIO. In turn VBATIO is supplied by the 3.3V regulator or VBAT_EXT. So I would expect the battery to keep the SRAM data when the 3.3V is removed. But I ran an experiment using global variables and when I power cycle the board, the data is erased. Since the SRAM appears to be powered by the battery, I was surprised to see the data erased. I am not clear how Dynamic C would provide battery backup, that seems a hardware function.

The Dynamic C compiler and run time distinguish between normal memory and memory that is marked as BBRAM and make sure that any variables in BBRAM are not initialised or cleared to 0 on reset for BBRAM. This means that even if the memory has battery protection, if it is not indicated as being BBRAM in the memory_layout.lib file it will be initialised on reset.
There are some comments in the above lib file and the boardtypes.lib file about the RCM5600W memory layout. To me it looks like there are artificial limits set on the memory layout to keep it similar to the RCM6xxxx modules which have 32K of BBRAM on the Rabbit 6000 chip.

Have you looked at the sample Samples\RestartVars\BatteryRAM\bbvars.c

I forgot to add, you need to preface any variables you want to put in BBRAM with the bbram keyword.