Most timers (except those which don't support DMA, e.g. the rudimentary TIM6/TIM7) provide a mechanism through which multiple TIM registers can be filled (or read out, although that's probably a rare application) in one go, sometimes called a "TIM DMA burst". It consists from two registers - TIMx_DCR, to which the index of first target register, and number of registers to be accessed in one "burst", is written; and TIMx_DMAR, which is not a true register, but a "window", through which the "currently indexed" register can be accessed. The "current index" is in fact an internal register, inaccessible directly to the user.
DMA's Peripheral pointer is to be set to TIMx_DMAR. The first DMA transfer of the "burst" is triggered by usual Update event (with TIMx_DIER.UDE being set). The subsequent transfers are then triggered by the "burst" mechanism upon accessing TIMx_DMAR (DMA writing to); up until an another internal "counter" reaches the count written to TIMx_DCR.DBL.
TIM can't distinguish between accesses from DMA, from processor (debugger is part of processor), or any other busmaster. If the TIMx_DMAR register is observed in debugger, this advances the internal "current index" and counter registers, thus messing with the DMA burst mechanism as it's intended to work. This can be tried experimentally: after setting up TIMx_DCR to access several registers previously written with various values, in a stopped processor with no DMA running, reading out TIMx_DMAR by debugger ("refreshing" the registers view, or setting the debugger to automatic readouts, "live mode") results in varying value in TIMx_DMAR, as its "window" shifts across the indexed registers.
The runtime results are then surprising, with the TIM registers getting "out of sync" with source data in RAM.
This is yet another, although maybe less expected, consequence of the fact, that debugging is intrusive.