M574 Z1 S2 followed by G1 Z-27 F300 H4 causes an assertion failure reset

[dc42]

Duet Forum Discussion Thread

n/a

Which Duet products are you using?

• [ ] Duet2-Wifi
• [ ] Duet2-Ethernet
• [ ] Duet Expansion Breakout Board
• [ ] Duex2
• [ ] Duex5
• [ ] Duet2-Maestro
• [ ] Maestro Dual Driver Expansion
• [ ] Duet3-6HC
• [ ] Duet3-3HC
• [ ] Duet3-1XD
• [ ] Duet3-1LC
• [ ] Duet3-Tool Distribution Board
• [X] Duet3-Mini5+
• [ ] Duet3-Mini2+
• [ ] Raspberry Pi or other SBC
• [ ] SmartEffector
• [ ] Magnetic Filament Sensor
• [ ] Laser Filament Sensor
• [ ] PT100 Daughterboard
• [ ] Thermocouple Daughterboard
• [ ] PanelDue
• [ ] Other
• [ ] None

Firmware Version

3.5.0-beta.4

Duet Web Control Version

3.5.0-beta.4

Are you using a Single Board Computer (RaspberryPi) with your Duet?

• [ ] Yes I use a SBC.
• [X] No I do not use a SBC.

Please upload the results of sending M122 in the gcode console.

Last reset 00:00:18 ago, cause: software
Last software reset at 2023-06-20 12:02, reason: AssertionFailed, FilamentSensors spinning, available RAM 16564, slot 1
Software reset code 0x412d HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0000087d BFAR 0xe000ed38 SP 0x2003fe94 Task MAIN Freestk 62336 ok
Stack: 0000019f 000c14b8 0009cded 00000002 0009de09 20019048 20003038 2002cb50 20016510 00000000 00000000 00000000 00000000 00000000 0009ab99 2003fef0 20025438 0000003f 00085265 20018670 20025418 00000000 000878b5 20016510 0009e689 20025418 000878eb

What happened?

As in the title.

[dc42]

The reason is that DDA::CheckEndstops called form the step ISR ends up calling ZProbeEndstop::Stopped which tries to acquire the ZProbes lock. Changed the code so that ZProbeEndstop::CheckTriggered doesn't try to get the lock.

Confirmed that firmware 3.4.6rc1 is not usually affected, because acquiring a ReadWriteLock doesn't suspend task scheduling in that version.

[dc42]

Fix tested, now closing.