STM32CubeProgrammer incorrectly displays BKPSRAM content

[waclawek.jan]

Below CubeProgrammer's window is gdb displaying the real content of BKPSRAM.

 

JW

[Mike_ST]

Thank you.

Ticket entered...

[waclawek.jan]

Hi @Mike_ST​ ,

Thanks.

Jan

[Mike_ST]

Hello Jan,

I got feedback...

It seems like in the GDB setup you are using the BKPSRAM has been activated previously,

When STM32CubeProgrammer is only reading memory without doing activation.

[waclawek.jan]

Hi Mike,

What do you mean by *activation* here, in terms of the Reference Manual?

And what should I do to "activate" the BKPSRAM so that it is readable by CubeProgrammer?

Thanks,

Jan

@Mike_ST​ 

[Mike_ST]

Hi Jan,

RCC.PWREN set to 1

RCC.BKPSRAMEN set to 1

PWR.BDP set to 1

[waclawek.jan]

Hi Mike,

Thanks.

So, how do I set those bits in CubeProgrammer, so that I can read out (and eventually reprogram) content of BKPSRAM?

Thanks,

Jan

@Mike_ST​ 

[Mike_ST]

Hello Jan,

Go to memory editor part (the same one you shown on the picture), enter the reg address and write desired reg value.

[waclawek.jan]

Hi Mike,

OK, this works. For read, it's enough to set RCC_AHB1ENR.BKPSRAMEN of course.

CubeProgrammer could do this automatically, though, when access to the BKPSRAM area is requested; I don't see any danger stemming from this.

It also could support write in the same manner, besides PWR_CR.DBP perhaps also setting PWR_CSR.BRE (but that should perhaps be optional).

Can this please be chalked up as a feature request to CubeProgrammer? After all, BKPSRAM is a nonvolatile memory, thus similar in usage to FLASH...

Thanks for your support,

Jan

@Mike_ST​ 

[Mike_ST]

Hi again,

"CubeProgrammer could do this automatically"

Actually I asked for that in the ticket. It has been rejected, because we want to display original memory/register state.

You can try automate the process by creating a batch script that call STM32CubeProgrammer with the w32 command to set the 3 registers.

STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=SWD mode=normal -w32 0x40023840 0x10000000 -w32 0x40023830 0x00140000 -w32 0x40007000 0x0000C100

Then you have to connect in "Hotplug" mode, not "Normal" or under "Reset".

[waclawek.jan]

Hi Mike,

> It has been rejected, because we don't want to display original memory/register state.

I don't understand what that means, but whatever, I assume this is to keep behaviour consistent which is a good thing.

> You can try automate the process

Thanks for the suggestion.

My original application was to quick-check self-measured calibration data during manufacturing, using the clicky interface; so any "intermediate" step would defeat this particular purpose. I've arranged for a different process meantime.

Thanks again for your involvement.

Jan

@Mike_ST​