[BUG] emergency parser not working for STM32F1 (BTT SKR E3 mini v2.0) #19623

coudu · 2020-10-05T07:52:57Z

Bug Description

Emergency parser does not work for my STM32F1 board (BTT SKR E3 mini v2.0).
Emergency commands are not jumping the queue and are executed "in normal queue order".

My Configurations

configs.zip

Steps to Reproduce

compile latest bugfix-2.0.x for BTT SKR E3 mini v2.0 with emergency parser enabled
send normal commands to the printer
then send an emergency command (M112, M108 or M876)

Expected behavior: [What you expect to happen]
Emergency command should jump the queue and be executed asap

Actual behavior: [What actually happens]
Emergency command is executed after/at the end of other commands

coudu · 2020-10-06T20:54:28Z

might be related to #19567 as I see the same behavior when sending M108 after filament load...

boelle · 2020-10-13T21:45:13Z

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

coudu · 2020-10-14T18:33:51Z

Was already on latest bugfix, I just retested yesterday with latest commits and results are the same. I'am running the same config on a LPC1769 board and there is no issue with emergency parser.

rhapsodyv · 2020-10-14T18:37:12Z

None of the emergency parser commands work? or only M108?

coudu · 2020-10-14T18:45:14Z

unfortunately none... M108, M112, M876 to answer an host prompt, etc... everything is treated in queue order as if there were no emergency parser.

rhapsodyv · 2020-10-14T18:46:55Z

which env are you using?

coudu · 2020-10-14T19:00:30Z

I normally use STM32F103RC_btt_512K but I also tested STM32F103RC_btt_512K_USB and results are the same.

rhapsodyv · 2020-10-14T19:13:51Z

STM32F103RC_btt_512K with SERIAL_PORT -1 is not currently handled.

But STM32F103RC_btt_512K_USB must work... Can you try again?

coudu · 2020-10-14T19:18:55Z

not currently (LPC board in the printer) but i'll drop the STM32F1 in the printer to retest over the week-end.

github-actions · 2020-11-14T01:27:10Z

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

sjasonsmith · 2020-11-15T09:37:58Z

I'm replying to keep this open. The correct solution is probably to move boards to the STM32 HAL.

coudu · 2020-11-15T09:53:23Z

sorry but with lockdown back here in France and me not being locked and hard at work, I didn't have any time to put the board back in the printer to test. This SMT32F1 board will eventually go in a printer at work or a friend's one so I'll be able to test sooner or later...
Thanks!

rhapsodyv · 2020-11-15T17:36:04Z

There're 3 types of usb/serial in STM32F1:

Hardware Serial - Support Emergency Parser
Using SERIAL_PORT != -1
Usb Serial - DON'T Support Emergency Parser
Using SERIAL_PORT == -1
Usb Serial + Usb Composite (to use mass storage) - Support Emergency Parser
Using SERIAL_PORT == -1 + USE_USB_COMPOSITE is defined (envs with _USB)

The reason is that lib maple don't give us a way to intercept usb data when using only UsbSerial. To do that, we would need to copy too much code from lib maple, and don't worth it in the current state of STM32F1.

I suspect that this issue is because the user are using (2).

Sebazzz · 2020-12-03T18:21:23Z

I use SERIAL_PORT=-1 with USE_USB_COMPOSITE and it is also not working. To make it worse, understandably, EMERGENCY_PARSER commands are skipped during normal processing, so M112 does not work at all (gcode.cpp):

Marlin/Marlin/src/gcode/gcode.cpp

Lines 493 to 502 in 3327568

    
           #if DISABLED(EMERGENCY_PARSER) 
        
             case 108: M108(); break;                                  // M108: Cancel Waiting 
        
             case 112: M112(); break;                                  // M112: Full Shutdown 
        
             case 410: M410(); break;                                  // M410: Quickstop - Abort all the planned moves. 
        
             TERN_(HOST_PROMPT_SUPPORT, case 876:)                     // M876: Handle Host prompt responses 
        
           #else 
        
             case 108: case 112: case 410: 
        
             TERN_(HOST_PROMPT_SUPPORT, case 876:) 
        
             break; 
        
           #endif

rhapsodyv · 2020-12-03T18:39:33Z

Very weird. From where are you sending the M112? Computer serial or TFT Serial?

Sebazzz · 2020-12-03T18:40:01Z

Host, Octoprint. From TFT it does work, but that isn't using maple of course.

rhapsodyv · 2020-12-03T18:42:42Z

I was looking at the code, and it seems exactly the same as the original PR, that @thisiskeithb tested: #19281

