Marlin: [BUG] I2C EEPROM on SKR PRO V1.1 broken

[Hans007a]

Bug Description

After the last bugfix update (last commit: #17788) my I2C is stopped to work. I change the 24CL256 chip, but the bug exists. No EEPROM can't be initialised and writen or read.

My Configurations

BTT SKR PRO V1.1 with EEPROM on I2C port

Steps to Reproduce

1. try to initialize EEPROM, short beep is comming and Marlin blocks for a while
2. write Z-Offset
3. read Z-Offset
4. Marlin stops allways for a while, no error messages, but no value

Expected behavior: [What you expect to happen]
I2C EEPROM works, I can save config

Actual behavior: [What actually happens]
I2C EEPROM is not working, config is not saved

Additional Information

My last working update was bugfix from the end of February
Marlin_Configs.zip

[viper93458]

Same here using external i2c eeprom module.

Likely related to this: https://github.com/MarlinFirmware/Marlin/pull/17772

-William

[GMagician]

Maybe related to #17813? Cause is missing eeprom_init() call

[viper93458]

I don't know but even with the PR from 17813, there is an issue with SKR Pro 1.1:

Send: M502
Recv: echo:Hardcoded Default Settings Loaded
Recv: ok
[...]
Send: M500
Recv: echo:Error writing to EEPROM!
...
Recv: echo:Settings Stored (4 bytes; crc 7439)
Recv: Error:EEPROM datasize error.
Recv: ok

I use the following from an instructable to enable the external EEPROM:

//Added external EEPROM
#define I2C_EEPROM
#undef E2END
#define E2END 0x7FFF // EEPROM end address AT24C256 (32kB)
// Added external EEPROM

-William

[thinkyhead]

Our helpful guests are incorrect.

For a while now the SKR Pro 1.1 has been using FLASH_EEPROM_EMULATION as the default for its EEPROM. It used to fall back to "none" which would at that time would end up using the i2c-based EEPROM. At the time of Marlin 2.0.1 the E2END value was only 4K, not 32K.

If there's a more robust built-in i2c EEPROM then that would be the preferable default.

With the current bugfix-2.0.x code you should be able to put these lines into your Configuration.h file for the same result:

#define I2C_EEPROM
#define E2END 0x7FFF

Once I have a more definitive answer about the built-in EEPROM then I will make the appropriate change to pins_BTT_SKR_PRO_V1_1.h so that it uses i2c-based EEPROM by default.

[viper93458]

I am attempting this updated config now per your recommendation:

//Added external EEPROM
#define I2C_EEPROM
//#ifdef E2END
//   #undef E2END
//#endif
#define E2END 0x7FFF // EEPROM end address AT24C256 (32kB)
//Added external EEPROM

I don't know the actual ramifications, I was just following an instructable that someone else made to connect a simple $5 eeprom to my SKR to avoid emulation. :)

-William

[randellhodges]

The STM32 platform calculates E2END based on the FLASH_PAGE_SIZE, at elast for the STM32F4 (SKR PRO 1.1)

When I had my SKR 1.1 PRO board and an I2C eeprom about a month ago, I just included
-DFLASH_PAGE_SIZE=0x8000 as a build flag inside my platformio.ini to use the entire (not that I needed to) eeprom. It had to be there or the variant.h otherwise I'd get warnings about redefines in the platform and inside Marlin

Note: E2END was FLASH_PAGE_SIZE - 1

Note 2: This was before the latest refactor of i2c/spi/wired eeprom changes.

[viper93458]

My adjustment in the config above per the recommendation wasn't successful as I have downloaded the current version of bug fix 2.0.x and it no longer compiles due to issue https://github.com/MarlinFirmware/Marlin/issues/17823

:(

I also played with the DFLASH_PAGE_SIZE option in platformio.ini which made no difference in the error/issue.

-William

[jgwinner]

As an alternative workaround, I have an SKR Pro board too, and with @LinoBarreca 's great work, got the MultiSPI branch going. The EEPROM emulation on the SD cards works great, now in the 2.0.5.3 main branch. I'm saving settings as I did with the MultiSPI branch.

In any event, do you have a link to the instructable? While trying to get anything to work, I did order some EEPROM chips.

[viper93458]

@jgwinner https://www.instructables.com/id/BigTreeTech-SKR-Pro-V11-Adding-a-EEPROM/?fbclid=IwAR2uKRGzvIFZJv8fiw6MxmGGHm8PG-gGMObgHNx5tX_Bklcl2R1uMyO01qQ

[thinkyhead]

I just included -DFLASH_PAGE_SIZE=0x8000 as a build flag inside my platformio.ini to use the entire (not that I needed to) eeprom.

More notes…

FLASH_PAGE_SIZE can also be defined by a variant.h file, as is done for the FYSETC_S6.

Marlin uses E2END for the platform eeprom, or EEPROM_SIZE for flash-based emulation.

[viper93458]

I am sure the previous comment wasn’t directed at me as I am not a developer, but I can say that it still fails to work on the current bug fix from tonight. Unfortunately I lack the understanding needed to troubleshoot or offer a solution so I am just waiting and watching to see if anything comes up. :)

Thanks for all your hard work team!

-William

[jgwinner]

Hi Viper. Maybe you could switch to the SD Card EEPROM emulation? That works pretty well for me. It's a lifesaver! I used to compile the z offset and then walk the card over and reboot ... evertime I'd adjust the plate, I'd have to recompile ...

[viper93458]

I could but I would rather not put unneeded stress on the SD card. I bought an actual EEPROM specifically for this that I would like to use if possible. If it isn’t meant to be then I will switch. :)

