STM32F373 Code Question

[real_felix9]

Posted on April 14, 2015 at 14:05

 

 

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on April 14, 2015 at 17:07

Don't rely on the debugger. Toggle a GPIO, and review period/duty on a scope.

The DMA likely occurs faster than the reaction time of you or the debugger, it also doesn't stop, the ADC+DMA operate independently of the CPU.

Other people who had issues like this tracable to the DMA unit changed FIFO modes, I don't think this is the problem here.

Clear the source of the interrupt, not everything.

[real_felix9]

Posted on April 22, 2015 at 22:25

Thank you clive.

I changed my code, so that only my interrupt source is cleard by the ISR.

But I still didn't get it, how I can test my code, when I can't rely on the debugger?

Can you explain that in more detail, please.

I want to see that the half transfer interrupt and the full transfer interrupt work correctly. But all I can see is, that both interrupt flags are set at the same time....

[Tesla DeLorean]

Posted on April 23, 2015 at 01:27

Can you explain that in more detail, please.

When you have a flywheel spinning at 1000 rpm you don't stick your finger in it to check it's speed, right? You have a hall sensor or switch, and you'd measure the frequency of pulses with a scope, or frequency counter. You observe behaviour, you don't interfere with it.

First you need to get beyond your ''debuggers are transparent'' mindset. Debuggers are invasive, they change the dynamics of a system, and are very bad for real-time measurements. If you stop in the debugger, other parts of the system continue to spin at very high speeds, certainly beyond your reaction time, and that of reading/writing screen messages.

The debugger also doesn't have magically access powers, if it reads USART->DR to display it's content to you it changes the state of USART->SR.

If you want to test ADC+DMA+TIM sampling speeds you toggle GPIO pins in the interrupt, or you record a time stamp in a RAM buffer that you can inspect later.

If the interrupts fire 1ms apart, by the time you see anything on the screen both will have appeared to have fired. If you want to see them in the debugger consider pushing the periodicity to 10 seconds.

You can use a USART or SWV connection to output diagnostic or telemetry information. You measure things over a second, and output information about the number of interrupts observed.

There is a role for single-step debugging, and parking a debug view over a peripheral, but there are more effective ways of understand the logic of code execution.