[BUG] Stepper recursion with ESP32 I2s expanders & laser

[HoverClub]

Marlin.zip

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

Yes, and the problem still exists.

Bug Description

ESP32 exception generated at the end of a laser move in dynamic mode (G4 I).

Fully described here:

#22690 (comment)

I can confirm that the issue is caused by current_block being null. The only way I can see this happening is if block_phase_isr() (called from I2S stepperTask()) gets called again (as it does every 4uS) before the previous block_phase_isr() has completed. That could happen if block_phase_isr takes longer than 4uSec as stepperTask() is running on a separate thread. On the last block move, pulse_phase_isr() (called just before block_phase_isr()) has completed the last step then, because steps are complete, the 2nd call discards the block - the first call hasn't completed at this point but current_block is now null.

The fix in the above link does appear to work but doesn't really solve the issue properly if code trying to accessing the block gets added after that line in future. A busy flag on entry/exit to block_phase_isr() would also work at preventing recursion but I am reluctant to mess with the stepper code (unforeseen consequences and all that!). Anyone got a better idea?

Bug Timeline

#22690 (comment)

Expected behavior

No exception!

Actual behavior

Exception.

Steps to Reproduce

1. Configure for any board with an ESP32 and I2S expander
2. Enabled LASER_FEATURE
3. Issue G4I then G1Xnnn at terminal and an exception will be thrown. If you use a long distance move at a slow feed rate you will see the exception always occurs at the end of the move.

Version of Marlin Firmware

bugfix2-2.1.x

Printer model

Custom

Electronics

MKS TinyBee

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[vfbank]

All chipsets that use ESP32 have this problem. In particular, this problem occurs when performing operations such as updating ROM data, where dynamic mechanisms cannot be executed, so stopping one operation and resuming another will result in the loss of previous operation values. This appears to be a limitation of the EPS32 I2C system. In the case of 3D printers, a layer shift phenomenon is discovered when G-code reading stops momentarily.

It seems like you'll need some kind of groundbreaking system to use this chipset properly. Something like a separate system buffer for I2C.

[HoverClub]

Turned out to be nothing to do with recursion, task switching or interrupts - just a simple sequencing issue!

[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.