STM32F405RG weird ADC spikes - Page 1
Forum section: electronics / general

author: syntax333
author_rank: Regular Contributor
timestamp: November 16, 2020, 01:13:16 pm
content: Hi I am working on a small project where I need to sample couple of ADC channels.I am using STM32F405RG. ADC1 is running in continuous and scan mode with DMA. I am using ping pong buffers to send ADC data through USART.After gathering some data I plot them in MATLAB.Problem is that there are random spikes in my ADC values an example is shown below.X axis is Seconds, Y axis is voltage. Graph belongs to an ADC channel where approximately 2.6 volts needs to be read.Has anyone encountered this ?EDIT:I am first storing ADC data in an external SPI FLASH. After getting certain amount of sample I dump data through USART.

author: Alti
author_rank: Frequent Contributor
timestamp: November 16, 2020, 01:17:55 pm
content: Do the same test with sampling internal temperature channel.

author: syntax333
author_rank: Regular Contributor
timestamp: November 16, 2020, 02:12:34 pm
content: Quote from: Alti on November 16, 2020, 01:17:55 pmI will try that and share results here.

author: Pack34
author_rank: Frequent Contributor
timestamp: November 16, 2020, 05:51:42 pm
content: I've seen issues like this that was related to ground noise caused by some switching power supplies. You're using the internal ADC on the chip? Have you looked at the reference voltage pin with a scope? Does it look solid and clean? What about the power being supplied to the STM32? Does the analog signal cross over/next to any higher voltage or switching signals? Broken ground planes?

author: syntax333
author_rank: Regular Contributor
timestamp: November 17, 2020, 04:37:21 am
content: Quote from: Pack34 on November 16, 2020, 05:51:42 pmI am using internal ADC on the chip. Yes, I scoped the Vref while board was sampling and everything was clean. Vref and my Vcc is connected trough a ferrite bead so Vcc was also clean. I have single ground plane and I was careful while routing Analog channels, the nearest digital signal to an analog signal route is on chip pins.

author: syntax333
author_rank: Regular Contributor
timestamp: November 17, 2020, 09:48:36 am
content: I am seeing spikes at 14Hz frequency as shown below image.

author: Yansi
author_rank: Super Contributor
timestamp: November 17, 2020, 09:52:01 am
content: To the OP: That is a design flaw in F2 and the older F4 (405, 407, 427, 429) devices. The ADC there is just.... not really worth a lot.Google for AN4073.What syntax333 posted does not seem to have anything in common with that and seems to be some fuckup somewhere else.

author: syntax333
author_rank: Regular Contributor
timestamp: November 19, 2020, 05:25:03 am
content: Quote from: Yansi on November 17, 2020, 09:52:01 amYou are talking about first post right?Quote from: Yansi on November 17, 2020, 09:52:01 amYou are talking about temperature sensor result post?

author: Yansi
author_rank: Super Contributor
timestamp: November 19, 2020, 08:47:00 am
content: Exactly.Look in the AN I have pointed at. The ADC gets some serious noise from the FLASH access circuitry. That usually result in these randomly crippled single mesurement values once in a while.What your temp sensor measures does not seem related any way, especially because it is highly periodic. Do you switch anything at that exact rate you are seeing in the signal?Also, make sure you sample the tempsensor with enough sample time, dead the datasheet. The tempsensor circuitry inside the MCU is obviously quite high impedance, you can sample it with just 1us.

author: syntax333
author_rank: Regular Contributor
timestamp: November 19, 2020, 03:19:56 pm
content: Quote from: Yansi on November 19, 2020, 08:47:00 amAN4073 says disabling prefetch results in better accuracy. However, reference manual statest that default state of Prefetch option bit is 0 which corresponds to disable.So if it was because of flash, wouldn't this bit be enabled?

