cancel
Showing results for 
Search instead for 
Did you mean: 

Occasional invalid ADC1 data Regular Simultaneous Mode on only some STM32L476 chips.

Hamid.Wasti
Associate II

I am using STM32L476, running on MSI @ 16MHz, with MR Range 1 and 3.3V supply voltage. The problems described below are happening at room temperature. The processor is running Bare Metal.

The ADC1 and ADC2 are configured in Regular Simultaneous Mode (DUAL[4:0] = 00110) with MDMA mode for 12 bits and clocked at HCLK/2 (CKMODE[1:0] = 10).

The ADC is triggered using TMR3 and 16 samples are captured on each channel using DMA from the CDR (Common Data Register). The sample time is identical on all input channels.

Every 250 millisecond, the code sets up the DMA to transfer 16 words of 32 bits each from the CDR to a memory location, sets the DMAEN bit, sets ADCEN bit for ADC1 and ADC2 (in that order) then starts TMR3, which eventually triggers the ADC some time later. The data is processed in the DMA Transfer Complete interrupt. The DMA interrupt does write to the ADC at all.

From the time TMR3 is started till the DMA interrupt happens, the processor is in Sleep mode.

We have built a couple of thousand boards. In all but about 10 systems, this works perfectly and several systems have been running non-stop for 1000+ hours without an issue.

In the few problem systems, we are occasionally receiving dad data. Investigating, it appears that once in a several thousand times, every single of the 16 sample from ADC1 is 0x0800. At the same time, the ADC2 data is valid, containing various different values that are reasonable. The next time the ADCs are run, the data for both ADC1 and ADC2 is reasonable.

This is something internal to the ADC1. We can be certain that ADC1 is NOT capturing the actual data on the GPIO pins when it reports a value of 0x0800 because it is not physically possible for several different external sensors to all of a sudden present EXACTLY 1.65V on several different GPIOs only to revert back to their original values a few hundred milliseconds later, while other related sensors connected to ADC2 retain their correct values.

Any ideas what might cause ADC1 to report 0x0800 on 16 consecutive samples, while ADC2 samples valid data? And for this problem to be transient, so the next time the ADCs are run, everything works perfectly. And for this to happen on only a small percentage of the chips?

Regards,

Hamid

0 REPLIES 0