Re: DMA losing sync on ST ARM processor

ave

a suggestion from a quick google

-Lasse

#axzz1yLmVUCe5

That's way too simple -- my problem isn't getting the right numbers out of the ADC. My problem is getting the right numbers out of the ADC, at the right times, and into the right spots in memory fast.

The _only_ way that I can see to do multiple consecutive ADC conversions with that part is to use the ADC scan mode and DMA -- so I pretty much must get it working.

It is very frustrating to halt the processor, restart, and see all the right numbers in all the wrong places. Scary, too, considering that I'm controlling enough power to make things awfully toasty if I screw it up.

should have mentioned I was looking at the post by "tony" two thirds down the page, look like scan of two channels with dma

-Lasse

I think the STM32 debug hardware has the option to stop the timer clocks when debugging. If you don't do that, perhaps your timer is triggering an ADC cycle while in the debug mode.

Mark Borgerson

to

d:

re

ry.

of

to

ks

at

I'm

generally when you are working on stuff that controls with motors and power stopping the cpu is not an option. You have to use some type of realtime debugger to look at variables and such

used to be that you had to make your own with uart or something like that, but now most also have to the option to do it over the jtag or what ever debug interface is used

-Lasse

The manual for the STM32F2xx mentions that the option to keep the timer clocks running when the CPU is halted for debugging is useful when using the timers to generate PWM for motor control.

Mark Borgerson

memory.

depends on how intelligent the timer is of course, but imagine a robot controlled by that motor, stop the cpu at the wrong time at it might just keep going until it hits something HARD

-Lasse

to

scrambled:

where

memory.

of

to

folks

conversions

up.

That kind of problem is always present when controlling motors and other mechanical systems. Real-Time debugging is difficult even with the best of hardware. That's one reason I've never been particularly interested in writing code for computer-controlled sawmills!

When I was working on autonomous aerial vehicle code, there were two kinds of debugging----offline PC sims to debug algorithms, and the "record everything and analyze after the crash" for the hardware- associated problems. (The 'crash' was usually not a computer reset type crash. It was an "I was flying and now I'm not" type of crash.)

Mark Borgerson

stm32/

It looks like he's doing what I'm trying; maybe he didn't debug.

At any rate, I found a horrible kludge that seems to work. At the end of the ISR, I reset the DMA controller leaving room for the ADC channels _plus one_. I'm sure that when I die and I'm trying to convince St. Peter that I belong up instead of down, that this kludge will be raised as a topic of conversation:

DMA.CHAN_1.CCR.bits.EN = 0; // disable DMA DMA.CHAN_1.CMAR = raw_adc_readings; // set address DMA.CHAN_1.CNDTR.bits.NDT = ADC_CHANNELS + 1; // Number of ADC channels + kludge DMA.IFCR.bits.TCF1 = 1; // Clear the transfer complete interrupt DMA.CHAN_1.CCR.bits.EN = 1; // enable DMA

ADC1.SR.bits.EOC = 0; // clear interrupt

at

so it is only when you debug? what are you using for debug?

of

I've seen worse but, are you setting the dma up for circular mode? if you do that and have the plus one aren't you pretty sure it will go wrong if you are ever late with the interrupt?

guess you could put a magic number at that extra location and if it ever gets overwritten panic or what ever makes most sense :P

-Lasse

JTAG, OpenOCD and gdb for debugging.

The DMA is _not_ in circular mode.

I may monitor the extra location -- but I suspect that I'll just find out that it stays zero until after I halt and restart.

he

ng

nd

did you have that before?

it should tell you something about whether it is the dma or the adc that gets confused

-Lasse