Adding to this discussion a little. If I manually post each line from my homeall.g command to the console and execute them in sequence, they seem to work properly. However, if I generate a macro with the 3 commands:

G1 H1 X-625 Y605 F3800
G1 H1 X-625
G1 H1 Y605

the board seems to no longer pause when each endstop is triggered, almost like it's executing them all instantly. The endstop monitor plugin shows each endstop being triggered, however when X is triggered, for example, the feed does not stop in the X direction and continues until the full move has been completed.

This was after an upgrade from 3.4.4 to 3.4.5

@NeoDue It is indeed a 250Mhz scope and I tested at a few speeds and triggers, to see if there was any detectable spikes.
I saw mentioned in another thread to verify if NC endstops are used, so i'll double-check that too.

@dc42 I went and installed that version on all four boards and the noises stopped, even at high speeds there is no more thunking noises from the motors.

Thanks for the fix!

@dc42 I went and installed that version on all four boards and the noises stopped, even at high speeds there is no more thunking noises from the motors.

Thanks for the fix!

@dc42 I don't see one in the list of system files, I don't think I have one.

3.6.0-rc.1 has the issue, so I went back further and re-verified the 3.5.4 did not have the issue. From there I upgraded to 3.6.0-beta.1 but that did not successfully install, so I went to 3.6.0-beta.2 and that did install, and has the issue.

So I recently upgraded to 3.6.0-rc2, and after the upgrade, I notice that the motors now click/thunk approx every 250ms. The motors are on EXP1HCL boards, and are not in closed loop mode, as I haven't been able to get that working right yet.
It does not appear to be skipping steps, and to validate that, I slowed the printing down to 20% or so, and by slowing down, the clicking gets quieter, but has the same ~250ms cadence. Speeding it up and slowing it down changes the volume but not the speed of the clicking. Rapid movements track correctly but the faster motion causes the clicks to be louder.
If needed I can take a video and post that.

I've included the config.g and the M122 output from all boards on the system:
M122.txt
config.g

@chrishamm It appears to be happening much less with 3.5.1, though I was able to trigger a SPI reset; it happened after about 40 moves instead of one or two.

Instead it appears the data capture is being cut off somewhere, as the received data should be 1 second long but i am only getting around 150-350ms of data back for each run. Once in awhile (about every 10 runs) I get a complete data log.

Here's a screenshot showing my settings and the returned data:

EDIT: Looks like I spoke too soon, it seems to be resetting just as often on longer moves (100mm+).
I also validated that the endstop wasn't the culprit by unplugging it after homing, it still seems to reset without that connected.

@NeoDue It is indeed a 250Mhz scope and I tested at a few speeds and triggers, to see if there was any detectable spikes.
I saw mentioned in another thread to verify if NC endstops are used, so i'll double-check that too.

Spent some more time on this tonight.

I disconnected everything not necessary from the Duet board, leaving only power, 1 endstop, and the Z stepper motors, along with the CAN bus and SPI cable. Curiously I saw a reset or two happen without movement.

I hooked up a logic analyzer to the SPI lines and checked those. I also enabled debug logging via the USB port.

I checked the Duet's 3.3v line for any issues, spikes, noise, etc, but it is very quiet and during motor movements I saw no noise on it, so I feel like I've ruled out a brownout on the processor. I looked at some other lines but similarly didn't see much noise at all on them.

Curiously, with debug enabled, the reset errors became much less frequent, which makes me wonder if there's a race or something that's causing a reset of the board.

I've included a CSV of the SPI logging, and a text log from the Duet's serial output while the issue happened. The reset is at the end of the files, I stopped logging right after it died. I have the Saleae Logic file which I can send on request as the forum doesn't support that filetype.

mini5_reset_log.txt
mini5plus_reset.csv

A bit more info as I went through attempting to tune the motors again today.. it seems if the motor is oscillating a bit, i.e. running a low P (<20) with all other parameters set to zero, the resets happen more often and i can't get more than about 300ms of data from the board, but setting to higher values seems to make it happen less. An odd thing for sure.

@NeoDue Sadly, the change here was to move to closed-loop stepper control via the 1HCLs, and the closed-loop tuning is what seems to be instigating this issue, as I've never had this error occur outside running the closed loop tuning commands, so it seems like it's been narrowed down to something going on here.
I appreciate the help!

@NeoDue I was running a "Record" command from the Closed Loop tuning plugin with these settings:

Upon clicking Record, there's about a 20% chance the move will begin, and while the move is taking place, the printer will stop moving and the board resets.
After going through plenty of motor tuning, the settings here don't seem to have any effect on the SPI errors. I'm assuming it may have to do with the motor data being transferred out of the controller to the Pi, but not sure if that would cause a reset or some other error may cause it.

I don't have any physical reset buttons installed anywhere, just the board itself.
Would any CAN bus commands from other boards cause a reset of the main Duet board?