How to read additional ADC channel in Motor Control MC SDK 5.4.4 (STSPIN32F0601)?

[GenuineDeveloper]

I am using MC SDK 5.4.4 to drive a PMSM motor using STSPIN32F0601. Now, I want to add a potentiometer to my system to sense different user selectable levels. Generally, in other appplications we can intialize the ADC and read the ADC converted values as and when required. But after referring the documentation I found regular_conversion_manager (RCM) to use the ADC channels. I am using an ADC channel other the ones assigned for phase current sensing, voltage bus sensing, temperature sensing. How do I go about to read an ADC channel in this case?

[cedric H]

Hello RV,

You can find a potentiometer example with the Regular conversion manager among the "Example Projects" at the first Motor Control Workbench window.

The following code is extract from the example "Speed ramp with Potentiometer on P-NUCLEO-IHM001 kit"

In order to use the regular_conversion_manager API you need first to include the following header file :

#include "regular_conversion_manager.h"

RegConv_t PotentiometerConv;

uint8_t PotentiometerHandle;

PotentiometerConv.regADC = ADC1 ; /* to be modify to match your ADC */

 PotentiometerConv.channel = ADC_CHANNEL_12;/* to be modify to match your ADC channel */

 PotentiometerConv.samplingTime = ADC_SAMPLETIME_61CYCLES_5; /* to be modify to match your sampling time */

 PotentiometerHandle = RCM_RegisterRegConv (&PotentiometerConv);

In order to start a regular conversion, you need to be sure that no Regular conversion is ongoing :

 if (RCM_GetUserConvState() == RCM_USERCONV_IDLE)

    {

     /* if Idle, then program a new conversion request */

     RCM_RequestUserConv(PotentiometerHandle );

    }

    else if (RCM_GetUserConvState() == RCM_USERCONV_EOC)

    {

     /* if Done, then read the captured value */

     potentiometer_value = RCM_GetUserConv();

    }

Hope it helps

Regards

Cedric

[GMaud]

I did exactly what is decribed above and it worked at first sight, but when observing the

ADC result it is correct most of the time and sometimes a wrong value comes from the ADC.

I checked with a controled DC voltage and this is repeatable.

It looks as if sometimes this method returns the data from the wrong ADC channel.

Since I have no control over this method, is there a fix for this/altyernative method

for reading out an ADC?

[cedric H]

Hello GMaud,

Could you describe your configuration :

What is your MCU ?

Which MCSDK version do you use ?

How many ADC handler do you need ?

For your information, you have access to these methods. They are in regular_conversion_manager.c file

Regards

Cedric

[GMaud]

Hi, I use the STSPIN32F0

MCSDK is MCSDK_v5.3.2

I need 1 ADC channel

I use the proposed method and even added a filter to mask the intermittend wrong data.

let me know how this can be resolved,

Thank you,

G

   // update potentiometer from ADC

   if ((RCM_GetUserConvState() == RCM_USERCONV_IDLE))

   {

      // request ADC measurement from potentiometer

      RCM_RequestUserConv(Potentiometer_Handle);     

   }

   else if((RCM_GetUserConvState() == RCM_USERCONV_EOC))

   {

      // we now have the results of the potentiometer setting

      dumval = RCM_GetUserConv();

      if (dumval > 9039)

      {

         dumval = 9039;

      }

      Potentiometer_raw = (uint16_t)((dumval*29)>>2);

      PotentiometerFiltAcc = K_VoltFilter * Potentiometer_raw;

      Potentiometer = Potentiometer_raw;      

   }   

void PotentiometerMetingInit(void)

{

   Potentiometer_Conv.regADC            = ADC1;

   Potentiometer_Conv.channel         = ADC_CHANNEL_3;

   Potentiometer_Conv.samplingTime   = ADC_SAMPLETIME_7CYCLES_5; //ADC_SAMPLETIME_239CYCLES_5

   Potentiometer_Handle                  = RCM_RegisterRegConv(&Potentiometer_Conv);   

}

[cedric H]

Your configuration does not match a known issue on our side (at least with the SDK 5.4.4 version)

We have a fix pending that it is worth to test anyway. Let me know if it solves your issue.

In regular_conversion_manager Line 559 :

Replace :

