MSPM0G1107: Question regarding Errata ADC_ERR_06

Hi Siegfried,

In our internal testing, we found that this errata still affects the device across the operating voltage range, so your observations that the error disappears when operating at 3.3V would be something of an anomaly. 

The posted workarounds in the errata are the primary suggestions we have. Unfortunately the issue does cause jumps in the ADC reading during the conversion, so we need to work around it / resolve it in these devices my monitoring the results and checking if they are outside of the expected range, as mentioned in the errata.

In the near future we do not have a silicon revision planned for this device. We have released other devices that do have updated silicon and are not affected by this bug. If you would like, you could put your system requirements in a new post and if we have another device that fits we can recommend it to you. Otherwise you could take a look at all MSPM0 products and look for another one, then check the errata to see if it does not have the ADC_ERR_06 errata.

Hi Dylan,
thanks for your feedback. But still remaining questions. Obviously the different Power Supply is just an side effect, got it. 
But would it potentially help if we use the 10Bit conversion mode.
What always is feeling strange is the relation between sampling rate and sample time. 
We work with DMA, averaging, trigger source event and interrupt on DMA DONE. 
See attached config snippet.
But what I never understood are the settings in GUI relative to measured resulting sampling rate. 

When Power Down Mode is set to Auto, GUI calculates a sampling rate of 213,33kHz but physically it is approximately 100kHz.
And additionally the ADC doesn't start after a warm start of cpu. 

The ADC starts safely even after warm start when Power Down Mode is Manually.
ADC121.$name = "ADC12_0";
ADC121.samplingOperationMode = "sequence";
ADC121.configureDMA = true;
ADC121.subChanID = 1;
ADC121.repeatMode = true;
ADC121.trigSrc = "DL_ADC12_TRIG_SRC_EVENT";
ADC121.enabledInterrupts = ["DL_ADC12_INTERRUPT_DMA_DONE"];
ADC121.adcMem1chansel = "DL_ADC12_INPUT_CHAN_1";
ADC121.adcMem2chansel = "DL_ADC12_INPUT_CHAN_2";
ADC121.adcMem3chansel = "DL_ADC12_INPUT_CHAN_3";
ADC121.adcMem4chansel = "DL_ADC12_INPUT_CHAN_7";
ADC121.adcMem5chansel = "DL_ADC12_INPUT_CHAN_12";
ADC121.adcMem7chansel = "DL_ADC12_INPUT_CHAN_1";
ADC121.adcMem8chansel = "DL_ADC12_INPUT_CHAN_2";
ADC121.adcMem9chansel = "DL_ADC12_INPUT_CHAN_3";
ADC121.adcMem10chansel = "DL_ADC12_INPUT_CHAN_4";
ADC121.adcMem11chansel = "DL_ADC12_INPUT_CHAN_5";
ADC121.sampCnt = 3;
ADC121.endAdd = 5;
ADC121.sampleTime1 = "1 ms";
ADC121.interruptPriority = "1";
ADC121.enabledDMATriggers = ["DL_ADC12_DMA_MEM5_RESULT_LOADED"];
ADC121.enableFIFO = true;
ADC121.dataFormat = "DL_ADC12_SAMP_CONV_DATA_FORMAT_SIGNED";
ADC121.adcMem0vref = "VREF";
ADC121.adcMem1vref = "VREF";
ADC121.adcMem2vref = "VREF";
ADC121.adcMem3vref = "VREF";
ADC121.adcMem4vref = "VREF";
ADC121.adcMem5vref = "VREF";
ADC121.powerDownMode = "DL_ADC12_POWER_DOWN_MODE_MANUAL";
ADC121.adcMem4avgen = true;
ADC121.adcMem5avgen = true;
ADC121.adcMem3avgen = true;
ADC121.adcMem2avgen = true;
ADC121.adcMem1avgen = true;
ADC121.adcMem0avgen = true;
ADC121.hwNumerator = "DL_ADC12_HW_AVG_NUM_ACC_2";
ADC121.hwDenominator = "DL_ADC12_HW_AVG_DEN_DIV_BY_2";
ADC121.sampleTime0 = "155ns";
ADC121.peripheral.$assign = "ADC0";
ADC121.peripheral.adcPin0.$assign = "PA27";
ADC121.peripheral.adcPin1.$assign = "PA26";
ADC121.peripheral.adcPin2.$assign = "PA25";
ADC121.peripheral.adcPin3.$assign = "PA24";
ADC121.peripheral.adcPin7.$assign = "PA22";
ADC121.peripheral.adcPin12.$assign = "PA14";
ADC121.adcPin0Config.$name = "ti_driverlib_gpio_GPIOPinGeneric5";
ADC121.DMA_CHANNEL.addressMode = "f2b";
ADC121.DMA_CHANNEL.enableInterrupt = true;
ADC121.DMA_CHANNEL.enabledEvents = ["EVENT_CHANNEL"];
ADC121.DMA_CHANNEL.interruptPriority = "1";
ADC121.DMA_CHANNEL.$name = "DMA_CH2";
ADC121.DMA_CHANNEL.peripheral.$assign = "DMA_CH2";
ADC121.adcPin1Config.$name = "ti_driverlib_gpio_GPIOPinGeneric6";
ADC121.adcPin2Config.$name = "ti_driverlib_gpio_GPIOPinGeneric7";
ADC121.adcPin3Config.$name = "ti_driverlib_gpio_GPIOPinGeneric8";
ADC121.adcPin7Config.$name = "ti_driverlib_gpio_GPIOPinGeneric0";
ADC121.adcPin12Config.$name = "ti_driverlib_gpio_GPIOPinGeneric1";

