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.

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

@chrishamm I've validated that the 1HCL boards do NOT have the termination jumpers connected, and the 1LC board DOES have it's jumper soldered.

I attempted to grab a M122 as fast as possible after the reset this time, and I sent the command 1 second after the notification popped up on the screen.

console.txt

@Phaedrux
Sure thing:

@NeoDue
A good suggestion!
I just went through and made sure all power supplies have their negative rails connected together, and tied the connected negative rails to earth ground at the closest power supply to the frame. I ensured all grounds are tied together star style, and are connected to earth ground via the outlet. I tied the frame to ground as well and validated that it has low resistance to ground. Each board's negative is tied to ground now and I added a 5V 10A MeanWell supply to the Raspberry Pi to ensure it's getting it's own clean power supply that's also at the same ground potential.

After doing all that, I am still getting the SPI errors while performing moves while in the Closed Loop plugin.

I've attached the M122 from the current instance of the issue, but I assume it's similar to the first one.
m122-2.txt

@chrishamm
I don't have any heaters or anything nearby.. The only steppers the Mini5 is controlling is the Z axis, the heaters are being controlled up on the toolhead, and the bed heater is controlled via an SSR (both are off during this process)
The part fan is also connected here, but is off during the tuning process. The 1HCLs are about 12" away from the board, along with their power supply, near the stepper motors driving the X/Y.
I've included a couple photos to show the setup, and added the M122 output here:

m122.txt