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

 

[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

[Amel NASRI]

Hi @mads_nielsen ,

Thanks for coming back to this discussion (while we generally prefer to start a new one).

In your case, are you using exactly the same product/package as Tomas?

As you are suspecting a quality issue, again I'll point to a FAE as we cannot handle FAR in the public community. It will be required to get the failing devices and make tests with them.

Thanks for your understanding. I'll try to follow on my side in case you submit a request on OLS.

-Amel

[waclawek.jan]

Mads,

Here I am not talking about merits/demerits of using libraries for normal firmware, but about producing a minimal, easily and surely reproducible example exhibiting he problem, for purposes of problem analysis.

But whatever; the key point is in providing a minimal but complete compilable example exhibiting the problem, together with concise description of used hardware (e.g. VDDA voltages may matter very much in this case). With libraries or without them. Even better in this case would be *both* source and binary.

> first step is for ST to acknowledge that there is a problem

Witnessed by Amel's posts above, they did acknowledge that, and performed an experiment at their side, concluding that there is no problem.

However, we don't know, what experiment did they perform, under what circumstances, etc. Would they publish a reproducible example code as I've wrote above, together with what was the hardware used - unfortunately in this case a standard Nucleo is not an option - you and Tomas could then try to reproduce that code at their side, and would that result in working case, you/he could then investigate and try to find differences between working and non-working cases. And the same applies to you and Tomas, would you/he provide that minimal but complete code/binary, then you could mutually verify your findings and potentially come to some conclusions.

That's because the details usually do matter.

JW

 

[EDIT]

> Main coincidence is the matching date and revision code

Any photo?

[Tomas Hamouz]

Hi @mads_nielsen 

I think you hit the nail. Unintended connection is not the first encountered (@waclawek.jan knows, bound timers). Thanks for investigation, it sounds reasonable.

In out project we finally made simpler circuit, without need of second OPAMP.

-Tomas