Below I preserve the text of an obviously AI-generated spam post, which will be probably removed by moderators, as it's mostly correct; although - being AI generated - obviously does not contain the understanding of the root of problem, which is probably contention on processor's AHBP bus.
As an excercise, in the "jittery" state, you could try to swap first write to GPIO with write to TIM10 SR
impulse.TxPort->ODR = impulse.Step1; // First clamp output channel
TIM10->SR = 0;
... and here come the nops...
although I'm not sure if it helps and/or not introduces any other problem.
On a general note, the AI is right and nop-timed events are prone to timing issues, especially in a (mildly) superscalar processor as the Cortex-M7 is. You may want to strive to use hardware for strictly timed events, e.g. timers.
Also, even if it's not the issue here, but generally, don't use GPIO_ODR to change pins' state, use GPIO_BSRR instead, that is guaranteed to be atomic.
JW
--------:
It seems that your ISR timing is being affected by resetting the IWDG in the main loop. This may be happening because the IWDG reset is causing a delay in the execution of the instructions in the main loop, which in turn is causing the ISR to be delayed.
When the IWDG counter is reset, the CPU has to perform several operations to reload the counter and restart the watchdog. These operations take a certain amount of time to execute, during which the CPU cannot execute any other instructions. If the main loop is executing instructions during this time, those instructions will be delayed by the IWDG reset.
One way to avoid this issue is to disable interrupts while resetting the IWDG in the main loop. This will prevent the ISR from being delayed by the IWDG reset. Another way is to increase the priority of the ISR so that it is not delayed by other interrupts.
It's also worth noting that the use of nops in the ISR is not a reliable way to generate precise timings, as the number of cycles required for each nop instruction can vary depending on the CPU clock frequency and other factors. Instead, you could use a hardware timer to generate the required timing signals, which would be more accurate and less affected by other factors.
