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

[coudu]

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

1. compile latest bugfix-2.0.x for BTT SKR E3 mini v2.0 with emergency parser enabled
2. send normal commands to the printer
3. 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]

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

[boelle]

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]

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]

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

[coudu]

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]

which env are you using?

[coudu]

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

[rhapsodyv]

STM32F103RC_btt_512K with SERIAL_PORT -1 is not currently handled.

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

[coudu]

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

[github-actions[bot]]

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]

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

[coudu]

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]

There're 3 types of usb/serial in STM32F1: 1) Hardware Serial - Support Emergency Parser Using SERIAL_PORT != -1 2) Usb Serial - DON'T Support Emergency Parser Using SERIAL_PORT == -1 3) 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]

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):

https://github.com/MarlinFirmware/Marlin/blob/3327568142f0294fa2b6e69b8b6567fa345ad205/Marlin/src/gcode/gcode.cpp#L493-L502

[rhapsodyv]

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

[Sebazzz]

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

[rhapsodyv]

I was looking at the code, and it seems exactly the same as the original PR, that @thisiskeithb tested: https://github.com/MarlinFirmware/Marlin/pull/19281

[Sebazzz]

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

[rhapsodyv]

It's already merged on bugfix since Sep 6.

[thisiskeithb]

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

Always test with the latest bugfix-2.0.x.

[Sebazzz]

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]

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]

Anyone can test if this branch solves the issue?

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

Thanks

[Sebazzz]

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.

[rhapsodyv]

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

[Sebazzz]

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

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]

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]

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]

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

[FirewinX]

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

[rhapsodyv]

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]

i have the board for testing available

[Sebazzz]

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

[FirewinX]

i write you on discord on private message @rhapsodyv

[arjanmels]

I also had problems on my SKR Mini-E3 v1.2 board. I submitted following fix: https://github.com/MarlinFirmware/Marlin/pull/21011, maybe this helps for v2.0 as well?

[Sebazzz]

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

[thisiskeithb]

Closing since https://github.com/MarlinFirmware/Marlin/pull/21011 was merged.

[github-actions[bot]]

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.