MX 6.5, IDE 1.9 ADC offset bug. On stm32H743VIT

[SeyyedMohammad]

We can't set offset higher than 2^15. But we need higher, in case of using oversamplin without using OVSS or right bit shifting. I've tested for 64x OVS without OVSS we need 0x200000 offset. (left aligned 16-bit signed according to RM).

Really there is no way to report MX and IDE bugs? will anyone report this? Could we expect to these bugs be vanishing?

Please report the bug to the team.

[Amel NASRI]

Hi @SeyyedMohammad​ ,

What you did is the right way to report an STM32 related issue: ask your question here at ST Community.

And in order to increase the chance to get an answer quicker, it is recommended to add relevant topics (tags) like STM32CubeMX.

To deeply analyze your case, I add @Sara BEN HADJ YAHYA​  in the loop.

Sharing an .ioc file will be of a great help to reproduce the issue easily.

-Amel

[SeyyedMohammad]

Thx NASRI,

There is no procedure in reproducing that. This is just the limitation of offset which is set to 65535.

But in my case according to Reference manual I've needed 0x20000 offset to create left aligned x64 oversampled, zero-DC output from ADC, inspired by the last line of picture below.

Thanks again kindly.

[Sara BEN HADJ YAHYA]

Hello @SeyyedMohammad​ ,

Thanks for your feedback,

Actually it is not possible to reach the value 0x20000. The Offset maximum value is 0xFFFF and it depends on the ADC resolution.

  uint32_t Offset;                 /*!< Define the offset to be subtracted from the raw converted data.
                                        Offset value must be a positive number.
                                        Depending of ADC resolution selected (16, 14, 12, 10, 8 bits), this parameter must be a number between Min_Data = 0x0000 and Max_Data = 0xFFFF,
                                        0x3FFF, 0xFFF, 0x3FF or 0xFF respectively.

This info is also mentioned in RM0455 page 966.

I hope this helps 😊

If your issue is solved, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly 🙂

Sara.

[SeyyedMohammad]

Hi @Sara BEN HADJ YAHYA​ 

If you do not use oversampling your are right.

But after oversampling the offset will be subtracted before righ shift for oversampling.

Then 0xFFFF is not sufficient.

Actually in my program I am exactly using 0x8A0000 for 256x oversampling, approxiamately, I'm not remembering exact.

Note: after oversampling bit's exceed defined resolution and can be as large as 26bit then FFFF is just for 16bit.

Solution manual:

The offset correction is also supported in oversampling mode. For the oversampling mode, offset is subtracted before OVSS right shift applied.

[SeyyedMohammad]

Hi again Sara,

Does I've explained unclear? It's really a problem. Could you please report it? Thank you so much.

Exactly now I'm using 0x8ba000 and other number than this will cause a problem in my case with 256x oversampling.

[Amel NASRI]

Hi @SeyyedMohammad​ 

I double checked your explanation as well as the reference manual, generated code and ADC driver.

On my side, I agree with you that the maximum allowed value of the offset in the particular case of oversampling shouldn't be 0xFFFF but (3FFFFFF = 0xFFFF * 1024 where 1024 is the maximum oversampling ratio).

If you use an offset value greater than 65535 with oversampling, it will be managed properly in the ADC driver and precisely in HAL_ADC_ConfigChannel:

  /* Check offset range according to oversampling setting */
  if (hadc->Init.OversamplingMode == ENABLE)
  {
    assert_param(IS_ADC_RANGE(ADC_GET_RESOLUTION(hadc), sConfig->Offset / (hadc->Init.Oversampling.Ratio + 1U)));
  }

A deeper review will be done by STM32CubeMX Experts in order to take relevant corrective action for the particular case of oversampling.

This is tracked in Internal ticket number: 129596 (This is an internal tracking number and is not accessible or usable by customers).

-Amel

[Sara BEN HADJ YAHYA · Accepted solution]

Hello @SeyyedMohammad​ ,

This issue is fixed in STM32CubeMX latest release.

V6.7.0 is now available under this Link.

Thanks for your contribution 😊

Sara.

[SeyyedMohammad]

Hello @Sara BEN HADJ YAHYA​ 

Thanks for your appreciation, but I wonder why there is no clue about this problem on the cubeMX release note?

Why the bugs reported before, about MDMA, looplisting continually requre cube to generate code and MDMA node definition declaration requires __atrribute__ (align(8)) to work, are not listed in cubeMX, known limitations section of release note? This really will help the new users to save their time. (Sorry for not linking bugs reports, since they're removed from my account(*))

Thanks for your patient and your products, which all of them are the best!

Post edited by Moderation Team to adhere to community guidelines.

[Piranha]

Your topics are not removed. A "master of science" should be capable of opening the profile and setting the "Time Frame" combo-box appropriately.

> Why the bugs reported before ... are not listed in ... known limitations section of release note?

Imagine them listing network issues and all of the million other issues... That would be the same as admitting the truth and writing: "We are completely incompetent fools and because of that the HAL/Cube is a broken bloatware."