Improve STM32F4 Flash Behavior #17946
Conversation
FLASH_EEPROM_EMULATION takes about a second to erase the flash page on STM32F4 hardware, which will interfere with any ongoing activities. Disallow PRINTCOUNTER and FLASH_EEPROM_EMULATION to co-exist for STM32F4 hardware using HAL/STM32, to avoid issues during prints.
|
I'm hoping some of the users who have reported issues will be able to help test this and report back. All of these users have clearly indicated in one of the referenced issues that they encountered one or more of the problems this addresses. Note that |
Ill give this a test tomorrow when i get to my office and printers with SKR Pro's Does this change effect the SD eeprom emulation? Or did you want me to switch to flash emulation to test this? Also, to clarify you need us to undefine "FLASH_EEPROM_LEVELING" in the pin, the SKR pro doesnt appear to have this Only the FYSETC S6 does as far as i can tell on the STM32F4 platform. |
All of these changes only impact FLASH_EEPROM_EMULATION.
That is currently correct. I was going to enable it by default as part of this PR, but realized that would interfere with testing. I fully expect all of these issues would have existed on the S6, GTR, or any other STM32F4 board. |
|
The BTT002 is printing right now, so I’ll give this PR a go later today. |
Understood, I will test tomorrow Morning when i get to the hardware. |
|
I wonder if maybe the printcounter should not be flushed to the underlying eeprom storage (regardless of eeprom type) if there are any moves in the planner? Maybe a way to accumulate that data in memory and flush it out once only at the end. |
|
FYI, I did find this in the documentation, confirming what you said: "Any attempt to read the Flash memory on STM32F4xx while it is being written or erased, I wonder if instead of using the last 128k sector, if we can use the linker to adjust the start of the code to Sector 1. Then store the EEPROM in Sector 0. The layouts of sectors are: While we'd lose the ability to have like 100, 10x10 meshes stored and flash leveling wrapping around for every 32nd time, but, we'd be erasing a much smaller and hopefully faster sector? |
It sounds like it would be wise in-general to only write that once per Z height (i.e., once per layer) and then again if the print ends for any reason, and just accept the potential of the stored values being one layer off if the power goes out. |
|
Writing it out once per Z height would actually increase the EEPROM writes. Currently it writes it out once per hour, which align with people reporting layer shifts and other issues on the hour... The quick fix I was thinking was change I'm assuming the start/stop methods are already appropriately being called to persist the data if the print ends for any other reason.... Now that I type this all out, I realize doing it this way could be negated by only persisting when stop is called and remove it from being an interval save. Just my random thoughts. |
That's a good idea. |
|
So far everything seems to be fine for me SKR Pro STM32F4 Bltouch. Flash eprom Emu. |
|
I think you need to add #define FLASH_EEPROM_EMULATION outside the if statement as well because if you #define EEPROM_SETTINGS then how would you guarantee that FLASH_EEPROM_EMULATION will be turned on? #if NO_EEPROM_SELECTED I propose to add the below line in pins for the SKR PRO: Great work with this, will save me from crashing into the bed after an M500! |
|
In octoprint when setting up new eeprom, I get these errors. So how many slots for meshes are available now? And why does it say eeprom saved to slot 26? What happened to the mesh I have/had stored in slot 6? Is it gone? Thanks! Send: G29 L6 Send: M500 |
It's already there, it just only happens if you haven't already defined some other EEPROM or EEPROM Emulation. If the user has already configured some other form of EEPROM, you don't want to define FLASH_EEPROM_EMULATION. |
Apparently there are three slots now. If you need to store more than that you will need to turn It is safe to assume that they are gone if you have done an M500.
I enabled It did not occur to me when I made the change that people might have a bunch of UBL meshes saved in there. Sorry about that. |
|
Its ok, I had done a G29 S-1 on that mesh so I just read it back in into slot 0. |
If you need more UBL slots, it looks like you can keep |
|
Without I don't believe meshes would have access to the entire sector, unless Edit: Keep in mind, the EEPROM data is cached in memory. It seems boards using the F4 chip usually have it to spare, but if you wanted a bunch of meshes and set the EEPROM_SIZE to 64kB, that is going to hoard 64kB of memory |
|
In updating to the newest bugfix from the non-bugfix production version, I am now getting a BLTouch error: Changing monitoring state from "Error: !! STOP called because of BLTouch error - restart with M999" to "Offline (Error: !! STOP called because of BLTouch error - restart with M999)" This happens when I home and run G28. X and Y home just fine with sensorless homing. The BLTouch deploys and raises for 2 cycles and then throws this error. |
What board, can you upload your configs and also how is your probe connected? to Z min end-stop? |
|
I'll upload the configs later. But it is an SKR pro with a BLtouch
connected to the 4 pin connector for the bltouch.
…On Tue, May 12, 2020, 7:22 PM GhostlyCrowd ***@***.***> wrote:
In updating to the newest bugfix from the non-bugfix production version, I
am now getting a BLTouch error:
Changing monitoring state from "Error: !! STOP called because of BLTouch
error - restart with M999" to "Offline (Error: !! STOP called because of
BLTouch error - restart with M999)"
Connection closed, closing down monitor
This happens when I home and run G28. X and Y home just fine with
sensorless homing.
The BLTouch deploys and raises for 2 cycles and then throws this error.
What board, can you upload your configs and also how is your probe
connected? to Z min end-stop?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17946 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIZZJSFZDFFZCDPB66MUYRLRRHKZ7ANCNFSM4M5MMGFQ>
.
|
|
Here are the current configs and they produce the M999 issue. |
Interesting you have SW mode enabled and force 5v mode both of which shouldn't be needed on the SKR Pro, you also don't have any delay defined for your probe I assumed this worked before? I'd suggest enabling |
|
My thought with the 5V mode and force sw mode was to remove as much noise
as possible. This is on an FT6 and the cable run is kind of long plus goes
through the Folger Tech breakout boards for Ethernet and doing a 15x15 mesh
I need to do multiple probes it seems (10 right now, takes 12 hrs!) in
order to get an accurate bed mesh. Do you think the 5V and sw mode would
help with these? I know that doing multiple probes helps with the bed
accuracy but perhaps there are some settings that I could enable or disable
to reduce the number of multiple probes. I already have turn heaters off
and wait for bed heater and turn steppers off and fans off plus I unplug
the hot end cooling fan during probing. I'll try the settings above and
see. Thanks.
…On Wed, May 13, 2020, 8:46 AM GhostlyCrowd ***@***.***> wrote:
Here are the current configs and they produce the M999 issue.
Marlin-bugfix-2.0.x-11-5160.zip
<https://github.com/MarlinFirmware/Marlin/files/4619286/Marlin-bugfix-2.0.x-11-5160.zip>
Interesting you have SW mode enabled and force 5v mode both of which
shouldn't be needed on the SKR Pro, you also don't have any delay defined
for your probe #define BLTOUCH_DELAY 500 should be defined the probe
needs some sort of time to react.
I assumed this worked before? I'd suggest enabling #define
DEBUG_LEVELING_FEATURE in configuration.h Turn on with the command 'M111
S32' and seeing what it complains about when it fails.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17946 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIZZJSAYGKWOR6AR2SCKZ5DRRKJCBANCNFSM4M5MMGFQ>
.
|
The fastest way for us to see what's going on is to debug the probe with the mentioned settings. |
|
I'm still having the error. Here are the logs, I am not sure what is
happening. I turned on the delay and the leveling. Thanks.
Send: G28
Recv: >>> G28
Recv: Machine Type: Cartesian
Recv: Probe: BLTOUCH
Recv: Probe Offset X21.00 Y39.00 Z-2.87 (Right-Back & Below Nozzle)
Recv: Auto Bed Leveling: UBL (disabled)
Recv:
Recv: X current: 700 -> 800
Recv: Y current: 400 -> 800
Recv: Raise Z (before homing) to 15.03
Recv: >>> do_blocking_move_to X0.00 Y0.00 Z15.03
Recv: <<< do_blocking_move_to
Recv: T:17.90 /0.00 B:16.99 /0.00 @:0 B@:0
Recv: echo:busy: processing
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
Recv: >>> homeaxis(X)
Recv: Home 1 Fast:
Recv: >>> do_homing_move(X, -1110.00, [50.00])
Recv: <<< do_homing_move(X)
Recv: >>> set_axis_is_at_home(X)
Recv: Axis 88 home_offset = 0.00 position_shift = 0.00
Recv: > home_offset[X] = 0.00
Recv: current_position= X0.00 Y0.00 Z15.03 :
Recv: <<< set_axis_is_at_home(X)
Recv: current_position= X0.00 Y0.00 Z15.03 : sync_plan_position
Recv: current_position= X0.00 Y0.00 Z15.03 : > AFTER set_axis_is_at_home
Recv: T:18.17 /0.00 B:16.87 /0.00 @:0 B@:0
Recv: <<< homeaxis(X)
Recv: >>> homeaxis(Y)
Recv: Home 1 Fast:
Recv: >>> do_homing_move(Y, -517.50, [50.00])
Recv: echo:busy: processing
Recv: <<< do_homing_move(Y)
Recv: >>> set_axis_is_at_home(Y)
Recv: Axis 89 home_offset = 0.00 position_shift = 0.00
Recv: > home_offset[Y] = 0.00
Recv: current_position= X30.00 Y0.00 Z15.03 :
Recv: <<< set_axis_is_at_home(Y)
Recv: current_position= X30.00 Y0.00 Z15.03 : sync_plan_position
Recv: current_position= X30.00 Y0.00 Z15.03 : > AFTER set_axis_is_at_home
Recv: T:17.90 /0.00 B:16.60 /0.00 @:0 B@:0
Recv: <<< homeaxis(Y)
Recv: BLTouch Command :160
Recv: BLTouch Command :90
Recv: last_written_mode - 1
Recv: config mode - BLTOUCH_SET_5V_MODE
Recv: home_z_safely >>>
Recv: current_position= X30.00 Y30.00 Z15.03 : sync_plan_position
Recv: destination= X1.00 Y1.00 Z17.90 : home_z_safely
Recv: >>> do_blocking_move_to X1.00 Y1.00 Z15.03
Recv: <<< do_blocking_move_to
Recv: echo:busy: processing
Recv: T:17.99 /0.00 B:16.91 /0.00 @:0 B@:0
Recv: >>> homeaxis(Z)
Recv: current_position= X1.00 Y1.00 Z15.03 : Probe::set_deployed
Recv: deploy: 1
Recv: Probe::move_z(2.00)
Recv: BLTouch DEPLOY requested
Recv: BLTouch Command :10
Recv: BLTouch ALARM or TRIGGER after DEPLOY, recovering
Recv: BLTouch Command :160
Recv: BLTouch Command :90
Recv: BLTouch Command :10
Recv: BLTouch Command :90
Recv: BLTouch Command :10
Recv: BLTouch Recovery Failed
Recv: Error:!! STOP called because of BLTouch error - restart with M999
Changing monitoring state from "Operational" to "Error: !! STOP called because of BLTouch error - restart with M999"
Send: M112
Send: N2 M112*35
Send: N3 M104 T0 S0*34
Send: N4 M104 T1 S0*36
Send: N5 M140 S0*96
Changing monitoring state from "Error: !! STOP called because of BLTouch error - restart with M999" to "Offline (Error: !! STOP called because of BLTouch error - restart with M999)"
Connection closed, closing down monitor
|
|
I figured it out just needed to turn off Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN.
If that is off do I need this on?:
#define USE_PROBE_FOR_Z_HOMING
On Wed, May 13, 2020 at 3:47 PM Arion Mangio <[email protected]>
wrote:
… I'm still having the error. Here are the logs, I am not sure what is
happening. I turned on the delay and the leveling. Thanks.
On Wed, May 13, 2020 at 11:06 AM GhostlyCrowd ***@***.***>
wrote:
> My thought with the 5V mode and force sw mode was to remove as much noise
> as possible. This is on an FT6 and the cable run is kind of long plus goes
> through the Folger Tech breakout boards for Ethernet and doing a 15x15 mesh
> I need to do multiple probes it seems (10 right now, takes 12 hrs!) in
> order to get an accurate bed mesh. Do you think the 5V and sw mode would
> help with these? I know that doing multiple probes helps with the bed
> accuracy but perhaps there are some settings that I could enable or disable
> to reduce the number of multiple probes. I already have turn heaters off
> and wait for bed heater and turn steppers off and fans off plus I unplug
> the hot end cooling fan during probing. I'll try the settings above and
> see. Thanks.
> … <#m_-2130865378847682888_m_1233060633523041473_>
> On Wed, May 13, 2020, 8:46 AM GhostlyCrowd *@*.***> wrote: Here are the
> current configs and they produce the M999 issue.
> Marlin-bugfix-2.0.x-11-5160.zip
> https://github.com/MarlinFirmware/Marlin/files/4619286/Marlin-bugfix-2.0.x-11-5160.zip
> Interesting you have SW mode enabled and force 5v mode both of which
> shouldn't be needed on the SKR Pro, you also don't have any delay defined
> for your probe #define BLTOUCH_DELAY 500 should be defined the probe needs
> some sort of time to react. I assumed this worked before? I'd suggest
> enabling #define DEBUG_LEVELING_FEATURE in configuration.h Turn on with the
> command 'M111 S32' and seeing what it complains about when it fails. — You
> are receiving this because you were mentioned. Reply to this email
> directly, view it on GitHub <#17946 (comment)
> <#17946 (comment)>>,
> or unsubscribe
> https://github.com/notifications/unsubscribe-auth/AIZZJSAYGKWOR6AR2SCKZ5DRRKJCBANCNFSM4M5MMGFQ
> .
>
> The fastest way for us to see what's going on is to debug the probe with
> the mentioned settings.
> But yes the SKR pro doesn't need sw mode or 5v mote exclusively so try
> without it.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#17946 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AIZZJSEG6272FAGO6NJHXC3RRKZQVANCNFSM4M5MMGFQ>
> .
>
|
I believe you're correct. If you're not using Z min for the probe you have to tell the firmware it's using the probe as zmin or it will assume you still have a Z min endstop. |
|
Its working now. One curious thing I have noticed is that when I save the EEPROM, it increments to a smaller and smaller number, say after an M502 M500 M501 sequence. But if I just do M500 then it says it saved the current mesh in the current slot. So will the eeprom slots run out of storage? Or does FLASH_EEPROM_LEVELING take care of this? |
|
@DroneMang if you do M500 without changing anything it will say it stored settings, but it actually skips the unnecessary write. When the slots run out it will erase the flash sector and start over. |
|
@DroneMang The last sector is 128kB and we "use" 4kB for EEPROM. The leveling subdivides this 4kB into 32 "slots". Assuming the 128kB sector is empty (all 0's) it starts at the back and works forward so it can find the first non-empty slot. It starts at the beginning of the sector, scans until it hits non-empty data, that's how it knows what the current "slot" is (no other way figure it out), then subtracts one and fills that slot. Once it runs out, it erases the entire sector (can only erase full sectors) and starts over again. When you execute an M500, it evaluates each byte in "memory" vs what is stored in the EEPROM. If no bytes change, then nothing is done. No sense to "waste" a slot and an erase/write cycle if nothing changed. I stole this idea from the LPC code by p3p and just hacked it into the STMF4 HAL. Edit: Note that mesh data and "slots" used by the meshes is a subset of the 4kB EEPROM. When it says what EEPROM "slot" it saved into, that doesn't mean mesh slot. |
|
Very cool. It certainly does work. Idk if we really need more slots for
meshes, but a few more might be nice. Right now it's just 3.
…On Thu, May 14, 2020, 7:08 PM randellhodges ***@***.***> wrote:
@DroneMang <https://github.com/DroneMang> The last sector is 128kB and we
"use" 4kB for EEPROM. The leveling subdivides this 4kB into 32 "slots".
Assuming the 128kB sector is empty (all 0's) it starts at the back and
works forward so it can find the first non-empty slot. It starts at the
beginning of the sector, scans until it hits non-empty data, that's how it
knows what the current "slot" is (no other way figure it out), then
subtracts one and fills that slot. Once it runs out, it erases the entire
sector (can only erase full sectors) and starts over again.
When you execute an M500, it evaluates each byte in "memory" vs what is
stored in the EEPROM. If no bytes change, then nothing is done. No sense to
"waste" a slot and an erase/write cycle if nothing changed.
I stole this idea from the LPC code by p3p and just hacked it into the
STMF4 HAL.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17946 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIZZJSECOKI3I5T5N6J6FYLRRR2YBANCNFSM4M5MMGFQ>
.
|
|
Make note of your settings, then in your configuration file, Add Or Just keep EEPROM_SIZE a multiple of 4kB. If you do not, I do not know how it will respond to the change. It should evenly divide into 128 and be more than 4. Edit: You only get 3 meshes with the default 4kB? I am using an LPC1769 and I thought it was doing 4kB and gave a few more meshes. I'll have to double check, now I'm curious. How many points are you using? |
Description
Improves several issues related to FLASH_EEPROM_EMULATION for STM32F4 environments using HAL/STM32.
Hopefully several people will volunteer to test this prior to it being merged. While I believe this resolves the issues stated, I have only tried it on my SKR Pro board, and perhaps it causes issues for other configurations of non-STM32F4 boards using this HAL.
1. Clear flash error bits prior to writing to flash
Apparently STM32F4 MCUs come up with flash error bits set, that need to be cleared prior to flash operations. This caused the erase operation to fail, resulting in no data being stored. A second M500 was previously needed to succesfully store settings.
This is discussed in this post on the ST forums
2. Disallow PRINTCOUNTER when using FLASH_EEPROM_EMULATION with STM32F4
It takes just over one second on my SKR Pro to erase the 128kB flash sector used for EEPROM emulation. During this time the flash cannot be accessed at all, including to execute code from other sectors. This greatly interferes with timing and would be a generally bad idea during prints.
3. Pause servo output during flash erase
As mentioned above, erasing the flash sector takes just over one second on my board. This disrupts servo (BLTOUCH) output to the extent that it does not recover.
Prior to performing a flash erase, this now pauses all active Servo output and disables interrupts, to avoid scenarios where interrupts misbehave if they run while flash is inaccessible. Previous Servo output is restored after the flash operation is complete. My BLTouch seems perfectly happy with this arrangement.
The following image demonstrates the duration of the gap in Servo output:
4. Add sanity check to report error if
FLASH_EEPROM_LEVELINGis specified incorrectlyFLASH_EEPROM_LEVELINGis very useful to reduce/hide the impacts of the issues this PR addresses. This is because it only erases the flash every 33rd time it is written. I wanted to be sure people could not specify it hoping for those benefits, and have it be silently disabled.Benefits
This makes
FLASH_EEPROM_EMULATIONmuch more usable on STM32F4 boards, in the two primary ways:Related Issues
#17627 - SKR PRO, M502 M500 twice to update EEPROM
#16169 - SKR PRO Bltouch doesn't work after M502/M500/M501 (flash emulation related)