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

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

Closed
Drachenkaetzchen opened this issue Nov 30, 2019 · 31 comments
Closed

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

Drachenkaetzchen opened this issue Nov 30, 2019 · 31 comments
Labels

Comments

@Drachenkaetzchen
Copy link
Contributor

Drachenkaetzchen commented Nov 30, 2019

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

boelle commented Dec 1, 2019

is written like

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

@boelle
Copy link
Contributor

boelle commented Dec 1, 2019

found out something nice

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

image

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

@gitmiz
Copy link

gitmiz commented Dec 1, 2019

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
Copy link
Contributor Author

This upstream issue might relate to this: stm32duino/Arduino_Core_STM32#297

@boelle
Copy link
Contributor

boelle commented Dec 13, 2019

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

@Drachenkaetzchen
Copy link
Contributor Author

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
Copy link
Contributor

boelle commented Dec 13, 2019

well your motivation might climb again after i make this post

@randellhodges
Copy link
Contributor

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

#16174

@tna11
Copy link

tna11 commented Dec 18, 2019

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

@sjasonsmith
Copy link
Contributor

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
Copy link
Contributor

randellhodges commented Dec 18, 2019 via email

@tna11
Copy link

tna11 commented Dec 19, 2019

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

@boelle boelle added the A: STM32 label Feb 3, 2020
@iankds05
Copy link

iankds05 commented Feb 13, 2020

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
Copy link

jimi0303 commented Apr 8, 2020

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
Copy link

iankds05 commented Apr 9, 2020

IMG_20200409_101100
IMG_20200409_101124
IMG_20200409_101150
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
Copy link

jimi0303 commented Apr 15, 2020

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!
Annotation 2020-04-15 231523
Annotation 2020-04-15 231508

@thinkyhead
Copy link
Member

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
Copy link

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
Copy link

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
Copy link

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
Copy link

jimi0303 commented Apr 20, 2020

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
Copy link

lewiss66 commented Jun 1, 2020

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

@jimi0303
Copy link

jimi0303 commented Jun 1, 2020

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
Copy link
Contributor

@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
Copy link

jimi0303 commented Jun 1, 2020

@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
Copy link
Contributor

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
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Aug 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests