GCode file causes partial(?) reset

[dc42]

I've determined that the memory protection fault occurs while processing a M27 command. This command is rarely used these days, however Pronterface sends is regularly.

Does the problem occur at the start of printing, or the end, or in the middle?

[dc42]

PS - are you running the Duet 3 with an attached SBC, or in standalone mode?

[oliof]

I am running in SBC mode and have a tool distribution board and a (single) toolboard as well.

[dc42]

Thanks, I've found the problem. When M27 is received from USB when you are printing a file from the Pi, the M27 command should be passed to the Pi for processing. I've now implemented this in RRF3.2.

[oliof]

Great find! I assume that the latest KISS V2 alpha release added M27 support.

[dc42]

@oliof said in GCode file causes partial(?) reset:

Great find! I assume that the latest KISS V2 alpha release added M27 support.

It's Pronterface that's generating the M27 commands, not the slicer.

[oliof]

@dc42 I am not using pronterface (my printer is not connected to anything via USB. Pi via SBC interface and a PanelDue).

[dc42]

In your original post, you said your M122 report was taken after you triggered a print using Pronterface :

@oliof said in GCode file causes partial(?) reset:

Hi,
I have a gcode file generated with the latest KISS Slicer v2 alpha which consistently soft resets the printer when I try to print it via DWC or serial console.
Here is M122 after trying to trigger a print with pronterface using M32:

[oliof]

Oh true, but that was just to rule out it's DWC running into some error. The same happens without pronterface in the mix.

[dc42]

Does the GCode file you are trying to print contain M27 commands?

[oliof]

It does not, see the olm-x_end_stop.gcode I attached to https://forum.duet3d.com/post/164699

[dc42]

The firmware crash recorded in the M122 report you posted was caused by M27. But you said that was provoked by starting a file print from Pronterface. I am wondering whether you found more than one way to crash the firmware? If you did, then I need a M122 report from after it crashed in the other way.

I've put a pre-release RRF 3.2 build at https://www.dropbox.com/s/p28vp6fbnkc4rbz/Duet3Firmware_MB6HC.bin?dl=0 in which the M27 issue should be fixed.

[oliof]

@dc42 I can crash without pronterface, pronterface was just used to see whether this is DWC specific or not. I'll provide an M122 over the weekend from a DWC induced crash, and try the build you linked (I did a build myself but didn't get around to testing it yet).

[oliof]

Here is an M122 from a reset triggered when selecting to print a file via DWC

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DGM-9T66A-G63SJ-6J1D6-3SD6R-9U0BA
Used output buffers: 1 of 40 (13 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162672 of which 188 recycled
Exception stack ram used: 520
Never used ram: 75232
Tasks: NETWORK(ready,1968) HEAT(blocked,1188) CanReceiv(suspended,3424) CanSender(suspended,1428) CanClock(blocked,1436) TMC(blocked,68) MAIN(running,2868) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:20:54 ago, cause: power up
Last software reset at 2020-07-05 15:48, reason: User, spinning module LinuxInterface, available RAM 75268 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 31.8, current 36.9, max 37.0
Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.3, max 12.3, under voltage events: 0
Driver 0: standstill, reads 32356, writes 11 timeouts 0, SG min/max 0/1023
Driver 1: standstill, reads 32357, writes 11 timeouts 0, SG min/max 0/1023
Driver 2: standstill, reads 32367, writes 0 timeouts 0, SG min/max not available
Driver 3: standstill, reads 32359, writes 8 timeouts 0, SG min/max 0/338
Driver 4: standstill, reads 32359, writes 8 timeouts 0, SG min/max 0/1023
Driver 5: standstill, reads 32358, writes 8 timeouts 0, SG min/max 0/1023
Date/time: 2020-07-10 19:42:47
Slowest loop: 5.91ms; fastest: 0.21ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 345, MaxWait: 116335ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 17, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.70ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8
- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 18347, longest wait 1ms for type 6013
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 16ms ago
RX/TX seq numbers: 678/38571
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 27.96
 

[oliof]

And a other this time with some error from DCS before

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DGM-9T66A-G63SJ-6J1D6-3SD6R-9U0BA
Used output buffers: 1 of 40 (13 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162672 of which 188 recycled
Exception stack ram used: 520
Never used ram: 75232
Tasks: NETWORK(ready,1968) HEAT(blocked,1188) CanReceiv(suspended,3424) CanSender(suspended,1428) CanClock(blocked,1436) TMC(blocked,68) MAIN(running,2868) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:28:09 ago, cause: power up
Last software reset at 2020-07-05 15:48, reason: User, spinning module LinuxInterface, available RAM 75268 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 36.7, current 37.0, max 37.1
Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Driver 0: standstill, reads 36602, writes 8 timeouts 0, SG min/max 0/595
Driver 1: standstill, reads 36601, writes 8 timeouts 0, SG min/max 0/1023
Driver 2: standstill, reads 36610, writes 0 timeouts 0, SG min/max not available
Driver 3: standstill, reads 36601, writes 8 timeouts 0, SG min/max 0/101
Driver 4: standstill, reads 36602, writes 8 timeouts 0, SG min/max 0/993
Driver 5: standstill, reads 36602, writes 8 timeouts 0, SG min/max 0/1023
Date/time: 2020-07-10 19:50:02
Slowest loop: 5.16ms; fastest: 0.21ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 349, MaxWait: 256811ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.52ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8
- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 2575, longest wait 1ms for type 6013
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 19ms ago
RX/TX seq numbers: 1318/52023
SPI underruns 0, overruns 0
Number of disconnects: 1
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 29.32
 

[oliof]

I updated the 3.2 build and now I cannot connect to the board cleanly anymore. DCS complains:

Jul 10 21:05:02 vcore-pro DuetControlServer[1692]: [fatal] Could not connect to Duet (Board is not available (no header)

It's getting late here -- I will probably need to reflash via BOSSA to 3.1.1 and then see how to continue.

[oliof]

Back to 3.1.1 once more tonight -- I'm getting comfortable with BOSSA (-:

A freshly booted machine again crashes when uploading and starting a print via DWC:

console entries:

7/10/2020, 9:27:42 PM	Upload of 1515-T-connector-vcore-pro.gcode successful after 3s
7/10/2020, 9:27:44 PM	M32 "0:/gcodes/1515-T-connector-vcore-pro.gcode"
File 0:/gcodes/1515-T-connector-vcore-pro.gcode selected for printing
7/10/2020, 9:27:45 PM	Connection interrupted, attempting to reconnect...
DCS has been stopped
7/10/2020, 9:27:54 PM	Connection established

I Immediately ran an M122:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DGM-9T66A-G63SJ-6J1D6-3SD6R-9U0BA
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162880 of which 188 recycled
Exception stack ram used: 520
Never used ram: 75024
Tasks: NETWORK(ready,1968) HEAT(blocked,1188) CanReceiv(suspended,3396) CanSender(suspended,1444) CanClock(blocked,1436) TMC(blocked,68) MAIN(running,2672) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:09:44 ago, cause: power up
Last software reset at 2020-07-05 15:48, reason: User, spinning module LinuxInterface, available RAM 75268 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 26.7, current 35.6, max 35.9
Supply voltage: min 24.0, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Driver 0: standstill, reads 22793, writes 49 timeouts 0, SG min/max 0/1023
Driver 1: standstill, reads 22793, writes 49 timeouts 0, SG min/max 0/856
Driver 2: standstill, reads 22832, writes 11 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 22824, writes 19 timeouts 0, SG min/max 0/154
Driver 4: standstill, reads 22825, writes 19 timeouts 0, SG min/max 0/210
Driver 5: standstill, reads 22825, writes 19 timeouts 0, SG min/max 0/97
Date/time: 2020-07-10 21:27:59
Slowest loop: 4.65ms; fastest: 0.14ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 372, MaxWait: 42423ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 107, completed moves: 107, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1.02ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8
- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 2343, longest wait 2ms for type 6011
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 16ms ago
RX/TX seq numbers: 181/17363
SPI underruns 0, overruns 0
Number of disconnects: 1
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Daemon:
Finishing macro daemon.g, started by system
> Next stack level
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 20.83

This is the gcode file in question:

1515-T-connector-vcore-pro.gcode

It's notable that the printer is still homed, so it wasn't a full reset.

(DWC 3.1.1, RRF 3.1.1)

[oliof]

Over the weekend I did a couple slices with Superslicer (PrusaSlicer fork) which did not cause the reset. I'll try to come up with minimal gcode with as little differences as possible to see if I can isolate what causes this. It will take some time though since I'll be traveling for work this week.