[BUG] Fysetc S6: M500 doesn't save (or restore is faulty)

[Drachenkaetzchen]

Bug Description

On the Fysetc S6, settings saved with M500 aren't restored after reset of power cycling the board.

Workaround

Comment out #define FLASH_EEPROM_EMULATION in pins_FYSETC_S6.h to save eeprom data to an SDCARD. Requires a supported SDCARD-Reader.

My Configurations

Configuration.h Configuration_adv.h

Steps to Reproduce

1. Change any setting supposed to be saved in the EEPROM (or emulation)
2. M500
3. Power cycle or reset the board

Expected behavior:

Settings saved with M500 are restored

Actual behavior:

Settings are initialized with the compiled in firmware defaults

[thisiskeithb]

It looks like the S6 has a lot of outstanding issues.

It would probably make sense to create a single issue to track all the bugs there instead of opening up several related tickets.

[Drachenkaetzchen]

It looks like the S6 has a lot of outstanding issues.

It would probably make sense to create a single issue to track all the bugs there instead of opening up several related tickets.

I usually don't like that since it keeps things separate as it helps me to put research info into the individual ones. How about a S6 overview ticket with references to the individual ones?

[Drachenkaetzchen]

you could even keep the overview one open and the others closed since the overview one will link to the closed ones, but just an idea

That sounds odd to me. For example, if a user wants to know if M500 works on the S6 and the issue is closed, they might think the issue is resolved.

I'm not sure what the benefits of merging issues for a board or having non-fixed issues closed are. I learned that M500 also doesn't seem to work on the SKR Pro, so this also affects more than one board as well.

[Drachenkaetzchen]

I'm actually working on these issues and yes, the issue list might be shorter, but I don't really get the idea why a short issue list is good. A short issue list doesn't fix issues. Bug reports do.

[boelle]

• [ ] #16056

is written like

dash space bracket space bracket space # and then without space issue number

[boelle]

found out something nice

if you make a list in the first issue then it will look like this on the issue list

so yes, create an overview issue and then list all the issues in the first post

[gitmiz]

This is similar to an open issue on the BTT SKR Mini E3. Except on the SKR E3, M500 saves to EEPROM (verifiable with M503) but configs are lost upon board cycle or M501.

[Drachenkaetzchen]

This upstream issue might relate to this: https://github.com/stm32duino/Arduino_Core_STM32/issues/297

[boelle]

a PR was merged upstream, but i guess this will not solve this one?

[Drachenkaetzchen]

I don't know, test it?

As long as the upstream issue is not closed, I don't expect it to be fixed.

Sorry but you're creating way more effort maintaining the issues than it would be necessary. I feel that you're after closing as much issues in Marlin as possible, but that actually hurts the project. My motivation contributing to Marlin steadily drops the more I feel it's not about resolving the issue but closing as many issues as possible.

[boelle]

well your motivation might climb again after i make this post

[randellhodges]

@Drachenkaetzchen Would you be willing or have a chance to try my PR with your Fysetc S6? I haven't had a chance to do in depth testing yet, but it so far it works.

https://github.com/MarlinFirmware/Marlin/pull/16174

[tna11]

Has anyone managed to get the flash eeprom emulation working? No joy for me. Thanks

[sjasonsmith]

Has anyone managed to get the flash eeprom emulation working? No joy for me. Thanks

This is a new board that nobody has spent the time with to get everything working completely. You may very well be the first person to try it on this board.

[randellhodges]

What did you try to get it working?

On Wed, Dec 18, 2019, 9:38 AM tna11 notifications@github.com wrote:

Has anyone managed to get the flash eeprom emulation working? No joy for me. Thanks

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/16060?email_source=notifications&email_token=AB26S2YST5WNEYZN34NGFJLQZI7YHA5CNFSM4JTIV2EKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHGQOXI#issuecomment-567084893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB26S25J72JUPZGJ4BU3Y5LQZI7YHANCNFSM4JTIV2EA .

[tna11]

Not sure if its just me, but if I enter M500 twice, it seems to save the data to the flash eeprom, when reset, the eeprom changes are restored.

The extruder pwm outputs werent working without the following changes in variant.h

// PWM resolution
//#define PWM_RESOLUTION          8
//#define PWM_FREQUENCY           20000 // >= 20 Khz => inaudible noise for fans
//#define PWM_MAX_DUTY_CYCLE      255

This was followed from the comments in the skr pro file

[iankds05]

As a automation and controls engineer for some 40 years I have never trusted Eeprom emulation in any form because there is always a risk of errors or corruption into flash memory of the MPU or the memory card. For the fractional cost of a AT24C256 2ECL IIC/I2C Serial Interface Port hardware EEPROM its a simple fix for any board that has not had a hardware Eeeprom pre configured, which still astounds me. I have used this after market method on the BTT SKR1.1 Pro without issue for some 6 months and have not had a single issue of loss of settings or failure to update. This solution has now been adopted for my Fysetc S6 and again it is behaving without issue. Installation is generally simple using a female header soldered to the Eeprom PCB and the Designers could offer this as a solution.

[jimi0303]

As a automation and controls engineer for some 40 years I have never trusted Eeprom emulation in any form because there is always a risk of errors or corruption into flash memory of the MPU or the memory card. For the fractional cost of a AT24C256 2ECL IIC/I2C Serial Interface Port hardware EEPROM its a simple fix for any board that has not had a hardware Eeeprom pre configured, which still astounds me. I have used this after market method on the BTT SKR1.1 Pro without issue for some 6 months and have not had a single issue of loss of settings or failure to update. This solution has now been adopted for my Fysetc S6 and again it is behaving without issue. Installation is generally simple using a female header soldered to the Eeprom PCB and the Designers could offer this as a solution.

