search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.17k stars 19.21k forks source link

[BUG] Errors writing to eeprom on STMF103RC_btt_512K_stm32, works fine on STMF103RC_btt_512K #21964

Closed strayr closed 2 years ago

strayr commented 3 years ago

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

Yes, and the problem still exists.

Bug Description

Built attatched config against latest bugfix, I understand the _stm32 build targets are going to replace the old non _stm32 build targets? Ran ggcode to M502,M500 sort my settings out and M500 again and it throws a can't write to eeprom error and my terminal disconnects. Consistently reproducable with attacted gcode. I think doing this by hand and saving every line it's the M301 and M304 that it was failing on, but I didn't try every line, just the one lines that might be different from the base config. settings.zip

I don't know if it's my unusual config finding corner cases or something not being right with the eeprom config in the _stm32 target.

Marlin.zip

Bug Timeline

Pulled latest 2.0.x code and found issue

Expected behavior

writing to eeprom with m500 or attatched gcode should work

Actual behavior

writing to eeprom fails and disconnects terminal

Steps to Reproduce

Build attached config and install firmware on SKR Mini E3 v2.0 run settings.g

Version of Marlin Firmware

bugfix-2.0.x

Printer model

~ ender3 but irrelevant

Electronics

BTT SKR Mini E3 V2.0

Add-ons

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

No response

izzymoren0 commented 3 years ago

hi, have you tested the non 512k version? im using this one and it works with that.

Send:19:46:42.677: N81846 M500 Recv:19:46:43.100: echo:Settings Stored (676 bytes; crc 23990) Recv:19:46:43.101: ok N81846 P31 B3

strayr commented 3 years ago

hi, have you tested the non 512k version? im using this one and it works with that.

It's not a problem with the flash, the SKR mini e3v2.0 board has a separate AT24C32 eeprom it's not emulating eeprom with flash.

I've been building the 512k non stm target and it's been fine

I'll have to start cutting features to test the 256k version

TM32F103RC_btt_stm32/firmware.elf section `.rodata' will not fit in region `FLASH'
c:/users/rowla/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 24940 bytes
izzymoren0 commented 3 years ago

im using a lot of features but have no issues with the 256k version. binary is around 192kb. Seems that you have way more enabled which needs memory :D

strayr commented 3 years ago

UBL, MECHANICAL_GANTRY_CALIBRATION G34, G35, bunch of stuff to mak eoctoprint play nicely. Gets big fast. I'll have a look through see if there's anything I can trim but as it's working on a 512k target and the EEPROM is separate to the flash i don't see what this will achieve

izzymoren0 commented 3 years ago

im using bltouch, mesh leveling with subidivision+extrapolate, corner leveling and a lot of other activated menu stuff like pid autotune and so on too but i never get over 205kb with the stm32.

octo"slow" is a bottle neck, as those modifications which i think you did for it don't really play a big improvement here - except you play here with BufferBuddy or ArcWelder, which helps.

Thats not a serial or board problem, the reason is how octoprint is communicating via serial thats why i switched over to repetier server - there you have buttersmooth high speed prints even with the oldest Melzi 8 Bit board.

you can see the same via klipper+octoprint, a reason why so much using mainsail/fluidd.

strayr commented 3 years ago

Use a different build target and a political discussion on print servers way off topic for the bug reported. I know you're trying to be helpful but it's distracting from the problem in hand.

I'd like to see your config and don't mind discussing what i've enabled and why, but here is not the place.

GhostlyCrowd commented 3 years ago

Does the V2 E3 have its own eeprom? Its not emulated on MCU flash. So this could be a valid bug with this board. It wouldn't hurt to try and get under 256k as a test i think thats technically what the MCU is on the V2 anyhow over provisioning could still be a factor some how mangling marlin.

took a look at your configs there is some things that might not need to be enabled but thats depending on your actual usage. Meatpack on both serials? you drive this host with 2 different instances of octoprint on each serial?

Define ARC_P_CIRCLES - Not used by Arc welder if thats what your enabling this for, but again this might be on purpose for something else.

Remove your custom status screen as a test to save space as well.

There is no need to have TMCDebug on or Driver monitoring technically, with all that off i got it to 244k.

strayr commented 3 years ago

Does the V2 E3 have its own eeprom? Its not emulated on MCU flash.