[MoellerDi]

My SKR PRO V1.1 works fine with an external I2C EEPROM. I made a hack in the pin file

in pins_BTT_SKR_PRO_V1_1.h after:

// Use one of these or SDCard-based Emulation will be used
#if NO_EEPROM_SELECTED
  //#define SRAM_EEPROM_EMULATION                 // Use BackSRAM-based EEPROM emulation
  //#define FLASH_EEPROM_EMULATION                // Use Flash-based EEPROM emulation
#endif

add the following:

#define I2C_EEPROM                                // Use external EEPROM Module (e.g. AT24C256) connected to I2C Pins as outlined at https://www.instructables.com/id/BigTreeTech-SKR-Pro-V11-Adding-a-EEPROM/
#ifdef I2C_EEPROM
  #define USE_SHARED_EEPROM 1                     // Use Platform-independent Arduino functions for I2C EEPROM
  #undef E2END                                    // Defined in Arduino Core STM32 to be used with EEPROM emulation. However a real EEPROM to be used
  #define E2END 0x7FFF                            // EEPROM end address AT24C256 (32kB)
#endif

edit: #define USE_SHARED_EEPROM 1 is not needed, see below

[randellhodges]

I just included -DFLASH_PAGE_SIZE=0x8000 as a build flag inside my platformio.ini to use the entire (not that I needed to) eeprom.

More notes…

FLASH_PAGE_SIZE can also be defined by a variant.h file, as is done for the FYSETC_S6.

Marlin uses E2END for the platform eeprom, or EEPROM_SIZE for flash-based emulation.

The reason I pointed that was because the platform (at least for the STM32F4 chip) defines E2END based on the FLASH_SIZE

from \.platformio\packages\[email protected]\cores\arduino\stm32\stm32_eeprom.h

#ifndef FLASH_PAGE_SIZE
/*
 * FLASH_PAGE_SIZE is not defined for STM32F2xx, STM32F4xx and STM32F7xx
 * Could be redefined in variant.h or using build_opt.h
 * Warning: This is not the sector size, only the size used for EEPROM
 * emulation. Anyway, all the sector size will be erased.
 * So pay attention to not use this sector for other stuff.
 */
#define FLASH_PAGE_SIZE     ((uint32_t)(16*1024)) /* 16kB page */
#endif
#define E2END (FLASH_PAGE_SIZE - 1)

