[BUG] Emergency Parser M410 crashes board STM32F1

[schlaegerz]

Bug Description

When using the EMERGENCY_PARSER flag after I send a M410 the board stops responding immediately.

The other emergency commands work just fine, and if I don't have EMERGENCY_PARSER M410 works fine, so it is something specific to that command.

My Configurations

Marlin.zip

Steps to Reproduce

1. Send any gcode commands
2. Send M410

Expected behavior: [What you expect to happen]
Board continues to function after stopping all movement.

Actual behavior: [What actually happens]
Board becomes unresponsive, likely crashing.

Additional Information

This is specific to this experience, as if I don't have EMERGENCY_PARSER it is able to work normally,

After testing I found out that I can call
planner.quick_stop(); without it crashing, but as soon as I call any of the other lines in quickstop_stepper() the board crashes immediately without any additional logging output.

This is on the latest Bugfix-2.0 branch since EMERGENCY_PARSER is not available on the main branch

[ellensp]

I just tried this on a STM32F103RET6 small system board core board (ie a development board, same MPU)
Using your Configs on latest bugfix.

Before...
14:52:40.271 > M119
Reporting endstop status
14:52:43.641 > x_min: TRIGGERED
14:52:43.641 > y_min: open
14:52:43.641 > z_min: open
14:52:43.641 > ok P15 B3

Send M410
14:52:43.642 > M410ok P15 B3

try M119 again after M410
14:55:35.933 > M119Reporting endstop status
14:55:39.140 > x_min: TRIGGERED
14:55:39.140 > y_min: open
14:55:39.140 > z_min: open
14:55:39.140 > ok P15 B3

Controller is still talking.

[borsegbr]

Same for LPC1769 M410 crash and reboot board! need not reboot to do a power loss recovery from host to clean queue and save energy please solve

[boelle]

please solve

what do you mean?

[borsegbr]

please solve

what do you mean?

M410 produce a crash that reboot the board

[boelle]

what do you mean with "please solve" ?

[borsegbr]

what do you mean with "please solve" ?

Mean guru of Marlin please come to fix this bug, I'll immensely greatfull to who have ability tho understand what's going wrong after stopping motors occurs.

[schlaegerz]

To get back on track, does anyone have any suggestions on what I could look into to debug this further? It is a real issue, but I don't have the experience in Marlin to know what could be crashing this.

[rhapsodyv]

Did you tried with the current bugfix?

is it only happen while printing?

[schlaegerz]

I had tried it on the latest when ellensp said it wasn't reproing for her, I can try the latest master in marlin and see if it fixed it.

It happens with pretty minimal comands from boot I had it reproing with this:

G28
M410

[schlaegerz]

Here is the full communication from turn on until it crashes:

M108
M109 S0
M110 N0
Read: ok P15 B3 
M110 N0
Read: ok P15 B3 
N1 M105*38
Read: ok P15 B3 
N2 M119*40
Read: ok P15 B3 
N3 M115*37
Read: ok T:23.44 /0.00 @:0 
N4 M105*35
Read: Reporting endstop status 
Read: x_max: open oks: 3
Read: y_max: open oks: 3
Read: z_min: TRIGGERED 
Read: z_max: TRIGGERED 
Read: ok N2 P15 B3
N5 M84*26
Read: FIRMWARE_NAME:Marlin 2.0.7.1 (Oct 14 2020 17:33:49) SOURCE_CODE_URL: PROTOCOL_VERSION:1.0 MACHINE_TYPE: EXTRUDER_COUNT:1 UUID:1
Read: ok N3
ok T:23.55 /0.00 @:0ok N5 P15 B3 
N6 G91*23
Read: ok N6 P15 B3
N7 M105*32
Read: ok T:23.67 /0.00 @:0 
N8 M105*47
Read: ok T:23.55 /0.00 @:0
N9 M105*46
Read: ok T:23.55 /0.00 @:0 
N10 G91*32
Read: ok N10 P15 B3
N11 G1 Y5*84
Read: ok N11 P14 B3 
N12 M105*20
Read: ok T:23.59 /0.00 @:0
N13 M105*21
Read: ok T:23.52 /0.00 @:0 
N14 M108*31
N15 M410*18
N16 M109 S0*95
Read: ok N14 P15 B3 
N17 M105*17
N18 M105*30
N19 M105*31

