STM32U575QII Dedicated OPAMP2_VINM pin not connected?

[Tomas Hamouz]

I have a project which uses both OPAMPs. For both OA I use dedicated VINM pin.

OPAMP1 works correctly.

OPAMP2 behaves like the dedicated pin (M2 ball) is not connected to the input multiplexer.

I 've tried

 - mode FOLLOWER: OK

 - mode STANDALONE, reconnected the signal on the board and used PA7 for VINM: OK

 - mode STANDALONE, using the dedicated pin: the output is saturated at VDDA.

Checked the PCB connection, OK. Checked on 3 boards, identical results.

Is it possible it is really a bug in the silicon? What else should I check?

(I would like to use OPAMP tag, but it is not available :(  )

Initialization code:

(GPIO to analog)

LL_APB3_GRP1_EnableClock(LL_APB3_GRP1_PERIPH_OPAMP);

LL_OPAMP_InitTypeDef OPAMP_Init;

OPAMP_Init.PowerMode = LL_OPAMP_POWERMODE_NORMALPOWER_NORMALSPEED;
OPAMP_Init.FunctionalMode = LL_OPAMP_MODE_STANDALONE;
OPAMP_Init.InputNonInverting = LL_OPAMP_INPUT_NONINVERT_IO0;
OPAMP_Init.InputInverting = LL_OPAMP_INPUT_INVERT_IO1;
LL_OPAMP_Init(OPAMP2, &OPAMP_Init);

LL_OPAMP_Enable(OPAMP2);

[Amel NASRI]

Hi @Tomas Hamouz ,

Sorry to come back late to this question.

Do you still face an issue or you succeed to find a solution? That would be interesting to share the status.

In case you continue the investigation, could you please:

• share the revision of the used devices
• read the value of the bit field VM_SEL in both OPAMP1_CSR and OPAMP2_CSR

-Amel

[Tomas Hamouz]

Hi @Amel NASRI ,

Silicon revison is W, see attached picture, all devices the same. See also the snapshot of OPAMP registers from debugger.

Tomas

 

 

[Amel NASRI]

Hi @Tomas Hamouz ,

Thanks for sharing these details.

Our expert made a test with a BGA169 package and OPAMP2_VINM is working properly for both modes STANDALONE & FOLLOWER.

We will try to continue investigation using a BGA132 (as it is the case for you) and will come back to you.

-Amel

[Amel NASRI]

Hi @Tomas Hamouz ,

I come back to you to confirm that internal tests were performed by our team with BGA132 package.

Both OPAMP1 & OPAMP2 are configured in standalone mode with dedicated VINM pin configured and the work properly.

At this level, I recommend you to review your hardware setup. If the problem is still there, could you please share the used firmware? It may be interesting also to share your schematic.

-Amel

[Tomas Hamouz]

Hi @Amel NASRI ,

Thanks for investigation, the problem persists. See the attached snippets of code, principal schematic, a cut from real board routing and X-rayed board, confirming there is not bad connection under the M2 ball.

Summary:

 - when compiled with #define TEST_FOLLOWER_ONLY, it works.

- when compiled without TEST_FOLLOWER_ONLY, the OPAMP is saturated to Vdda

- when OPAMP_VINM reconnected to PA7 and source code changed (see commented out line), it works.

When saturated, the pads 1 (C3, R32) have Vdd/2, pads 2 have VDDA.

Snippet of code here, max 3 attachments :(

Tomas

//-----------------------------------------------------------------------------
/// OPAMP Initialization
void CWetContacts::InitOpAmp(void)
//-----------------------------------------------------------------------------
{
LL_APB3_GRP1_EnableClock(LL_APB3_GRP1_PERIPH_OPAMP);

// GPIO setup
LL_GPIO_InitTypeDef GPIO_InitStruct;

// minus need not setup, BGA132 has dedicated pin
// plus PA6
// output PB0
GPIO_InitStruct.Pin = WET_OPAMP_INP_PLUS_PIN;
GPIO_InitStruct.Mode = LL_GPIO_MODE_ANALOG;
GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
LL_GPIO_Init(WET_OPAMP_INP_PLUS_PORT, &GPIO_InitStruct);

GPIO_InitStruct.Pin = WET_OPAMP_OUT_PIN;
LL_GPIO_Init(WET_OPAMP_OUT_PORT, &GPIO_InitStruct);

// configuration of OPAMP
LL_OPAMP_InitTypeDef OPAMP_Init;
LL_OPAMP_StructInit(&OPAMP_Init);

OPAMP_Init.PowerMode = LL_OPAMP_POWERMODE_NORMALPOWER_NORMALSPEED;
OPAMP_Init.InputNonInverting = LL_OPAMP_INPUT_NONINVERT_IO0; // std gpio pin

#if defined(TEST_FOLLOWER_ONLY)
OPAMP_Init.FunctionalMode = LL_OPAMP_MODE_FOLLOWER;
OPAMP_Init.InputInverting = LL_OPAMP_INPUT_INVERT_CONNECT_NO; // minus need not connection
#else // !defined(TEST_FOLLOWER_ONLY)
OPAMP_Init.FunctionalMode = LL_OPAMP_MODE_STANDALONE; // amplification by external circuit
OPAMP_Init.InputInverting = LL_OPAMP_INPUT_INVERT_IO1; // dedicated pin
// OPAMP_Init.InputInverting = LL_OPAMP_INPUT_INVERT_IO0; // test alternate pin PA7
#endif // !defined(TEST_FOLLOWER_ONLY)
LL_OPAMP_Init(WET_OPAMP_DEVICE, &OPAMP_Init);

LL_OPAMP_Enable(WET_OPAMP_DEVICE);
} // InitOpAmp

   

[Amel NASRI]

Hello @Tomas Hamouz ,

No weird setup based on what you shared.

What I suggest at this level is to contact your FAE who can make checks with your hardware to reproduce issue and go farther with the analysis. Please let me know if you opt for this.

-Amel

[mads_nielsen]

Hello @Amel NASRI 

I know this is an old post, but strange enough, I see the exact same problem with OPAMP2 when using VINM in our design. We have run a previous board, where we used OPAMP1 and it was working and now switched to OPAMP2 where it doesn't work. I have gone through the exact same discoveries as Thomas, with setting up the opamp in different modes, which works until VINM is to be used. Fun fact is that our MCU is the exact same with exact matching date code and revision code.

So ST, are you sure that everything is OK with this MCU?

-Mads

[waclawek.jan]

Isn't it relatively simple to write an absolutely minimal but complete compilable code, with default clocks etc., pure direct writes to registers (it's just a handful of them needed; point is to remove uncertainties stemming from using any library code outside CMSIS-mandated device header), reproducing the problem? For both ST and users, so that they then can exchange them and reproduce it at their side, potentially revealing the soruce of the problem (e.g. incorrectly removed isolation switches, differences in booster setting, sequencing issues, etc.)

JW

[mads_nielsen]

JW

Yes, and no. In an ideal world, it is just a matter of firmware, in the real world, it depends. Tomas just put it right there, switching between the dedicated WINM pin and PA7 makes a difference, on his board. By using the LL driver he is using direct register writes, there is no bloat in these driver regarding the opamp setup. Is it "correct" top use these drivers, we can argue about this the whole day, but it doesn't change the outcome of his test. So what more do you want from him?

In my case, we switched from using OPAMP1 to OPAMP2, one line of code for writing to either OPAMP1_CSR or OPAMP2_CSR for setting up the required behaviour. Revision with OPAMP1 works all day long, with OPAMP2 no luck. Main coincidence is the matching date and revision code whit Tomas, and as long ST haven't tested on matching MCU, everything is in the open. We have been down this road before in other occasions, seldom it is a firmware problem, and first step is for ST to acknowledge that there is a problem, and they need to take it seriously instead of pointing to a FAE to handle the problem. Until then, everything is just noise.

-Mads