Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EEPROM library broken #1678

Closed
lincomatic opened this issue Mar 19, 2022 · 13 comments
Closed

EEPROM library broken #1678

lincomatic opened this issue Mar 19, 2022 · 13 comments

Comments

@lincomatic
Copy link

Hi, is the EEPROM library supposed to work? I tested it with a blue pill & STM32F102C8T6. When I try to write any EEPROM location and read it back, it fails.

Sample code:
EEPROM.write(0,0xbd); Serial.printf("%02x",EEPROM.read(0));
The read function just returns 0.
I also tried the functions directly from utility/stm32_eprom.c, and they don't work, either.

@ABOSTM
Copy link
Contributor

ABOSTM commented Mar 22, 2022

Hi @lincomatic,
Yes, EEPROM library is supposed to work.
And I checked on my bluepill and on my nucleo_f103rb, both are well working with your code
EEPROM.write(0,0xbd); Serial.printf("%02x",EEPROM.read(0));

Note, I am on main branch of the Core (sha1:e156c32db24d69cb4818208ccc28894e2f427cfa)

I am surprised when you say that you tested STM32F102C8T6, because there is currently no variant defined for STM32f102 !! which variant did you used ?
Can you also tell me which version of the core you are using ?

@lincomatic
Copy link
Author

Hi @ABOSTM,
Thank you for your reply. Sorry, it was a typo.. I am indeed using STM32F103C8T6. I'm using v2.2.0 of the core. I tried in both Arduino and platformio. Very strange how it's working on your end. I can't figure out what I'm doing wrong.

@ABOSTM
Copy link
Contributor

ABOSTM commented Mar 23, 2022

I checked on official v2.2.0 core version and it is still working on my bluepill.
Below is the exact sketch I used. Could you test it ?

#include <EEPROM.h>
byte value=0;

void setup() {
  Serial.begin(9600);
}
 
void loop() {
  EEPROM.write(0,value++); Serial.printf("%02x ",EEPROM.read(0));
  delay(100);
}

If it is still not working, could you try, for test purpose, to use variant : "BluePill F103C6 (32K)" in the Arduino IDE board menu selection ?
Point is that there are some fake bluepill marked as STM32f103c8t6 which are in fact STM32f103c6 (with 32k flash instead of 64k)
see https://embeddedtronicsblog.wordpress.com/2018/12/29/fake-stm32-blue-pill-boards/

@lincomatic
Copy link
Author

Thank you so much for your help!

It appears that I might have a fake MCU, but the behavior is strange.
I changed the variant to "BluePill F103C6 (32K)" as you suggested, and suddenly, the EEPROM emulation is working!
But ST-Link via STMCubeProgrammer identifies the MCU as Device ID: 0x410, and Revision ID: X, Flash size: 64KB.
Furthermore, I wrote a program that takes 45KB of flash, and it loads and runs correctly.
However, if I change the variant to "BluePill F103C8" the EEPROM emulation breaks.
Another strange thing is that EEPROM.length() returns 102400. Isn't the emulated EEPROM only 1024 bytes?

@ABOSTM
Copy link
Contributor

ABOSTM commented Mar 24, 2022

Device ID 0x410 is too generic, it identifies STM32F103/F102/F101
But with STM32CubeProgrammer, you can read address 0x1FFF F7E0 which correspond to Flash size register:
in my case 0x40 = 64 K
image

@ABOSTM
Copy link
Contributor

ABOSTM commented Apr 1, 2022

@lincomatic , any news ?

@fpistm fpistm added this to To do in STM32 core based on ST HAL via automation Apr 4, 2022
@fpistm fpistm closed this as completed Apr 4, 2022
STM32 core based on ST HAL automation moved this from To do to Done Apr 4, 2022
@lincomatic
Copy link
Author

@ABOSTM, sorry! I didn't see your last reply. My chip reports 64K, just like yours.
image
But as I said above, the EEPROM emulation works only if I pick the 32K Blue Pill. This is even though I can load programs that use >32K of flash. Very strange. But I think I must have a fake chip, because I'm not able to get into the UART bootloader at all.

@ABOSTM
Copy link
Contributor

ABOSTM commented Apr 5, 2022

On my side, EEPROM.length() returns 1024.
So this is abnormal that you have 102400.
Can you confirm this point ?

The EEPROM emulation uses the last flash page.
So for 32K Flash MCU, the page 31 is used; whereas for 64K Flash MCU, the page 63 is used. Which could explain the different behavior when you change the variant.

Also, another possibility is that your last flash page (63) is broken: Flash pages have limited lifecycle (limited number of write operations)

@lincomatic
Copy link
Author

Sorry again for taking so long to reply! I didn't receive the notification about your message.
Yes, I

On my side, EEPROM.length() returns 1024. So this is abnormal that you have 102400. Can you confirm this point ?

Hmm. Sorry, I must have done something wrong last time. I just tested again, and it returns 1024 with either "BluePill F103C6 (32K)" or "BluePill F103C8" selected.

The EEPROM emulation uses the last flash page. So for 32K Flash MCU, the page 31 is used; whereas for 64K Flash MCU, the page 63 is used. Which could explain the different behavior when you change the variant.

Also, another possibility is that your last flash page (63) is broken: Flash pages have limited lifecycle (limited number of write operations)

I don't think it's broken.. I have 2 different boads, and they both behave the same way. I think maybe my boards have a fake STM32F103C8T6, since I can't get into the USART bootloader in either one.

I wrote a sketch to write sequential bytes into the EEPROM locations:

void loop() { EEPROM.write(value,value); Serial.printf("%02x ",EEPROM.read(value)); if ((value % 256) == 0) Serial.printf("\nval: %d\n",value); value++; if (value > length*2) while(1); delay(1000);
Using STM32CubeProgrammer, I verified that the data were being written to the proper flash locations when I select "BluePill F103C6 (32K):

image

However, when I select "BluePill F103C8," the writing fails:

image

I verified that page 63 really exists, by writing some data into the first 2 bytes it using STM32CubeProgrammer:

image

As you can see from above, page 63 is working fine. There appears to be a problem w/ calculating the offsets properly when I select "BluePill F103C8" on my MCU

@ABOSTM
Copy link
Contributor

ABOSTM commented Apr 21, 2022

@lincomatic ,
Difficult for me to help you further, as everything is working on my boards.
There is no reason for offset calculation to be different between yours and mine.
You may enquire for help on the forum: https://www.stm32duino.com/

@lincomatic
Copy link
Author

OK, thanks for trying. Appreciate the time you spent on this.

@warp929
Copy link

warp929 commented May 31, 2022

I'm copying my answer from my post so others can find it here too.
#1731

The problem is with the "stm32_eeprom.c" file. It seems to incorrectly calculate the Flash End at 128K for a 64K chip which leads to an incorrect Flash Base.
See discussion:
#1500 (reference)

The solution was to replace
C:\Users????\AppData\Local\Arduino15\packages\STMicroelectronics\hardware\stm32\2.2.0\libraries\EEPROM\src\utility\stm32_eeprom.c
with this one:
fpistm@5c11191

@lincomatic
Copy link
Author

@warp929 Thank you!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

No branches or pull requests

4 participants