And I never get a response again. It is clearly handling the M108, but M410 fails.

I am able to hack the code to make it so M410 works as a normal command and M108 is in the emergency parse and that works for what I need. I am willing to help debug further if someone has any ideas, but this is not a blocker for me any more

[rhapsodyv]

is the watchdog enabled?

[rhapsodyv]

Which env are you using?

Emergency parser is not supported in USB Serial in stm32f1 without usb composite.

Or enabled usb composite, or use hardware serial (not -1).

I just send a PR for that: #19745

[borsegbr]

Did you tried with the current bugfix?

is it only happen while printing?

Last bugfix and happen in every state of machine,

[CornerBit]

I'm seeing the same thing on a GTR V1.0 (STM32F407IG). After a M410 I get a watchdog reset and the processor reboots. This only happens with EMERGENCY_PARSER enabled. I've also tested using a hardware serial port (USART3) instead of a USB coms (-1) and the issue persists.

[rhapsodyv]

Fixed there: #19752

Can you test it?

[schlaegerz]

Yep that works for me!

I'm not sure if this is expected or not, but it doesn't get me out of a homing command if I try to kill during it. Its fine with my implementation, but it isn't as immediate as I would imagine.

[rhapsodyv]

Yep that works for me!

I'm not sure if this is expected or not, but it doesn't get me out of a homing command if I try to kill during it. Its fine with my implementation, but it isn't as immediate as I would imagine.

do M112 gives the same behaviour?

[schlaegerz]

Nope M112 stops immediately.

[rhapsodyv]

are you using the my lasts commits?

Because M112 and M410 are being executed in the exactly same place...

  #if ENABLED(EMERGENCY_PARSER)
    if (emergency_parser.killed_by_M112) kill(M112_KILL_STR, nullptr, true);

    if (emergency_parser.quickstop_by_M410) {
      // quickstop_stepper will call idle, so we must set it to false to avoid infinite loop
      emergency_parser.quickstop_by_M410 = false;
      quickstop_stepper();
    }
  #endif

[schlaegerz]

Ah played around with it a bit more, and what is happening is it cancelling one move in the homing command, but there are a whole bunch of moves called from home so it is not stopping the rest of them.

[rhapsodyv]

Ah played around with it a bit more, and what is happening is it cancelling one move in the homing command, but there are a whole bunch of moves called from home so it is not stopping the rest of them.

Ok, so this a new issue, something like: "M410 don't stop when homing"...

Can you close this issue, and open another, relating that behaviour? It's another type of fix, as we would need to make a more robust M410.

[schlaegerz]

Ok well this bug still exists until your PR is in, since the emergency parser doesn't work without it.

[schlaegerz]

I'm going to do a bit more testing and then post the other bug as well

[schlaegerz]

After testing this same bug doesn't exist without emergency parser because it won't try to intercept in the middle of the command. It won't kill the homing, but it doesn't kill it half way, which is much worse, so all I can see with my board is that it breaks with your fix.

[rhapsodyv]

After testing this same bug doesn't exist without emergency parser because it won't try to intercept in the middle of the command. It won't kill the homing, but it doesn't kill it half way, which is much worse, so all I can see with my board is that it breaks with your fix.

Breaks with my fix?

The bug is: M410 crash board. Reason: it was executed inside a IRQ. Fix: execute out of a IRQ. With my fix, M410 will run properly, always.

Now, if M410 don't work with homing, it is not related with my fix, neither with this issue report. It's M410 that never worked with homing.

This issue is solved.

Please open other issue about homing + M410, and there we will find a fix for that.

[schlaegerz]

This issue will be solved when your fix is in I agree. Your fix accomplishes that, but you don't close a bug until it has a merged in fix.

I can't be the one to open the other bug since I can't repro it on the bugfix branch, I can only repro it on your branch. If you are correct about the behavior, other people will be able to repro it and file the bug, but if I post a bug people will ask me to try it on the latest bugfix, which obviously won't work due to this issue still existing on the branch, I personally cannot confirm that your fix is not the cause of this new issue, even if I am pretty sure it is not.

[schlaegerz]

This issue is fixed with that PR, whole feature is still not in a usable state though :/

[github-actions]

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.