Problem with STM32H743 backup ram access with 16 Bit

[roland23]

We use the STM32H743BI.

We have a problem with writing the Backup-RAM if the mapped variables size is not multiple of 32 Bit.

According to the reference manual (rev. 7) the backup RAM is accessible in 32-bit, 16-bit or 8-bit data mode. (RM0433 Rev 7, page 264, Backup RAM).

We have mapped a struct with several elements on the start address of the backup RAM (0x38800000). Each element has data size of 16Bit.

Struct:

struct tBackupRamDataStruct
{
            UINT16 ui16Test1;
            UINT16 ui16Test2;
            UINT16 ui16Test3;
            UINT16 ui16Test4;
};

Code:

int main(void)
{
        static volatile struct tBackupRamDataStruct 
        tBackupRamDataStruct __attribute__((at(0x38800000)));
           …       // Init controller and pheripherals
	while(1)
	{
            if (ui16UpdateData)
	    {
	       ui16UpdateData = 0;
	       tBackupRamDataStruct.ui16Test1 ++;
	       tBackupRamDataStruct.ui16Test2 ++;
	       tBackupRamDataStruct.ui16Test3 ++;
	       tBackupRamDataStruct.ui16Test4 ++;         
	    }
 
	   if (ui16ResetRequest)
	   {
	       ui16ResetRequest = 0;
               __NVIC_SystemReset();               // Execute System Reset
	   }
      }
}

If the data are written like in my code example and then a reset is executed everything is OK. But if I comment line „tBackupRamDataStruct.ui16Test3++;“ and execute a system reset the data of ui16Test1 and ui16Test2 are correct but the data of ui16Test4 is not correct. There is the same problem if I comment line „tBackupRamDataStruct.ui16Test3++;“.

If I change the data type of struct elements to 32 Bit everything works fine.

There is no difference between a software system reset and a power on reset.

[Uwe Bonnes]

Did you try to declare the uint16 units in the structure as volatile?

[berendi · Accepted solution]

Last paragraph of chapter 2.4 in the reference manual

When an incomplete word is written to an internal SRAM and a reset occurs, the last

incomplete word is not really written. This is due to the ECC behavior. To ensure that an

incomplete word is written to SRAM, write an additional dummy incomplete word to the

same RAM at a different address before issuing a reset.

[roland23]

Thank you for your answer berendi.

[Pavel A.]

> To ensure that an

incomplete word is written to SRAM, write an additional dummy incomplete word to the

same RAM at a different address before issuing a reset.

Additional incomplete word??

Does this mean, write it to any offset, like the following?

volatile uint16_t x[10];

x[1] = 42;

x[7] = 43;

Or the incomplete words must be halves of same 32-bit, like this:

x[1] = 42;

x[0] = 43;

And what if I do not keep track of how many half words or bytes I wrote there (like after several strcpy's ?)

Can the SRAM write-back be ensured by writing a complete 32-bit word after half word?

x[1] = 42; // unpaired

*((uint32_t*) &x[8]) = 0; // writing complete word

Thanks,

-- pa

[berendi]

"at a different address" means to me that any address except the one that was last written to. I would reserve a full word for dummy writes and write a byte into it whenever I feel like the write buffer should be flushed.

> And what if I do not keep track of how many half words or bytes I wrote there (like after several strcpy's ?)

Several strcpy's write to several different addresses, so the ones before the last should be properly written.

> Can the SRAM write-back be ensured by writing a complete 32-bit word after half word?

That is a good question.