Posted on August 14, 2012 at 18:38This issue has been a thorn in my side for several days now, so I figured I would post the problem in case it ever affects others.
I've been developing some code that interacts with the Standard Peripherals Library in a board-generic way. This means that in some cases, things like clock initialization or the setting of bits was done redundantly. Generally, this is no problem except for wasted time and effort. In this case though, it was discovered that setting the TSVREFE bit twice causes an error in how DMA interacts with the ADC unit.
An example of this can be run using the example code included with the Standard Peripheral Library.
Using the ADC_RegSimul_DualMode example, run the code until the ADC_SoftwareStartConv() command. If viewed, the value ADC_DualConvertedValueTab at all indices will be zero as expected.
If an additional call of ADC_TempSensorVrefintCmd() is made (or the bit is just manually set a second time without first being reset) and the code is again run to the ADC_SoftwareStartConv() the values of the indices of ADC_DualConvertedValueTab will not be zero and will already have junk stored in them via DMA.
I recognize that setting a control bit twice is not intended behavior, but it doesn't seem like it should (and is not documented to) have any affect on the functioning of the DMA or ADC.
Screenshots of the values have been attached to this post.
For repeatability purposes, I was using the IAR Environment along with the STM32F103ZE-SK IAR Kickstarter Kit when the error was discovered, and I have _not_ tested on other STM32 MCUs.
#stm32f103xe-adc-dma-tsvrefe