Sebazzz · 2020-12-03T18:44:44Z

Sorry - my fault - 9a5fae4 isn't in the source I'm building

rhapsodyv · 2020-12-03T18:45:55Z

It's already merged on bugfix since Sep 6.

thisiskeithb · 2020-12-03T18:50:40Z

Sorry - my fault - 9a5fae4 isn't in the source I'm building

Always test with the latest bugfix-2.0.x.

Sebazzz · 2020-12-03T18:51:33Z

Sorry - my fault - 9a5fae4 isn't in the source I'm building

Always test with the latest bugfix-2.0.x.

Sorry I'm always confused with the branching here (vs develop/release branches). It is not in Marlin 2.0.7.2 which is what I was testing - sorry all.

thisiskeithb · 2020-12-03T20:34:50Z

Testing the latest bugfix-2.0.x (3eddbc7):

Board: SKR Mini E3 V2
Environment: STM32F103RC_btt_USB
Serial Ports: #define SERIAL_PORT 2 / #define SERIAL_PORT_2 -1:

Using OctoPrint: I sent M109 S210 to start a preheat & wait for hotend temp. Then I sent M112 and OctoPrint disconnected, but Marlin didn't halt.

Using a serial-connected BigTreeTech TFT: I sent M109 S210 to start a preheat & wait for hotend temp. Then I sent M112 and Marlin halted.

Unfortunately, there's something wrong with my board since it's causing the Z stepper motor to heat up hotter than the sun upon boot, so I won't be able to test further until I get a replacement in.

rhapsodyv · 2020-12-03T21:43:13Z

Anyone can test if this branch solves the issue?

https://github.com/rhapsodyv/Marlin/tree/fix-ep-usb-composite-stm32f1

Thanks

Sebazzz · 2020-12-22T18:36:15Z

3\. Usb Serial + Usb Composite (to use mass storage) - Support Emergency Parser
    Using `SERIAL_PORT == -1` + `USE_USB_COMPOSITE` is defined (envs with `_USB`)

I can confirm what @thisiskeithb says. To BTW retry it your can also use other emergency gcodes like M410 quick stop so Octoprint doesn't try to be smart. This happens on latest bugfix-2.0.x.

@rhapsodyv Your branch appears to be deleted.

Due to this bug: MarlinFirmware#19623

rhapsodyv · 2020-12-22T21:51:40Z

@Sebazzz my bad. I just fixed the branch. Can you test again?

Sebazzz · 2020-12-23T11:17:33Z

@Sebazzz my bad. I just fixed the branch. Can you test again?

@rhapsodyv No, sorry, doesn't work. All EMERGENCY_PARSER commands get ignored.

Is this bug a regression btw or has it never worked?

rhapsodyv · 2020-12-23T20:04:39Z

Is this bug a regression btw or has it never worked?

It's hard to say. I don't have a F1 with UsbSerial/CDC to test. When I did the development, @thisiskeithb tested it. But as we have some many serial options, could be a wrong test. But the code changed a bit over the months too...

Can you confirm that my_rx_callback is called?

Sebazzz · 2021-01-03T17:40:36Z

Is this bug a regression btw or has it never worked?

It's hard to say. I don't have a F1 with UsbSerial/CDC to test. When I did the development, @thisiskeithb tested it. But as we have some many serial options, could be a wrong test. But the code changed a bit over the months too...

Can you confirm that my_rx_callback is called?

No, it doesn't appear to be. I've put a while(true) in my_rx_callback and the printer keeps responding just fine.

FirewinX · 2021-01-17T21:45:22Z

i have the same Problem on a Ender 5 with a BIGTREETECH SKR MINI E3 V2.0 with stock Config Creality/Ender-5/BigTreeTech SKR Mini E3 2.0 on build STM32F103RC_btt_512K unload per btt tft35 is possible, but on octoprint shows permanently "paused for user" and cannot resume the print.

no feedback about filament changes on the tft35
after unloading, printing is simply continued without filament
loading afterwards is not possible

Sebazzz · 2021-01-17T21:46:44Z

@thisiskeithb @rhapsodyv Any pointers where I should look and try to debug it?

FirewinX · 2021-01-17T21:57:55Z

what should the line with while (true) look like in msc_sd.cpp @Sebazzz

rhapsodyv · 2021-01-17T22:00:29Z

Author here. Sadly I don't have such boards to test. If anyone that can test it the code for me, reach on discord, I can fix the issue. Same username.

FirewinX · 2021-01-17T22:07:15Z

i have the board for testing available

Sebazzz · 2021-01-18T17:32:02Z

@rhapsodyv I contacted you on discord, my handle is the same

FirewinX · 2021-01-18T18:24:50Z

i write you on discord on private message @rhapsodyv

arjanmels · 2021-02-06T15:41:22Z

I also had problems on my SKR Mini-E3 v1.2 board. I submitted following fix: #21011, maybe this helps for v2.0 as well?

Sebazzz · 2021-02-08T20:43:09Z

Confirmed @arjanmels - your fix works on the BTT SKR CR6 board. Thank you.

Upstream pull request: MarlinFirmware#19623 Upstream bug report: MarlinFirmware#19623 (comment)

thisiskeithb · 2021-02-08T20:48:57Z

Closing since #21011 was merged.

github-actions · 2021-04-10T01:58:04Z

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 bot added the stale-closing-soon label Nov 14, 2020

sjasonsmith added A: STM32 C: Safety and removed stale-closing-soon labels Nov 15, 2020

rhapsodyv added the Bug? False Alarm label Nov 30, 2020

rhapsodyv added Bug: Confirmed ! and removed Bug? False Alarm labels Dec 3, 2020

Sebazzz added a commit to CR6Community/Marlin that referenced this issue Dec 22, 2020

Disable EMERGENCY_PARSER

407f299

Due to this bug: MarlinFirmware#19623

Sebazzz mentioned this issue Dec 23, 2020

Provisional release notes for CR-6 community firmware release 5 beta CR6Community/Marlin#84

Closed

arjanmels mentioned this issue Feb 6, 2021

Fix emergency parser for stm32f1 #21011

Merged

Sebazzz added a commit to CR6Community/Marlin that referenced this issue Feb 8, 2021

Enable emergency parser again on BTT SKR CR6 boards

a2935aa

Upstream pull request: MarlinFirmware#19623 Upstream bug report: MarlinFirmware#19623 (comment)

thisiskeithb closed this as completed Feb 8, 2021

sarvenn mentioned this issue Feb 23, 2021

HOST_ACTION_COMMANDS popup Pause reboot bigtreetech/BIGTREETECH-TouchScreenFirmware#1590

Closed

github-actions bot locked and limited conversation to collaborators Apr 10, 2021

[BUG] emergency parser not working for STM32F1 (BTT SKR E3 mini v2.0) #19623

[BUG] emergency parser not working for STM32F1 (BTT SKR E3 mini v2.0) #19623

Comments

coudu commented Oct 5, 2020 • edited

Bug Description

My Configurations

Steps to Reproduce

coudu commented Oct 6, 2020

boelle commented Oct 13, 2020

coudu commented Oct 14, 2020

rhapsodyv commented Oct 14, 2020

coudu commented Oct 14, 2020

rhapsodyv commented Oct 14, 2020

coudu commented Oct 14, 2020

rhapsodyv commented Oct 14, 2020

coudu commented Oct 14, 2020

github-actions bot commented Nov 14, 2020

sjasonsmith commented Nov 15, 2020

coudu commented Nov 15, 2020

rhapsodyv commented Nov 15, 2020

Sebazzz commented Dec 3, 2020

rhapsodyv commented Dec 3, 2020

Sebazzz commented Dec 3, 2020 • edited

rhapsodyv commented Dec 3, 2020

Sebazzz commented Dec 3, 2020

rhapsodyv commented Dec 3, 2020

thisiskeithb commented Dec 3, 2020

Sebazzz commented Dec 3, 2020

thisiskeithb commented Dec 3, 2020 • edited

rhapsodyv commented Dec 3, 2020

Sebazzz commented Dec 22, 2020 • edited

rhapsodyv commented Dec 22, 2020

Sebazzz commented Dec 23, 2020

rhapsodyv commented Dec 23, 2020

Sebazzz commented Jan 3, 2021

FirewinX commented Jan 17, 2021 • edited

Sebazzz commented Jan 17, 2021

FirewinX commented Jan 17, 2021

rhapsodyv commented Jan 17, 2021

FirewinX commented Jan 17, 2021

Sebazzz commented Jan 18, 2021

FirewinX commented Jan 18, 2021

arjanmels commented Feb 6, 2021

Sebazzz commented Feb 8, 2021 • edited

thisiskeithb commented Feb 8, 2021

github-actions bot commented Apr 10, 2021

coudu commented Oct 5, 2020 •

edited

Sebazzz commented Dec 3, 2020 •

edited

thisiskeithb commented Dec 3, 2020 •

edited

Sebazzz commented Dec 22, 2020 •

edited

FirewinX commented Jan 17, 2021 •

edited

Sebazzz commented Feb 8, 2021 •

edited