STM32H7 Dual Core ADC/DMA "locking"

[Iris-DM]

I have a setup on a dual core STM32H755 device with each core measuring two ADC channels with shared pins at different sample rates. The M7 core measures ADC1 Ch15 and Ch5 at 1MHz@14bit, with a sampling time of 1.5cycles (20MHz ADC clock prescaled by 2 down to 10MHz) and the M4 core measures ADC2 Ch15 and Ch5 at 1kHz@16bit, with a sampling time of 64.5 cycles (ADC clock also prescaled down to 10MHz). Both of these are read by DMA, with 1024 samples captured at a time in the M7 and 250 samples captured at a time in the M4. 

I have a peak detection algorithm which looks for significant spikes in the captured window, and on the M4 core, this is occasionally triggered when no stimulus is applied. Looking at the window, it seems that the majority of the datapoints are "locked" at one particular value, with only a handful of values displaying any sort of randomness that would be associated with the signal I'm capturing. Simply put, there is no way that these are accurate readings.

Interestingly, the "lock value" always has the lowest 8 bits set - eg.

(23039) 0x59FF

(20991) 0x51FF

(22015) 0x55FF

(20479) 0x4FFF

 

I have checked the application notes and I'm below the maximum allowed ADC frequency and sample rate for the LQFP package, and I've also tested with the D-Cache both enabled and disabled (although this shouldn't affect the M4 core AFAIK).

 

Is there something I'm missing? This presents across multiple devices, so a defective IC has also been ruled out.

 

 

[mƎALLEm]

Hello,

Did you try to separate the ADC channels between M7 and M4? Do you see the same behavior?

[mƎALLEm]

Could it be something related to the charge of the internal capacitor during the sampling process?

See Figure 39 from AN2834

[Iris-DM]

I see this behaviour mainly on the M7 core, but I have seen it on the M4 as well - although I can't remember what the sampling time was set to at that point. It could well be down to the charge on the internal capacitor, I'll increase the sampling time as much as I can and see if that makes any difference.

[TDK]

Interesting.

If you stop the ADC on the M7 core, does this still happen? Can you show more data around the problematic points? 0x59FF is more than 12 bits.

Another test would be to set up an analog watchdog on the M4 and see if that's triggered. Probably it won't be, which means the memory is being written somewhere else. Or the memory is corrupted at a hardware, which seems very low probability.

Is it possible the memory is being overwritten by rogue code? Would be interesting to see if there is a pattern to the X values that these occur at.

 

[FBL]

Hello @Iris-DM 

Maybe because degradation is more visible on large LQFP packages.

[VO]

Hello, Iris-DM

I found your post while searching for a solution to a very similar application, and I wondered if you ever found a satisfactory solution and care to share it?

Also, I would very much like your thoughts on how to best manage the ADCs when both cores are given access to them; I *thought* that one core must control the DMA to the exclusion of the other, but it seems you have found a way to do it.

Any insights you might pass along will be greatly appreciated.