Hello! Could you please give a detailed explanation where and what should be soldered exactaly? I ordered the component but can not figure out on my own what goes where, I'm not familiar with this kind of thing, but would really like a working printer. Thanks in advance!

[iankds05]

The connections for the eeprom chip I have is as shown in the attached photos. It depends on the type of eeprom module you have as to the connection detail but normally pins have designation on the module board and those 4 pins have to be married with the corresponding pins on the S6 controller board. header designated I2C. Those pins are individually designated on the underside of the board so its just a matter of ensuring your wiring corresponds pin for pin. A single line of code has to be added to Matlin Config.h file under the EEprom section. This will activate the read write process to the eeprom chip. This is the line of code: #define I2C EEPROM

[jimi0303]

Thank you very much for the detailed guide and pictures! I just ordered these 2 modules, hope to get one of them working properly. Best wishes!

[thinkyhead]

I'm not sure if BL24CXX-based i2c EEPROM is currently supported. I note that the Ender 3 v2 uses it and Creality is adding extra code to talk to it.

[jimi0303]

I'm not sure if BL24CXX-based i2c EEPROM is currently supported. I note that the Ender 3 v2 uses it and Creality is adding extra code to talk to it.

I think both that I ordered are AT24C256 2ECL, that's what they said in their names. If I'm wrong could you point me to an Aliexpress product?

[iankds05]

I have used both of those pictured above on 32 bit processors. Fystec S6 and also BTT SKR1.1 pro and they all function correctly. I have not used them on kit assembled printers like Ender 3 v2 or similar factory assembled printers so could not comment on their suitability. AliExpress links below https://www.aliexpress.com/item/32884598384.html?spm=a2g0s.9042311.0.0.27424c4d8DbeNH https://www.aliexpress.com/item/32889418944.html?spm=a2g0s.9042311.0.0.27424c4dPJQtnU

[chris-pollux]

So I just wanted to order a AT24C256 module, but checked my S6 again and saving EEPROM values works fine for me. I am on Marlin 2.0.5.3. I initially thought that double M500 seems to work, but apparently a single is also fine. Was there some upstream fix or something?

[jimi0303]

Hello!

You've all been very active in replying to my concerns so here goes one more.. I'd like to state that I have no experience in programming so bear with me please. Until my EEPROM module arrives (which now could take 90 days) I'd still like to use my printer with this board. I bought it used without an SD card, so obviously it did not work, the seller disappeared so it took me a good while to figure out the problem.

I managed to get it printing by saving the EEPROM to the SD card on a TFT35 v3.0 Here is the problem: obviously if I pull the SD card while the printer is on to upload a .gcode from my computer then put it back, the EEPROM doesn't work (can't explain why, guess it can't read it again or something..). So what I did until now was power cycle the printer so the settings are restored from the SD card. But now it does not seem to work reliably. I use auto bed leveling (I get that that data is stored in the EEPROM) and when I start a print I can see it is correcting the skew of the bed on the Z axis, but after some of the first lines the axis stops completely, the XY axes are still working and the print is going. So the print just goes on trying to mush layers in each other because the Z axis just stops completely, the stepper motor turns off, it doesn't raise Z even on layer changes, you can turn the axis by hand while the print is still going. Now I have to power cycle the printer 2-3 times to get it working. It seems like if I do anything in the printer menu before starting the print, then this will happen. Or not. I can't really explain it, it's pretty random.

So before you got an EEPROM module how did you get around to print with this board? Or what would you recommend I do? What could be the problem? It is really frustrating, yesterday it took me an hour to get a half hour print going.

Sorry for the long text, thanks in advance.

[lewiss66]

Hello, jimi0303. Did you manage to sort your problems? I just bought the board.

[jimi0303]

Hello, jimi0303. Did you manage to sort your problems? I just bought the board.

Hello @lewiss66 !

The I2C board is still on the way, I managed to use a workaround, but it isn't pretty. If I push anything other than starting the print, like move axis or something the auto-level and the Z axis altogether will fail. So what I'm used to doing now is that I heat up the printer, power it off for like 4 seconds, turn on then start print. This works every time, it is a passable solution until my chip arrives. (If I try to boot the printer without the SD card in it won't even do that.)

[sjasonsmith]

@jimi0303 have you updated your firmware recently? I think your issues were probably fixed recently in the bugfix branch.

In fact, this entire issue is probably fixed, although I don’t think @Drachenkaetzchen is around any more to be the one to verify that and close it.

[jimi0303]

@sjasonsmith Thanks for the input, honestly this whole firmware thing was more than a month ago and I'm not even sure what I should update anymore. I remember that I couldn't compile the provided firmwares so I whipped up a vanilla Marlin from scratch and made the settings so it would fit my Sapphire Pro and my preferences. Of course I dated everything, so I have those files. Could you shed some light on what needs to be updated so this issue is fixed? I guess not Marlin itself, so then what?

[sjasonsmith]

At this point, I believe flash EEPROM emulation should be working fine with this board. Some of the comments relate to I2C support, but that isn't what this issue was originally about, and should be tracked elsewhere if there are problems.

I'll close this issue out. If there are additional problems they should be opened as new issues.

[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.