STM32F7 - Bug in ADC?

danielschramm9 · ‎2015-10-07

Posted on October 08, 2015 at 08:15

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

AvaTar · ‎2015-10-08

Posted on October 08, 2015 at 12:59

>Signal Source is a low impedance (8 Ohm 65W)

That can't be true - at least that can't be what the ADC sees. 65W on 8 Ohm would amount to about 22V/2.5A.

Of interest is what your ADC input actually sees. Perhaps your voltage divider is wrong, and you see only the 2 or 3 least significant bits of the ADC moving ? That's what you image looks like.

I would check the ADC input signal at the pin, with a scope.

danielschramm9 · ‎2015-10-08

Posted on October 08, 2015 at 14:03

Of course I do not have a current flow of 65W, I just wanted to show, that high impedance voltage devider cannot be the issue here. The Toellner TCE7741 is only the source providing the 0V to 3V sine without any extra series resistor.

Interesting is that there is really no noise (even without averaging) on the horizontal parts of the curve in the raw data from the ADC. Normally I would expect some LSB changing.

The sinus is perfect at the header on the board. I cannot measure directly at the pin of the µC since it is BGA package. The schematic says that there is no series resistance in between. And again, it's really low frequency: 3.6Hz (not kHz, not MHz), so series inductance of the tracks should not be an issue.

The X-Axis of the diagram shows the DAC value 0-4095 = 0-3.3V, so it's the whole sinus amplitude we see there and not some LSB noise.

Daniel

AvaTar · ‎2015-10-08

Posted on October 08, 2015 at 14:53

Of course I do not have a current flow of 65W, I just wanted to show, that high impedance voltage devider cannot be the issue here. The Toellner TCE7741 is only the source providing the 0V to 3V sine without any extra series resistor.

Maybe I'm slow-witted, but you can't connect the ADC pin to your 65W source directly, because the 22V output would blow the MCU. Some kind of voltage divider needs to be involved.

The sinus is perfect at the header on the board. I cannot measure directly at the pin of the µC since it is BGA package. The schematic says that there is no series resistance in between.

And if you measure closest to to the input - perhaps scratching the protective lacquer off the PCB track ? Schematics do not necessarily represent reality, especially for prototype boards. Can you check the proper PCB routing on an unpopulated board ?

The X-Axis of the diagram shows the DAC value 0-4095 = 0-3.3V, so it's the whole sinus amplitude we see there and not some LSB noise.

For getting untested software on prototype board running, I usually avoid such intertwined testing. I suggest to use a simple ADC code without DMA in continuous mode, a potentiometer (or another known, adjustable voltage source) at the input header, and some printf - like debug output.

However you do it, try getting one peripheral running at a time, not all at once. That method proved best for me ...

ST's DAC peripherals have a high output impedance in unbuffered mode, perhaps you overload the DAC.

danielschramm9 · ‎2015-10-08

Posted on October 08, 2015 at 15:30

Hello,

your test approach does not help, I need ''high'' (min 10kHz) update rate. Reading without DMA and slow update rate does not show the effect, because the reading is slower than the effect I'm describing. I can also use only every 100th value and output it with 100 times slower sine and I get a ''clean'' reading, see image.

Test without signal generator, with

Potentiometer

was done - Same result.

I was asking for known side effects regarding the combination Timer1 + Sequencer + ADC3 + DMA.

By the way, I also tested without timer, using only continuous ADC with DMA it shows the same problem.

Also I did check if the sample rate is correct (Scope on Pin) and it shows low jitter, because DMA has the highest IRQ priority.

Daniel

AvaTar · ‎2015-10-08

Posted on October 08, 2015 at 15:39

> your test approach does not help, I need ''high'' (min 10kHz) update rate.

Perhaps because it implied a hardware issue, at least to me.

Neither do I have any F7 hardware, nor do I touch Cube stuff.

But since both ADC and DMA not new to STM32, I suspect a bug in your code, or the Cube generated code.

Perhaps someone else can chime in.

walworc · ‎2015-10-08

Posted on October 09, 2015 at 05:36

Hi,

I do not have F7 board, but I have F0 board; Take a close look at the Disco Schematic ... I saw strange results (Nucleo board) when I tried to read analog from pin with a Cap that debounced PC.13.

Further, I pulled-down the Analog I was reading with 100K ohm R, which cleared-up some (not all) of the offset. Try to increase the sample time, too. And check your clock ... use the ''jitter free'' variety described in the datasheet.

Second suggestion: Is it possible that your sample rate is 4.5hz? 😉

Sorry in advance for my poor 4.5hz joke.

And advise of success when you can.

-Chris

danielschramm9 · ‎2015-10-08

Posted on October 09, 2015 at 07:44

Hello Chris,

about the sample time, I tried all combinations of:

ADC_CLOCKPRESCALER_PCLK from DIV2 to DIV8;

And all

ADC_SAMPLETIME from 15CYCLES to 480 (12Bit variants)

Allways the same.

What about your jitter free variant? I cannot find this in the F7 Reference or Datasheet.

Sample Rate is really higher and only the data flow of the DMA Interrupt generates a new value in the display table.

Interesting also when I set breakpoints in the DMA IRQ, the raw data stays the same (no LSB jitter) for a lot of resumes. All channels always behave in the same way, if one changes, all change.

Reducing the channel count on the sequencer to 4 instead of 6 also does not change anything.

I will just try only one channel with the same code and send an update.

Thanks,

Daniel

danielschramm9 · ‎2015-10-09

Posted on October 09, 2015 at 10:53

Hello,

when I reduce the channel count to 1 and speed up ADC by shortest sampling time and highest ADC clock (25MHz) the results get better = shorter periods with stable value.

Reducing clock or increasing sampling time make makes it worse.

I'm just checking if the next sequence is trigegred before the DMA Interrupt flag is reset.

But it does not seem to be critical, since reducing the sampling period in the timer does not influence the stable parts. This indicates that the IRQ processing time is not critical.

Daniel

walworc · ‎2015-10-09

Posted on October 09, 2015 at 18:30

Hello, Daniel,

Re: STM32F030x Datasheet ''REFERENCE MANUAL'' (this is F0... not F7) On page 188 (of 771)

in document ''RM0360'' STM32F0xxx datasheet ( DocID025023 Rev 3) it states....

...

Table 35 Latency...Page 188...

1. Dedicated 15MHz clock... (jitter)

2. PCLK div 2... (NO JITTER)

3. PCLK div 4... (NO JITTER)

....

Consider finding F7 REFERENCE MANUAL and search for Jitter within ADC section.

Good luck.

Advise of success!

-Chris