The monitored data with "spike"

[yang2]

Dear Sir,

When I monitor the data, sometimes the value often accompanied by spikes, such as followed figure.

In my case, I monitor 3 variables that update from ADC registers.

Normally, their values would be around 0.

The signals of ADCvalue[0] and ADC Value[1] appear to be normal.

However ADCValue[2] has some spikes.

When I verify the variables byIDE, the variable does not show these spikes. It always remains around 0.

And I also used a conditional statement to check: if the value is greater than 50 (the maximum spike value is around 260), a counter would increment. However, the counter has always remained at 0, so I believe the actual variable does not have these spikes.

What could be the possible reasons for this?

Best Regards,

[yang2]

Additionally, if I add monitoring of other values, there is a chance that the data will return to normal.

For example, as shown in the image, I added two more monitoring variables, offset[0] and offset[1].

At this point, ADCvalue[2] returned to normal.

[TDK]

The spikes are about 256 off of the real value. It's a int16_t value which is sometimes positive, sometimes negative.

I would guess that whatever is reading the value is doing so one byte at a time rather than both bytes at once, which causes the issue. For example, if you read the first byte when the value is -1, and the second byte when it changes to 1, the reading will be around -256.

How to fix? Not sure. Perhaps change the acquisition mode or add a trigger such that it doesn't probe the value when they're being updated.

[Billy OWEN]

Hi @yang2 

This post has been escalated to the ST Online Support Team for additional assistance.  We'll contact you directly.

Regards,

Billy

[yang2]

Hello TDK, 

I think what you said makes a lot of sense. It might really be caused by the fact that it's transmitted as two separate bytes. Thank you for sharing your opinion.

[KhPaul]

I have the same issue and it's really anoing, when you are monitoring low range signals

[Richard.Chvr]

Hello

As stated by @TDK, changing the acquisition mode to avoid reading the value when it is being updated may solve the issue. 
What is the acquisition frequency? Could be also a good idea to tune it according to the variable update frequency.

STM32CubeMonitor adapts the reading size to the type of the variable to monitor, i.e reads 2 bytes at a time for a int16, 4 for a int32, etc... When your read 3 int16 type adjacent variables, as in you example, cubemonitor reads 8 bytes at a time. The read procedure is not the same as the one used for a int16 variable reading, that may explain why it works in that case as the reading delay is longer, the ADCvalue[2] update occurs in between each read process.