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]

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?

[MM..1]

Yes you can in runtime do all reconfigs, but need care hw connections.

For simple coding you can in MX generate code for all combinations and MX Inits copy to user parts code, as last generate boot configuration.

[T J]

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)

[TDK]

It is exceedingly difficult to kill an STM32 chip without applying voltage out of range. Misconfiguring is unlikely to harm anything.

Yes, of course you can edit user code to do what you want. HAL does not require use of CubeMX.

[RobGeografo]

That's reassuring, thanks!