It's not clear if you have shoot-through problems, but you have rise-time problems at least.
The switching speed is too fast, launching EM pulses down the motor cables, the reaction of which ("every action has an equal and opposite reaction") causes the board's ground potential (with respect to its surroundings) to kick around. Which in turn imposes a voltage drop / current flow across any cables connecting to it.
This is real electromagnetism in action: the waveform truly is fast enough that propagation and wave effects are relevant. This is mostly in terms of energy conducted along wires, but radiation will even be perceptible even with such mean instrument as the oscilloscope.
I'm guessing your debug cable is plain naked ribbon cable, so the voltage drop imposed across it will be a significant fraction of the incident voltage. That is, if VCM is more than a couple volts (and it definitely is here), the voltage drop across the debugger VDD/GND wires and not the signal wires will corrupt the logic levels (which are merely 3.3V LVCMOS or whatever).
Ferrite beads on the debug cable will help, but far more effect is required than even a handful of ferrites can muster. Needless to say, you're also blowing out any nearby radio services, and might even be corrupting data on nearby cables (maybe you have other unshielded signals in or around the project, or connected to a nearby computer; or shielded cables but the shield connections are flaky, as sometimes happens). The noise must be addressed at the source.
Give these a try:
Light green: scrape away soldermask to expose bare copper.
Bright red: cut trace here.
Light red: component placement.
Yellow circled (1)'s: add 1206 or 1210 ceramic chip capacitors, as large as is available. Probably 2.2uF 100V. Prefer X5R or X7R type.
This provides bypass at the switch node supply. C57 is far too distant, and not enough by itself, to have adequate effect.
Cut the +60V supply trace and insert an inductor. Not much is required, 100s of nH will even do. Saturation current rated at least the maximum DC supply current; I'm guessing, several amperes.
If you have some spare magnetic cores, a few turns around an open (E or C) ferrite, or through a powdered iron toroid (typically yellow-white or green-blue colored; solid colors, or bare gray/black, are likely high-mu ferrite that will not work) will do, or a dozen turns of hook-up wire at a 5cm diameter (air core) will do. Keep wires/cables away from the inductor, of course.
Optional, but given that I don't see any other capacitors in this area, it is recommended. Same procedure as (1), add ceramic capacitors at (3).
Add filtering to the motor outputs:
Yellow: these should be large-ish ferrite beads or rings (1-4cm OD if tubular, 2-5cm OD if toroidal), and pass each wire through several passes (more if toroidal).
Ideally this would be done on board, with a few µH inductor (rated for peak motor output / load current), then an R+C snubber to GND at the connector, typically a few nF plus 10Ω or so (typically, \$R = \sqrt{L/C}\$). This filters the switching node, but does increase switching loss (the resistor dissipates whatever charge goes into/out of the snubber capacitor).
You should also increase gate resistors until the switch node risetime increases. Compare gate and drain waveforms to ensure you aren't causing shoot-through.
If increasing gate resistance isn't having much effect on risetime (dV/dt), consider adding an R+C from drain to gate. Not much should be needed; I would suggest starting with a value of 10Ω + 100pF and go from there.
For future improvement:
The switching loop length is large, particularly the ground-return path (through the thin traces to R42/R43), and routing it on both sides ensures ground is cut off between the bridges and drivers/controller (that is, ground-return impedance is high, a circuitous path is taken instead).
The TI reference design is not very easy to read, but is worth studying. Their switching loop is much tighter, and this translates to better switching performance, lower losses and lower emissions. Check against application notes for relevant controllers and drivers as well.
but my debugger usually fails to connect when the motor is connectedwhich MCU are you using and which type of debugger is in use? Since the question mentions a TI reference design, does Hardware checklist on the TI web page about JTAG connection issues help? \$\endgroup\$