SAMD controlling BLDC resets during high current spike; EMI problem?
Are you sure it's an actual reset though? It could be an EMI induced spike on another input that controls some sort of operating mode change in your MCU (in my case, it was the index line on the encoder input. If that thing misfires, it throws everything out of synch. It was happening on the encoder A and B inputs too but that just throws the encoder count off by a bit whereas something like the index line would completely make the MCU change operating states).

It could also be a brownout or ground bounce because I don't see any large (i.e. >470uF) decoupling capacitors for the motor currents.

It could also be EMI as it was the case in my circuit. When I ran into it, I was working on an FPGA so I was able to make a digital filter where all offending inputs (including the reset) would have to be stable for n-cycles before being accepted. On an MCU you can't do this so you would have to harden your MCU inputs by placing an R-C filter on the vulnerable input as close as possible to the input. There are other measures you can take too such as a tight PCB layout with good ground planes and small loops.

You can also help things by increasing the size of your gate resistors (or replacing them with ferrite beads whose impedance peaks at the ringing frequency you measure at the MOSFET gate pin). You can also add RC snubbers as well across your BLDC motor terminals or MOSFETs. All of the things mentioned in this paragraph work to slow the rise/fall times of transients in the power portion of your circuit which will reduce EMI.

But if it is EMI, I am not sure why you can't see it on the scope. In my case, I was able to scope the line and see it very clearly (but it is a very thin vertical line). Is it possible your scope isn't good enough or your measurement leads are too long?

EDIT: actually I think I lied. I don't remember seeing my EMI spike on the scope until AFTER I corrected the issue so the system could operate through the spike because if the system crashes you stop seeing anything and EMI spikes are spurios events that are difficult to trigger off of on a scope. You lose that critical tail end of the data where the untriggerable one-time event happens on a scope. You might need a DAQ running where you record high bandwidths for minutes so can scroll through all waveforms after-the-fact to see things. Mine was a software correction so it did not change the EMI itself so I could scope it after things were fixed. With a hardware solution so you might not see it on a scope after the problem was fixed.

If you're desperate, you can also reduce the size of your reset pin pull-up resistor with a capacitor to ground. Possibly even replacing it with a shunt so you can short-circuit it straight to +V. This is the most desperate of measures but simple to try out to confirm if it is EMI on the reset pin if you are unable to observe it on the scope. Unfortunately, this doesn't work on other lines that need to change states during operation.