[BUG] Flash EEPROM not Saving on STM32G0B1CB

[alextrical]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I have been trying to utilise the Flash EEPROM feature on a STM32G0B1CB MCU, it is possible to get the board to initilise, and this then persists across reboots.

For example setting the maximum temperature setting, and then saving via the menu results in the folowing response.

15:54:54.211 > echo:Settings Stored (465 bytes; crc 17790)
15:54:56.301 > echo:V87 stored settings retrieved (465 bytes; crc 64415)
15:55:07.156 > echo:Settings Stored (465 bytes; crc 17790)
15:55:28.547 > echo:V87 stored settings retrieved (465 bytes; crc 64415)

Another issue that may have be related, is that the FW compiled Flash range overlaps with the last 2 pages, used for the virtual EEPROM, though this can be sorted by adding the following to the ini

board_upload.maximum_size   = 126976 ;124k

Bug Timeline

Old issue, I believe I first came across it in November

Expected behavior

I would expect that once a change is made to a value in the menu, and saved, that the changes made would persist across reboots.

Actual behavior

User settings are lost upon a reboot, or selecting 'Load settings'

Steps to Reproduce

1. Compile and Flash firmware to a STM32G0B1CBT
2. Accept eeprom initilisation
3. Make a change in the menu, and then select 'Store Settings'
4. Reboot, or 'Load settings', and all changes are lost

Version of Marlin Firmware

Bugfix-2.1.x

Printer model

BTT_EBB42_V1_1_filament_extruder

Electronics

BTT EBB42, SSD1306

Add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configuration.zip

Enabled: DEBUG_EEPROM_READWRITE

Set "board_upload.maximum_size = 126976 ;124k" in stm32g0.ini to prevent page usage usage overlap between Firmware and Virtual EEPROM

[alextrical]

Issue located, and confirmed working on my board. It seems a fix that was submitted to STM32Duino hasn't made its way into the Platformio code.
https://www.stm32duino.com/viewtopic.php?p=10543

Platformio Variant Vs working STM32Duino variant file

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.