void RCM_ReadOngoingConv (void)
{
 if ( RCM_NoInj_array [RCM_currentHandle].status == ongoing )
 {

By:

void RCM_ReadOngoingConv (void)
 
{
 
 if ( RCM_NoInj_array [RCM_currentHandle].status == ongoing &&
 LL_ADC_IsActiveFlag_EOC( RCM_handle_array[RCM_currentHandle]->regADC ))
 {

Could you detail why do you think the ADC reading is wrong ? What is the value read when you identify it as wrong ?

Are you sure it does not come from parasitic on the board ? Did you put a scope at the ADC pin entry ?

Probability is high than ADC_SAMPLETIME_7CYCLES_5 is not big enough. Could you give me the characteristics of your potentiometer ?

Are you using a ST board or your own one ?

Regards

[GMaud]

Hi Cedric,

I used the longer sampling time at the start, but due to the issues, I made it shorter, hoping that this would fix the issue.

So I have the issue with both short and long sampling times.

This behaviour is visible on both the evalboard and on my custom board.

There is no noise on the ADC pin, I verified this on scope and have good ground.

I also tested this with a solid DC voltage on the ADC input.

The ADC 'glitches'are also there with motor on and motor running.

I implemented the change you suggest but with this change, the ADC result is coming in very rare,

so rare that it can not be used at all.

Is the default motor control using PA3 for other functions? There is so much happening in the background that I wonder if this is causing the issue.

[cedric H]

Hello G,

> Is the default motor control using PA3 for other functions? 

Wait a second !

Did you use cubeMx in order to configure the PA3 pin to use the ADC1 Channel 3 first ?

(I guess no otherwise you will see if the pin is free or not ....)

If not, this is actually the first step to do. Open your ioc file generated in your project folder with cubeMX and configure your pin.

From cubeMX you can re-generate your project, you must have your pin properly configure in the generated stm32f0xx_hal_msp.c file.

The utilisation of the RCM API can work only if the pin is properly configured.

If after this step you want to change motor parameters for instance, you can go back in the MC Workbench and click on update button - It will keep the configuration of your PA3 pin (Update button rewrite only the Motorcontrol parameters )

Could you give me the reference of the evalboard you use, I will try to reproduce.

Regards

Cedric

[GMaud]

Hi Cedric,

Let me see if this is an option. I started with the CubeMX generated project at the very beginning but meanwhile a lot

of custom code has been added. This is a Brushless / Brushed controller where I can select between brushed and brushless.

So re-generating from cubeMx might cuase a lot of issues with the various adaptations.

Let me start a fresh project from CubeMX with target my board and the ADC on PA3 and let me verify if this ADC

works without glitches. This would give a better idea what is causing this. I use both my custom board and the STSPIN3202.

[cedric H]

On my side I will develop a potentimeter example with STSPIN3202, to try to reproduce.

For your information, few examples exist with a potentiometer. Even if you do not have the same board it is worth to test one of them and look at the IOC and the generated code.

Of course, configuring the pin through cubeMX is not a hard requirement. you can always write the generated code yourself.

Last point, if you have custom code, do not forget to write it inside the user section comments. Doing this your code will be kept at the next generation.

If a user section does not exist where you need, adding it yourself will NOT help. (It has to be added in the template file).

[cedric H]

Hello G,

I did the test with an STSPIN3202 without issue.

I tested both, with the proposed fixed (that should not change anything in your config) and without the fix.

In both cases I did not observe any wrong values read at the ADC. (without touching the potentiometer, the value read does not not vary more than 2.6% ).

You mentioned that applying the patch reduce the occurrence of the reading. That's make me wonder in which context did you execute the additional code ?

It should be in the main while loop. Not under interrupt.

Regards

Cedric

[GMaud]

Hi ST Support,

I moved to the latest MWB version 5.4.4. Tested the ADC in standalone mode (no motor running) and then also with motor drive features active.

The MWB 5.4.4 framework resulted in better ADC BUT still not a stable ADC result.

With a fixed volatge on the input and correct sampling times I get 0x0080 noise values.

I verified the schematics and measured the voltages and seems like I found the cause.

The VDDA receives its voltage from the SW output. The SW output has a coil and capacitor, but the output has a 3V3 level with sawtooth

on top of it. This is fed into the VDDA so the analog voltage reference is very noisy! The sawtooth noise is 120mV.

This is the STSPIN3202 evalboard based design and also follows the STSPIN datasheet.

But if I look at the STM32F31 datasheet, I would rather use a ferrite followed by a 1uF and 100nF capacitor at the VDDA input (DocID025743 Rev 6 37/106).

The main question now is:

Does it make sense to put a ferrite followed by 1uF + 10nF to feed the VDDA?

On a normal CPU this would fix the noise issue on the ADC.

BUT I am not sure if this will work on STSPIN32. In the datasheet it looks as if the internal DCDC looks at the VDDA level to regulate the switching. So

filtering the VDDA might result in DCDC issues.

Can you confirm that filtering the VDDA will work on STSPIN32?

[Cristiana SCARAMEL]

Hello @GMaud​,

as you can see in the STSPIN32F0A datasheet, the VDDA pin is the feedback of the DCDC regulator, so it is not possible to filter it.

I can suggest two options:

1. to use the MCU internal reference to compensate ripple on VDDA voltage
2. do not use the internal DCDC regulator and provide externally the 3.3 V supply voltage directly on the VDDA pin (refer to section 6.2.1 in the datasheet).

Please, next time open a new topic to ask new questions to help the Community members who might have similar concern.

If you want to refer to an old post you can add the link in the text ;)