STM32WL series radio power output

[Martdur]

As discussed here 56833 the support for STM32WL power amplifier configuration now allows to select between rfo-hp and rfo-lp.
But a comment says that low power output is not currently supported by the driver :

` /* High-power output is selected as a consequence of using
 * tx/rx-enable-gpio to control FE_CTRL1 and FE_CTRL2. Low-power
 * output would require both FE_CTRL1 and FE_CTRL2 to be high,
 * which is not currently supported by the driver.
 */`

So setting power-amplifier-output = "rfo-lp"; won't work as I understand.

Is there a way to modify the device tree parameter to make this work or maybe there is something I'm missing.

Do you have any input to this @knthm ?
And thanks by the way for the work in this PR !

[erwango]

As @knthm is not active anymore, maybe @martinjaeger you would be able to answer as an active (at least former) STM32WL user ?

[ndrs-pst]

@Martdur Alongside setting power-amplifier-output = "rfo-lp";
due to the RF Front-end schematic
(https://www.st.com/resource/en/schematic_pack/mb1389-wl55jc-highband-d04_schematic.pdf),
you may need to modify it to pass 1 to sx126x_set_rx_enable(1); 0 to sx126x_set_tx_enable(0); instead.

zephyr/drivers/lora/sx126x.c

Lines 286 to 289 in 6700a15

	case MODE_TX:
	sx126x_set_rx_enable(0);
	sx126x_set_tx_enable(1);
	break;

[ndrs-pst]

According to the stm32wlxx-nucleo-bsp

stm32wlxx_nucleo_radio.c#L105-L146

I think the followings should be GPIO_ACTIVE_HIGH

tx-enable-gpios = <&gpioc 4 GPIO_ACTIVE_LOW>; /* FE_CTRL1 */
rx-enable-gpios = <&gpioc 5 GPIO_ACTIVE_LOW>; /* FE_CTRL2 */

[martinjaeger]

The existing devicetree spec looks correct to me, see excerpt from Nucleo schematic:

[ndrs-pst]

Yeah, you're right. Thanks.

[martinjaeger]

@Martdur The power-amplifier-output = "rfo-lp"; should be supported in general. I'm using the Olimex board in some projects, which has the LP amplifier configured. It's just not supported on the Nucleo board because it would require setting of 3 different pins to the correct levels (see table posted above) and we can currently only configure the rx-enable and tx-enable pins.

[Martdur]

And, Can the use of power-amplifier-output = "rfo-lp"; on nucleo stm32wl55jc without any changes can damage the board ?
I think I've broke some of mine with this kind of settings.
If so it'd be nice to remove this property for this board as long as the feature is not implemented.

[ndrs-pst]

Thanks for all the information you've bring. So for the nucelo 32wl55jc I can configure

tx-enable-gpios = <&gpioc 4 GPIO_ACTIVE_HIGH>; /* FE_CTRL1 */
rx-enable-gpios = <&gpioc 5 GPIO_ACTIVE_LOW>; /* FE_CTRL2 */

with power-amplifier-output = "rfo-lp"; and it should work specifically for the lp mode ?

Instead of changing to sx126x_set_tx_enable(0); only case MODE_TX: changing to GPIO_ACTIVE_HIGH will effect other switch case which will bring undesired result of pin control to RF SP3T Switch

zephyr/drivers/lora/sx126x.c

Lines 291 to 306 in 6700a15

	case MODE_RX:
	case MODE_RX_DC:
	case MODE_CAD:
	sx126x_set_tx_enable(0);
	sx126x_set_rx_enable(1);
	break;
	case MODE_SLEEP:
	/* Additionally disable the DIO1 interrupt to save power */
	sx126x_dio1_irq_disable(&dev_data);
	__fallthrough;
	default:
	sx126x_set_rx_enable(0);
	sx126x_set_tx_enable(0);
	break;
	}

[martinjaeger]

Thanks for all the information you've bring. So for the nucelo 32wl55jc I can configure

tx-enable-gpios = <&gpioc 4 GPIO_ACTIVE_HIGH>; /* FE_CTRL1 */
rx-enable-gpios = <&gpioc 5 GPIO_ACTIVE_LOW>; /* FE_CTRL2 */

with power-amplifier-output = "rfo-lp"; and it should work specifically for the lp mode ?

I don't think this will work, as the driver will switch between RX and TX mode, so the pins need to be mutually exclusive. Take a look at the truth table:

	FE_CTRL1	FE_CTRL2
TX mode	High	High
RX mode	Low	Low

The RX mode is not a valid combination from the above table from the Nucleo schematic. Not sure if it could destroy the hardware.

[Martdur]

Ok thanks a lot !
I don't know if I close the discussion as it can be a feature to be implemented later on (maybe by adding a specific implementation of the driver for this kind of board).
I know that this feature was implemented in mbdedos and in stmCube.
What do you think ?

[martinjaeger]

I'd suggest to open an enhancement issue describing the results of the discussion. That way it's easier to find in the future. (at least I don't usually look into the discussions unless I'm pinged by someone)

[ndrs-pst]

@Martdur, @martinjaeger I'll try to open a PR (as an enhancement) within today. Please wait a moment. 😃

---

Here we go!!! #75445