author: Siwastaja
author_rank: Super Contributor
timestamp: November 19, 2020, 03:33:30 pm
content: Prefetch may be disabled at boot time, but standard use pattern is to enable it because otherwise the performance sucks beyond laughable. In this way, it's sensible to ask to "disable" it, although it's not a real solution because seldom you can cripple the performance of the M4 core you probably specified for a reason to begin with.Try running the code out of RAM to verify the assumption: the spikes should just go away. The Core Coupled Memory (CCM) doesn't have connection to the instruction bus so you can't place code there, sadly, but you can do the opposite: place at least the timing-critical variables (and possibly the stack) to the CCM, and instructions to the "normal" SRAM, so that instructions and data don't have to fight over the same memory bus. This way, I would guess, you'll get nearly the same performance than with those chips that come with separate instruction and data core coupled memories (F7 and H7 series, mostly, but F334 too, for example).

author: syntax333
author_rank: Regular Contributor
timestamp: November 19, 2020, 08:27:19 pm
content: Quote from: Siwastaja on November 19, 2020, 03:33:30 pmI will try your recommendations thank you. But my question is if these spikes were due to FLASH prefetch and at boot time prefetch is disabled (Also I do not enable it in my code), I shouldn't see these spikes right? I am kinda confused.

author: thm_w
author_rank: Super Contributor
timestamp: November 19, 2020, 10:16:23 pm
content: Quote from: syntax333 on November 19, 2020, 08:27:19 pmSo you are programming bare metal, no HAL or anything?Should be quick enough to fire up debugger, run your program, pause, then check the FLASH->ACR reg.

author: syntax333
author_rank: Regular Contributor
timestamp: November 20, 2020, 01:29:03 pm
content: Quote from: Siwastaja on November 19, 2020, 03:33:30 pmYes after HAL_Init(); prefetch is enabled.I do not know how to run the code from RAM. Can you give me some references?

author: Siwastaja
author_rank: Super Contributor
timestamp: November 20, 2020, 05:38:17 pm
content: Quote from: syntax333 on November 19, 2020, 08:27:19 pmEducated guess which might be wrong:It's not the prefetch per se, but reading the flash which causes the spikes. You would seeworsespikes with prefetch enabled. They recommend disabling prefetch as a way toreduce, not remove the problem.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 20, 2020, 05:46:13 pm
content: Quote from: syntax333 on November 20, 2020, 01:29:03 pmAre you using an IDE which autogenerates makefiles, linker scripts etc. for you? Or do you have access to the linker script?I do it this way (truncated key parts, by no way this is working complete code but hey, you asked for pointers!)linker script, basically copy-paste what you do for .data, but do it for .text:Code:MEMORY{ram(rwx) : ORIGIN = 0x24000000, LENGTH = 128Krom(rx) : ORIGIN = 0x08000000, LENGTH = 128K}SECTIONS{_TEXTI_BEGIN = LOADADDR(.text);.text :{_TEXT_BEGIN = .;*(.text)*(.text.*)*(.rodata)*(.rodata.*)_TEXT_END = .;} >ram AT>rom}startup, basically do the same thing you do for .data, but for .textCode:uint32_t* begin = (uint32_t*)&_TEXT_BEGIN;uint32_t* end = (uint32_t*)&_TEXT_END;uint32_t* i_begin = (uint32_t*)&_TEXTI_BEGIN;while(begin < end){*begin = *i_begin;begin++;i_begin++;}main(); // which should be in RAM now!

author: newbrain
author_rank: Super Contributor
timestamp: November 20, 2020, 06:32:23 pm
content: syntax333, may I ask how deep are the spikes? The top value is not visible in your second graph (and as soon as I saw the first I suspected it was hiding a lot).I find hard to believe that running from flash is the problem, given that:The spikes do not have any significant variance.They look much deeper than stated in the ANThey appear at regular intervals, (every 8 samples, it would seem from the second graph)So, I'd rather make sure that there isn't any problem with the code, in the DMA setup or data transfer, before you start the hunting of the snark.

author: Yansi
author_rank: Super Contributor
timestamp: November 20, 2020, 07:00:50 pm
content: You can believe what you want, but the AN will of course show the best out of the worst. So considering the MCU is not on any kind of decent layout PCB with clean filtered power supply voltages and very well executed supply decoupling, you can't expect anything close to the claimed performance.Given there are significant differences in between package parasitic inductances... it is like comparing pears and applesPS: Nucleo or discovery boards are nowhere close to what a decent layout should look like.

author: newbrain
author_rank: Super Contributor
timestamp: November 20, 2020, 10:18:26 pm
content: Quote from: Yansi on November 20, 2020, 07:00:50 pmWhat are you on about?I just confirmed what you said some posts above.Before trying to mitigate the noise, they should really make sure that there is not, in your words, "some fuckup somewhere else."Quote from: Yansi on November 19, 2020, 08:47:00 amQuote from: Yansi on November 17, 2020, 09:52:01 am

author: Yansi
author_rank: Super Contributor
timestamp: November 20, 2020, 10:54:01 pm
content: I reacted to your "hard to believe" noise comes from FLASH.However, it is impossible to hold in my head, we are solving two different issues from two different people at the same time. Sorry, my bad.

author: syntax333
author_rank: Regular Contributor
timestamp: November 21, 2020, 03:34:03 pm
content: Quote from: Siwastaja on November 20, 2020, 05:46:13 pmI am using STM32CubeIDE.Quote from: newbrain on November 20, 2020, 06:32:23 pmSecond graph does not show my problem. Its shows internal temp sensor and problem is probably due to sampling time is not matched with what datasheet says.In my original post the spikes goes 0.2V lower than my expected value. Its interesting the spikes are always -0.2Vnot +0.2V.Also spikes in my original post does not have a regular interval they are random. Sometimes it converts the ADC data right for 500 samples without a spike, sometimes there are 4 spikes in a row with right data between them.

author: syntax333
author_rank: Regular Contributor
timestamp: November 23, 2020, 12:14:00 pm
content: I think I found the problem. My main algorithm was:1) Sample chunk of ADC data2) Write it to SPI FLASH3) When Read command is send from USART dump the SPI FLASH data to PC through USART.I realized spikes are always approximately 0.2-0.15V which corresponds to 8bits when Vref=3.3V.Today I wrote a small code where it samples ADC data and dumps it directly trough USART without saving it to FLASH.After I plotted the data, I realized there was no spikes in the data. Which means the problem is SPI FLASH. 0.2V less means, 8bit of lower half of 12bit ADC data is 0x00.For Example: instead of 0x09BA I probably get 0x0900 thus results in 2304(1.85V) instead 2490(2V).Now I have to find why SPI FLASH sometimes reads 0x00 and sometimes corrupts data.Anyone have an idea? How can I make the reads from flash more reliable?The SPI FLASH I am using is MT25QL01GBBB.

author: newbrain
author_rank: Super Contributor
timestamp: November 23, 2020, 12:33:29 pm
content: I did not write anything more, as I was not able to reproduce anything similar to your findings with a STM32F4 DISCO board (F407, not F405) but wanted to try a couple of other things (e.g. alternating the temperature channel with a noisy other input).So, as expected, the problem lies elsewhere.Now, the troubleshooting target moves to the SPI flash handling, a completely different can of worms.- SPI mode, CS use and delays, SPI clock frequency are the first things to check.- Signal integrity: are the SPI signals of good quality?- Algorithm: is the SPI flash command and data sequences correct?- Code: is the correct data written to the flash? and is the data retrieved put in the right place?- etc. etc.

author: julian1
author_rank: Frequent Contributor
timestamp: November 23, 2020, 08:32:30 pm
content: QuoteNot saying it is the source of issues. But most schematics I see for stm32f4 - use RC or FBC as conditioning for both VDDA and VREF.

author: syntax333
author_rank: Regular Contributor
timestamp: December 01, 2020, 08:21:10 am
content: I found the problem. Processing large amount of data in MATLAB was bad idea. The code I wrote process 128MB of data. Somewhere in my code data is getting corrupted I don't know why.Now, I process the data in little chunks which results in correct output. Thank you all

author: mbless
author_rank: Regular Contributor
timestamp: December 02, 2020, 06:40:59 pm
content: Quote from: syntax333 on December 01, 2020, 08:21:10 amI do image processing of~200MB images with several loaded in RAM at once. MATLAB is not the issue.

author: thm_w
author_rank: Super Contributor
timestamp: December 02, 2020, 09:26:22 pm
content: Quote from: mbless on December 02, 2020, 06:40:59 pmProbably some off-by-one, buffer overflow, or similar coding error.