Is it possible to implement a peripheral on-the-fly?

[RobGeografo]

Hi everyone,

I am using a STM32G474VETx chip and I have an issue with two peripherals being in conflict.

I need to use the OPAMP1 input pin (PA1) for current sensing purposes. The OPAMP1 mode required is "PGA not connected" which automatically configures pin PA2 as OPAMP1_VOUT. On the other hand, I need to use LPUART1 peripheral with TX at PA2 and RX at PA3. Unfortunately, I don't have other pins available to remap one of these peripheral to.

Is it possible to pre-configure one of the 2 peripherals on the .ioc configuration file and force-enabling the other peripheral in software at runtime? If so, what steps do I need to take to achieve that?

NOTE: I am also using ChibiOS, in case it can also be done using its API.

Thanks,

Rob

[TDK]

> Is it possible to pre-configure one of the 2 peripherals on the .ioc configuration file and force-enabling the other peripheral in software at runtime? If so, what steps do I need to take to achieve that?

Yes. You will need to deinitialize the first peripheral, then initialize the second one to start using it. Initializing involves configuring pins, enabling the clock, and configuring the peripheral. And obviously you need to ensure your code only uses one at a time.

CubeMX doesn't really support this, but HAL does. The HAL_*_DeInit functions will work for deinitialization.

[RobGeografo]

Thanks. So I can't just disable the OPAMP1_VOUT configuration, enable LPUART1 and use both peripherals simultaneously, can I? I had the impression that the the OPAMP1_VOUT is internally connected to ADC IN13 when the peripheral is enabled.

[TDK]

I assumed from your question statement that there was a pin conflict. Otherwise, why would you not be able to use both simultaneously?

[RobGeografo]

There is a conflict on cubeMX on PA2, but I don't think I need OPAMP_VOUT function on the external pin as I believe it's connected internally to ADC IN13. However, cubeMX doesn't let me enable both peripherals together.

[TDK]

Ahh. Seems like "PGA Internally Connected" should give you what you want but I don't know enough to know why it's still initializing PA3 in that case.

But yes, with no conflict, you can run both together. Could be a missing CubeMX feature here but could also be some logical explanation.

Doesn't look like "PGA Not Connected" routes the output to ADC, judging by the notes.

[Tesla DeLorean]

You're perhaps going to have to "think beyond" what CubeMX does/says, and actually test and try things on the chip you're using. The number of forum members using that specific chip, and CubeMX, is apt to be rather thin.

[RobGeografo]

Cool, thanks. However, I now have a conflict on PA3. So I still need to enable LPUART1 at runtime as well as reconfigure PA3 as LPUART1 RX. I am not sure that's possible?

[RobGeografo]

I realized I have made an explanation error. My aim is not to enable the required configuration I mentioned in my initial post at runtime or on-the-fly, but rather manually change the pin configuration and add one of the two peripherals manually in the setup code. In other words, mess with HAL if possible or manually configure registers and flags to have both peripherals work simultaneously. My feeling is that it is possible, however, would that damage the chip if misconfigured or is it robust enough to simply freeze?

[T J · Accepted solution]

What I do in this kind of issue is simple...

Set the cube to one peripheral, compile and grab the initialization code for that peripheral, set that aside in your code somewhere.

then reset the cube for the other peripheral to run that one on startup.

Then initialize the other code you captured first, if you are doing it correctly, it should just work..

you should be able to massage the code easy enough...

Its all work and we have all done it one way or another...

Ive never heard of a G474, will be looking that one up now.

I find the ST chips are really excellent and fast, however, the Support from ST Employees is terrible.

Seems that ST Employees cannot code at all.

Can you build the code for the larger chip ? ( more pins)

and slice parts into your code ?

I have had really good success with ST chips, Hal and the Cube... (until I met ST-Azure.. it wont compile whatever I do)