Yes, the SKR mini V2 has its own dedicated AT24C32 eeprom chip, it shouldn't be using flash emulation.

Meatpack and arc support can massively reduce stuttering and print artifacts caused by that on fine details. No i dont need meatpack on both serial interfaces, I'll have a look at what's going on there.

TMC debug is there because i was chasing another issue. It's done now, but inabilty to run for a few weeks with some debug options is very inconvenient.

I'll try building @GhostlyCrowd 's suggestion and check it out on the block functional prints i have queued up now I don't have oher issues to solve, but it's still narrowing down the scope of the bug not a permanent fix.

strayr commented 3 years ago

Ok, I can confirm I can write to EEPROM on the STMF103RC_btt_stm32 build target with everything as was when reported the bug apart from the config files as attatched.

Just did a clean through vs code and it installed framework-arduinoststm32 @ 4.10900.200819 I don't know if it's an update? so I'm going to double check STMF103RC_btt_512K_stm32, pull the latest bugfix and see wheter the _USB targets build as being able to fire new firmware at the printer from my desk takes some of the pain out of trying new firmware.

config.zip

strayr commented 3 years ago

_USB targets fail to build with 

Compiling .pio\build\STM32F103RC_btt_USB_stm32\FrameworkArduino\WSerial.cpp.o
In file included from C:\Users\rowla\.platformio\packages\framework-arduinoststm32\system\Drivers\CMSIS\Device\ST\STM32F1xx\Include/stm32f1xx.h:133,
                 from C:\Users\rowla\.platformio\packages\framework-arduinoststm32\cores\arduino\stm32/stm32_def.h:28,
                 from C:\Users\rowla\.platformio\packages\framework-arduinoststm32\cores\arduino\stm32\usb/usbd_conf.h:30,
                 from C:\Users\rowla\.platformio\packages\framework-arduinoststm32\system\Middlewares\ST\STM32_USB_Device_Library\Core\Inc/usbd_def.h:29,
                 from C:\Users\rowla\.platformio\packages\framework-arduinoststm32\cores\arduino\stm32\usb/usbd_desc.h:25,
                 from C:\Users\rowla\.platformio\packages\framework-arduinoststm32\cores\arduino\USB.cpp:21:
C:\Users\rowla\.platformio\packages\framework-arduinoststm32\system\Drivers\CMSIS\Device\ST\STM32F1xx\Include/stm32f103xe.h:851:29: error: expected identifier before '(' token
  851 | #define USB                 ((USB_TypeDef *)USB_BASE)
      |                             ^
GhostlyCrowd commented 3 years ago

_USB target for experimental stm32 is not working yet, astm32duino needs to have some changes @rhapsodyv has some changes to make it work but they havnt accepted his PR

strayr commented 3 years ago

Thanks @GhostlyCrowd, I figured it was a framework-arduinoststm32 problem not a marlin problem but as usualy when squishing one issue more appear and might be already known about...

My <256k config has working eeprom when built for STMF103RC_btt_512K_stm32, maybe the update to framework-arduinoststm32 fixed this? Doing a very clean build of my orig bloated config. Remembering to eat first though.

strayr commented 3 years ago

Nope, problem still exists with firmware > 256k on the 512K_stm32 build target. Arduino update did not help

GhostlyCrowd commented 3 years ago

I think its reasonable to consider this a bug, something is being temperamental on the V2 E3 Mini with is built in eeprom on the 512K_stm32 platform

Quite curious 256K works.

If I understand correctly you built a binary below the 256k threshold on both, the 256K variant is fine its only 512k variant that errors.

thisiskeithb commented 3 years ago

problem still exists with firmware > 256k on the 512K_stm32 build target

If that's the case, then it's not a bug since you're overlfashing the chip. See this as well: https://github.com/MarlinFirmware/Marlin/blob/0987c3a3a3001279b6cca930ccb764dfb719652a/ini/stm32f1.ini#L108-L111

strayr commented 3 years ago

@thisiskeithb it's not a flash or emulated EEPROM error unlees for some reason it's emulating EEPROM when it should be using the dedicated AT24C32 chip.

The AT24C32 is separate to the main flash by design and a new feature on the V2 boards.

It looks like it's declared in Marlin\src\pins\stm32f1\pins_BTT_SKR_MINI_E3_V2_0.h?