That is why I defined FLASH_PAGE_SIZE as 0x8000 in the platformio (or the variant.h as you pointed out, which works too, I just tried to avoid touching that file).

Now, interestingly, the latest changes,

\Marlin\Marlin\src\HAL\STM32\inc\Conditionals_post.h defaults to #define USE_SHARED_EEPROM 1 if we are using I2C_EEPROM but it the eeprom_wired.cpp for that HAL uses E2END which is defined by the platform.

Not sure if that just means we don't need to USE_SHARED_EEPROM for STM32, or if something else should be (if anything) done to avoid mixing in this case.

I will try it on my SKR PRO 1.1 with and without USE_SHARED_EEPROM.

[randellhodges]

A follow up on my previous post. Testing as of commit 9a6934874a920afb91f0473add66f102c18f4798

-DFLASH_PAGE_SIZE=0x8000 inside my platformio
#define I2C_EEPROM

I see it sets #define USE_SHARED_EEPROM 1 in the conditions_post.h, so it is going to use the wired/shared code and not the platform code.

It seems to work. (I had to fix my jumpers on my robodyn eeprom to set the 0x50 address properly as required)

SENDING:M502
echo:Hardcoded Default Settings Loaded
ok P63 B31
>>>m500
SENDING:M500
echo:Settings Stored (668 bytes; crc 3229)
//action:notification Settings Stored
ok P63 B31

One thing I notice is that the platform has these signtures

uint8_t eeprom_read_byte(const uint32_t pos);
void eeprom_write_byte(uint32_t pos, uint8_t value);

And the shared wired version has these:

uint8_t eeprom_read_byte(uint8_t *pos);
void eeprom_write_byte(uint8_t *pos, unsigned char value);

So just toggling the define of USE_SHARED_EEPROM to try framework vs shared eeprom isn't possible.

[randellhodges]

Once I have a more definitive answer about the built-in EEPROM then I will make the appropriate change to pins_BTT_SKR_PRO_V1_1.h so that it uses i2c-based EEPROM by default.

I have the SKR PRO 1.1 and I do not believe it has a built in EEPROM. From what I gather the GTR board is the one that has the built in EEPROM.

I have the GTR board, I just haven't taken it out of the box yet. The SKR PRO 1.1 has kinda turned me off STM32 boards for a while.

Interestingly, they have a copy in the GTR that spells out EEPROM demo. I haven't looked at it yet to see what is changed to allow the onboard EEPROM for that board.

https://github.com/bigtreetech/BIGTREETECH-GTR-V1.0/tree/master/firmware/Marlin-2.0.x_BTT_GTR_V1.0_12864p-16div-eeprom_Demo

[MoellerDi]

you are right,

I didn't notice that \Marlin\Marlin\src\HAL\STM32\inc\Conditionals_post.h defaults to #define USE_SHARED_EEPROM 1 if I2C_EEPROM is enabled.

so adding the following to pins_BTT_SKR_PRO_V1_1.h works just fine for me:

#define I2C_EEPROM // Use external EEPROM Module (e.g. AT24C256) connected to I2C Pins as outlined at https://www.instructables.com/id/BigTreeTech-SKR-Pro-V11-Adding-a-EEPROM/
#ifdef I2C_EEPROM
  #undef E2END // Defined in Arduino Core STM32 to be used with EEPROM emulation. However a real EEPROM to be used
  #define E2END 0x7FFF // EEPROM end address AT24C256 (32kB)
#endif

[viper93458]

Just tested with my SKR Pro 1.1 and external EEPROM and it worked with the following in configuration.h as mentioned above.

#define I2C_EEPROM // Use external EEPROM Module (e.g. AT24C256)
#ifdef I2C_EEPROM
  #define USE_SHARED_EEPROM 1 // Use Platform-independent Arduino functions for I2C EEPROM
  #undef E2END // Defined in Arduino Core STM32 to be used with EEPROM emulation. However a real EEPROM to be used
  #define E2END 0x7FFF // EEPROM end address AT24C256 (32kB)
