STM32F103 RTC BKP Registers 16bit not 32bit

[RedEchidnaUK]

I'm fairly new to MCU development, so I could be missing something, so please tell me if I am.

The RTC BKP registers on the STM32F103 are 16bit, but the HAL driver (system/Drivers/STM32F1xx_HAL_Driver/Inc/stm32f1xx_ll_rtc.h) requests and accepts an unsigned 32bit value. Of course it can't actually save 32bits only 16bits, so you lose the top 16bits of the data you sent.

To Reproduce

#include <Arduino.h>
static const uint32_t testValue = 0x544F4F42UL;

void setup()
{
  Serial.begin(115200);
  while (!Serial)
    ;
}

void loop()
{
  resetBackupDomain();
  enableBackupDomain();
  setBackupRegister(1, testValue);
  disableBackupDomain();
  Serial.println(getBackupRegister(1), HEX)); 
  delay(10000);
}

Running this code will print out the lower 16bits 4F42 as the top 16bits are missing.

Expected behavior
While this is technically expected, as the registers are 16bits, in my opinion the function should only request 16 and not 32bits to avoid confusion.

Additional context
Arduino Core for STM32 2.7.1
STM32F103 series

[fpistm]

Hi @RedEchidnaUK
Right for this mcu but not for other which are 32 bits registers.
So choice was made to have the same API. Simply use mask, shift and 2 backup registers.

[RedEchidnaUK]

Thanks for the explanation. I guess that makes some sense.

Although, personally I feel the HAL for the f1 series would make more sense if it were 16bit if all the MCUs in the series are the same. Or at least perhaps a note in the description for the called function to state it is only 16bits for this series and 32bits should be split across registers. This caused me some confusion until I looked up the details in the reference manual.

[fpistm]

It's always required to read the RM for this kind of API. They are not standard Arduino API and are provided to ease usage across all series.
Just looking and it seems all the part number have a 16 bits registers.
I agree the LL API can bring some mistake, anyway the range value is given
* @param Data Value between Min_Data=0x00 and Max_Data=0xFFFFFFFF

Moreover, event if only 16 bits are valid it still a 32 bits registers with High part reserved.

As we only used the HAL/LL API from the Cube without any modification, you could report this issue to the dedicated repo:
https://github.com/STMicroelectronics/stm32f1xx_hal_driver

[RedEchidnaUK]

I agree, reading the RM is probably a good idea, but where’s the fun in that? :)

Thanks for the link to the other repo. I hadn’t realised you had just taken it straight from there. I’ll look at raising the issue over there.