The errata text does state that the behavior occurs in 12 bit mode, I need to check if this wording means that it does not occur in 10 bit mode. The language there could use some updating for clarity I think.

Is the above a full list of the peripherals you use? Because if you are only using these you could use another device, such as the MSPM0L1117, which is not affected by this errata. It also has an ADC that can meet the sampling rate you mentioned, it has DMA, event system. I encourage you to take a look at this.

How are you testing the actual ADC sample rate? And can you elaborate on "warm start"?

No this is just a important part of project, additionally we use two uarts, spi, and some i/o's.
The actual Samplerate is being tested over DMA Done IRQ connected to an I/O PIN.
After successfull transfer of the six samples. Warmstart means after power on do just an reset. 

Problem with ADC happens when power down mode ist on auto. When mode is manual warmstart is no problem. 
Sometimes even with auto the adc runs, but just sometimes ite seems to be a race condition or timing problem .
Like reset doesn't end power down mode.

One device that does not have the ADC_ERR_06 that does have an ADC capable of sampling up to 1.68Msps, 2 UARTS, one SPI, and up to 44 IOs (48 pins total), and DMA, so if you end up deciding to switch devices, you might want to look at the MSPM0L1117.

As for your warm start issue - does the device exhibit the same behavior when you tap the reset button vs hold it for more than one second? These two actions deliver different types of resets. Additionally, when the device will not send the data, are you able to reconnect the debugger to the target without resetting to check the state of the device? Then you could check to see if you got an NMI, hard fault, if your program counter has jumped somewhere unexpected, etc.

Regarding the ADC theme after an reset, it is independent of pressing reset button time. It happens just sometimes, the application itself is always running. But ADC Data is never refreshed. But this theme is for us, a minor theme as it works when not using auto_mode for power down. But perhaps our problem corresponds with ADC_ERR_05 of ERRATA from MSM0L1117. 
Real problem are the 0x800 datas. What about other mode than 12 bit?
Did you have an answer therfore?
MSPM0L1117 looks promising but we use actually two dma's for spi, one for ADC, two for UART. So minimum compromise would mean no DMA on UART'S as device has a maximum of 3 dma.
I will send you complete configuration. 
The MSPM0L111X Series does neither support MATHACL, nor higher frequencies than 32MHz?

ADC_ERR_05 is just saying that if an event trigger is asserted before the ADC is enabled, then it will be queued and executed when the ADC is enabled, so it does not sound like your issue is related to this.

Understood for your point about needing more DMA channels than the MSPM0L1117 has available. TO answer your other questions about this device: it does not support MATHACL, and the main clock cannot exceed 32MHz, so you are correct on both of your observations.

The ADC_ERR_06 occurs in the ADC whether in 12 bit or 10 bit mode. 

For your point about the warm start I would still like to get to the bottom of this - I see that if you use "manual power down" mode, the issue does not occur. This implies that your wake up source is not triggering when you warm-start the device, but it is working properly when you first flash the device? When the ADC is working, are you debugging the project, or letting it free run? Are you using a low power mode where the ADC would go to sleep and consequently not respond to triggers?

It works every time when directly flashed, in debug or release mode. ADC is sometimes not working when power down mode is in auto mode, when device is just reseted through button. When we power cycle or start from debugger it doesn't happen. For me it seems to be a trigger condition problem. Like a race condition. In debugger i saw the phenomen in debugger only after a restart of the application, not directly after flashing. We don't use any power switching features. The cpu is always running on 32MHz