#endif

Send: M502
Recv: echo:Hardcoded Default Settings Loaded
Recv: ok
[...]
Send: M500
Recv: echo:Settings Stored (651 bytes; crc 19227)
Recv: //action:notification Settings Stored
Recv: ok

I don't know if I need the platformio.ini change or not (-DFLASH_PAGE_SIZE=0x8000)?

Thanks!

-William

[randellhodges]

If you do #undef E2END and then #define E2END 0x7FFF then no, you do not need to use -DFLASH_PAGE_SIZE=0x8000.

You can do either:

In your pins file, or one of the configuration files:

#define I2C_EEPROM // Use external EEPROM Module (e.g. AT24C256) connected to I2C Pins as outlined at https://www.instructables.com/id/BigTreeTech-SKR-Pro-V11-Adding-a-EEPROM/

#undef E2END // Defined in Arduino Core STM32 to be used with EEPROM emulation. However a real EEPROM to be used
#define E2END 0x7FFF // EEPROM end address AT24C256 (32kB)

or

In your pins file, or one of the configuration files
#define I2C_EEPROM
then in your platformio.ini add
-DFLASH_PAGE_SIZE=0x8000

I didn't try @MoellerDi's way of undefining and redefining E2END. I'm not sure if that'll generate warnings (that you can probably ignore now). When I first used the EEPROM code on my SKR PRO 1.1 it was back before this EEPROM refactor. The code was using the frameworks method for accessing I2C EEPROM and not the shared 2wire code it is now using.

I was specifically looking to avoid warnings and redefines.

[viper93458]

Thanks for the update! It's working at the moment, so I don't know if its the best way, but I am happy it works. I will watch this thread for the most efficient/recommended/best practice way. :)

-William

[viper93458]

Well as of tonight's latest download of bugfix2.0, the skr 1.1 pro keep rebooting over and over and using yesterday's bugfix2.0 the eeprom error returned. :(

-William

[randellhodges]

The file eeprom_wired.cpp which is what is used for the I2C eeprom hasn't changed for 6 days...

[viper93458]

Not sure what to say about that. :)

I can't test today's bugfix version as it boot loops.

I know the ststm32 library changed on my machine in the last couple of days to v6.1 through vscode. May be related. May not. Not being a developer, all I can do is report. Sadly my troubleshooting is limited. Thanks for listening though! :)

-William

[randellhodges]

That could definitely be the cause. I don't know enough about how platformio works. Might see if there is a way to roll that version back to < 6.1 and see if it starts working again.

[sjasonsmith]

@viper93458 could you attach your configuration files that are causing the boot loop? Please include your platformio.ini and your pins file (if you have modified it).

I've seen bootloops as well, but I thought the platformio.ini was already preventing upgrading the component that causes it. I'd like to see what you are running with to compare with what I have on my board.

[viper93458]

@sjasonsmith Sure thing! No mods other than config, config_adv and patformio.ini

Attached here.

-William
Configs.zip

[sjasonsmith]

Thanks @viper93458, I'll look at it tonight, I'm just heading to work here now. I already have a PR posted to normalize some STM32 environments (#17904) so maybe this will provide additional insight into changes that are needed.

[viper93458]

Thanks! Have a great day! If you are in California, it's going to be hot today. :)

-William

[thinkyhead]

I think we solved the basic issue. But do we need to facilitate redefining. overriding, or substituting E2END for the case where an external i2c EEPROM is not like the one the Arduino framework expects?

[sjasonsmith]

@Hans007a, have you tried your I2C EEPROM with the current bugfix-2.0.x? I believe other people are using them successfully, and I have used one here on my bench.

[boelle]

@Hans007a still an issue?

[sjasonsmith]

I'm closing this issue, as there has been no response to my query 23 days ago, and several users (including myself) have successfully used an I2C EEPROM with an SKR Pro since the most recent comments.

[github-actions[bot]]

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.