// Onboard I2C EEPROM
#if NO_EEPROM_SELECTED
  #define I2C_EEPROM
  #define MARLIN_EEPROM_SIZE 0x1000                 // 4KB
  #undef NO_EEPROM_SELECTED
#endif

Would it work as a test if the above were commented out and i fell back on the declarations in Marlin\src\pins\stm32f1\pins_BTT_SKR_MINI_E3_common.h 

#if EITHER(NO_EEPROM_SELECTED, FLASH_EEPROM_EMULATION)
  #define FLASH_EEPROM_EMULATION
  #define EEPROM_PAGE_SIZE     (0x800U)           // 2KB
  #define EEPROM_START_ADDRESS (0x8000000UL + (STM32_FLASH_SIZE) * 1024UL - (EEPROM_PAGE_SIZE) * 2UL)
  #define MARLIN_EEPROM_SIZE    EEPROM_PAGE_SIZE  // 2KB
#endif

???

SamppaD78 commented 3 years ago

I had the same issue,not able to write/store settings on skr mini e3 2.0 with latest marlin release. And yes marlin 2.07 version worked without issues. Marlin 2.08.1 has some big issues. Examples: SKR tft 50 if printer is halted by user,screen temp values are frozen at that moment when printer is halted so you dont really know if hotend is really cooling down. Also hotend stays stuck on the print part when halted state is triggered.I would expect when printer is halted ,print has been stopped and nozzle lifted . Other thing is when you stop print in the middle,print is stopped but when you go to Marlin stock non touch screen you see that print is still active only paused,you need to stop it from there.. Random g code errors...but to get back on your issue..please compile firmware with non 512k version..this resolved my issue with random not able to store codes.

strayr commented 3 years ago

It works fine on STMF103RC_btt_512K just not on the _stm target.

Long term use on STMF103RC_btt_stm isn't particualry good for me, as I can't compile with debug options, so my options are

  1. stop pulling from bugfix when the non _stm build targets go away
  2. never build firmware with DEBUG options enabled and lose some features that are useful
  3. keep pointing out there's a regression between STMF103RC_btt_512K and STMF103RC_btt_512K_stm related to the DEDICATED EEPROM of the mini e3 v2.0 that SHOULD not be realted to a separate issue.

Again, if storing settings on the 2.0 board is using emulated eeprom on the flash as appears to be the belief of some of the contributors here and not the dedicated EEPROM like some of the older boards need to, that's a problem that needs to be fixed, whether or not it's for the 512k build target. I'm sure theres a whole world of other things that could be causing this, but denying the underlying archetcture is not helping anyone.

Votius commented 3 years ago

I'm also getting the same eeprom error with this board and newest bugfix branch, even with a 100% stock config. Using both the STM32F103RC_btt and STM32F103RE_btt environments in Auto Build Marlin.

CRCinAU commented 3 years ago

All the _512K environments are now gone - so this is probably a redundant bug now?

SamppaD78 commented 3 years ago

Who knows,but when you flash skr mini e3 2.0 dont use 512k option. Try to flash using STMF103RC_btt_256K_stm32. This will resolve many issues. SKR mini e3 2.0 has a 72MHZ stm 32bit processor and it has a 256k flash chip. Disable also all debugging options in Marlin,and leave some free space on flash chip,dont enable unnecessary stuff.

strayr commented 3 years ago

Disable also all debugging options in Marlin,and leave some free space on flash chip, dont enable unnecessary stuff.

Given the response to finding a problem with X is turn on DEBUG_X and send logs this is kinda problematic.

My options seem to be get a board that isn't going to have the rug pulled out from underneath it ...or use klipper.

CRCinAU commented 3 years ago

The board isn't the issue - its that the profiles caused issues trying to use 512K on chips that only had 256K.

Support for the 512K profiles have been removed and they were deemed unstable and risky.

The chip has 256K, and now you can build firmware with up to 256K in size for those boards.

SamppaD78 commented 3 years ago

The board isn't the issue - its that the profiles caused issues trying to use 512K on chips that only had 256K.

Support for the 512K profiles have been removed and they were deemed unstable and risky.

The chip has 256K, and now you can build firmware with up to 256K in size for those boards.

You are correct.

thisiskeithb commented 2 years ago

22919 / #22955 have been merged and should take care of the remaining EEPROM issues.

github-actions[bot] commented 2 years ago

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.