Device is not setting the user data rate and tx power, on reset.

[ankit-bansal-oxit]

Describe the set-up

The board is NUCLEO-WL55JC1 STM32 CubeIDE v1.15.1 STM32 CubeMx v6.10

Describe the bug (skip if none)

I setted the default data rate (say DR4)and Tx power using he cubeMx in LoraWan_end_node example(although its occuring even in the other LoRaWan examples). On device reboot, on first attempt, device tries to connect with the default data rate DR4. On second attempt it switch to DR0, since its in the join parameters. But, even after the device has been joined, its not using the user setted data rate ie DR4, it continues in the DR0.

How to reproduce the bug (skip if none)

1. Open the LoRaWan_End_Node_Example.
2. configure data rate except DR0.
3. Configure tx power except TX_POWER_0.
4. Generate the code and see the effects.

Additional context.

In the generated code, the user parameters has been setted in the file lora_app, using the variable LmHandlerParams.

When the device do not receive the answer from the gateway, the MLME_JOIN event occurs, in the file LmHandler.c,

There are 2 functions called , LmHandlerGetTxDatarate and LmHandlerGetTxPower has been called, to set the data rate and the Tx power for the join parameters. In the function LmHandlerGetTxDatarate, at line 1000, we are setting the data rate to variable name LmHandlerParams. LmHandlerParams is copied from the user device LmHandler values, which has to be used. . This alter the user defined values, causing the issue. On commenting the line 1000, resolves the issue.

Is there is any specific reason, that we are setting the LmHandlerParams, over riding the user values? As these function are not in the original LoRaMac Node repo.

This might be the case for the Tx Power also, although I did not tested it.

[RJMSTM]

Hello @ankit-bansal-oxit,

First, thank you for your contribution. Is your problem with the code generation using STM32Cube MX or with our firmware? Because I can't find the function LmHandlerGetTxDatarate. Where did you encounter your issue? Could you please specify your problem? In which files does this function appear, and is it a problem with the generation using MX?

Thanks,

[ankit-bansal-oxit]

@RJMSTM Thanks for the reply!

My problem is from the firmware side.

The function present in the file LmHandler.c at line 985. Here it isfor the reference https://github.com/STMicroelectronics/STM32CubeWL/blob/99e6b06c87338a6d78a7454e8b455b119cc29ac8/Middlewares/Third_Party/LoRaWAN/LmHandler/LmHandler.c#L985C24-L985C46

https://github.com/STMicroelectronics/STM32CubeWL/blob/main/Middlewares/Third_Party/LoRaWAN/LmHandler/LmHandler.c

When you compare the MLME_JOIN, event, from the ST proviced LmHandler.c and LmHandler.c from loramac node, this funciton LmHandlerGetTxDatarate is absent in the original stack.

https://github.com/STMicroelectronics/STM32CubeWL/blob/99e6b06c87338a6d78a7454e8b455b119cc29ac8/Middlewares/Third_Party/LoRaWAN/LmHandler/LmHandler.c#L1134

https://github.com/Lora-net/LoRaMac-node/blob/dcbcfb329b4a343ab007bc19ac43a8dc952b3354/src/apps/LoRaMac/common/LmHandler/LmHandler.c#L828

[RJMSTM]

ST Internal Reference: 193444

[RJMSTM]

We were unable to reproduce the issue using CubeWL version 1.3.1.

when setting

#define LORAWAN_ADR_STATE LORAMAC_HANDLER_ADR_OFF #define LORAWAN_DEFAULT_DATA_RATE DR_5 #define LORAWAN_DEFAULT_TX_POWER TX_POWER_4

It can be seen that all Join attempts are performed with DR_5 (no downgrade to DR=0) and, after the device joins the network, uplinks are still performed with DR_5. Behavior is consistent even across a device reset.

APPLICATION_VERSION: V1.3.0

MW_LORAWAN_VERSION: V2.5.0

MW_RADIO_VERSION: V1.3.0

L2_SPEC_VERSION: V1.0.4

RP_SPEC_VERSION: V2-1.0.1

AppKey: 2B:7E:15:16:28:AE:D2:A6:AB:F7:15:88:09:CF:4F:3C

NwkKey: 2B:7E:15:16:28:AE:D2:A6:AB:F7:15:88:09:CF:4F:3C

AppSKey: 2B:7E:15:16:28:AE:D2:A6:AB:F7:15:88:09:CF:4F:3C

NwkSKey: 2B:7E:15:16:28:AE:D2:A6:AB:F7:15:88:09:CF:4F:3C

DevEUI: 00:80:E1:15:00:0A:91:4F

AppEUI: 01:01:01:01:01:01:01:01

DevAddr: 00:0A:91:4F

0s036:TX on freq 868300000 Hz at DR 5

0s100:MAC txDone

5s081:RX_1 on freq 868300000 Hz at DR 5

5s127:IRQ_RX_TX_TIMEOUT

5s127:MAC rxTimeOut

6s131:RX_2 on freq 869525000 Hz at DR 0

6s330:IRQ_RX_TX_TIMEOUT

6s330:MAC rxTimeOut

= JOIN FAILED

10s041:TX on freq 868100000 Hz at DR 5

10s105:MAC txDone

15s085:RX_1 on freq 868100000 Hz at DR 5

15s132:IRQ_RX_TX_TIMEOUT

15s132:MAC rxTimeOut

16s136:RX_2 on freq 869525000 Hz at DR 0

16s334:IRQ_RX_TX_TIMEOUT

16s334:MAC rxTimeOut

= JOIN FAILED

20s047:TX on freq 868300000 Hz at DR 5

20s111:MAC txDone

25s091:RX_1 on freq 868300000 Hz at DR 5

25s138:IRQ_RX_TX_TIMEOUT

25s138:MAC rxTimeOut

26s142:RX_2 on freq 869525000 Hz at DR 0

26s340:IRQ_RX_TX_TIMEOUT

26s340:MAC rxTimeOut

= JOIN FAILED

30s053:TX on freq 868300000 Hz at DR 5

30s117:MAC txDone

35s097:RX_1 on freq 868300000 Hz at DR 5

35s144:IRQ_RX_TX_TIMEOUT

35s144:MAC rxTimeOut

36s148:RX_2 on freq 869525000 Hz at DR 0

36s346:IRQ_RX_TX_TIMEOUT

36s346:MAC rxTimeOut

= JOIN FAILED

40s059:TX on freq 868100000 Hz at DR 5

40s123:MAC txDone

45s103:RX_1 on freq 868100000 Hz at DR 5

45s195:MAC rxDone

= JOINED = OTAA =====================

MCRootKey: 7D:F7:6B:0C:1A:B8:99:B3:3E:42:F0:47:B9:1B:54:6F

MCKEKey: 8C:B8:66:5E:0C:0E:0B:64:5B:2E:D9:E4:8A:19:27:7C

AppSKey: 79:A0:57:47:C1:9D:2F:B5:80:1C:11:AA:E5:29:36:3C

NwkSKey: 21:B3:32:BB:43:10:24:B8:00:30:16:B7:27:1D:E0:7E

DBIntKey: 7A:C4:7C:65:FE:25:9B:B6:54:BD:26:35:19:F8:9C:8E

DevEUI: 00:80:E1:15:00:0A:91:4F

AppEUI: 01:01:01:01:01:01:01:01

DevAddr: 26:0B:4D:43

50s062:VDDA: 254

50s062:temp: 25

50s066:TX on freq 867300000 Hz at DR 5

50s069:SEND REQUEST

50s135:MAC txDone

55s116:RX_1 on freq 867300000 Hz at DR 5

55s163:IRQ_RX_TX_TIMEOUT

55s163:MAC rxTimeOut

56s122:RX_2 on freq 869525000 Hz at DR 3

56s181:IRQ_RX_TX_TIMEOUT

56s181:MAC rxTimeOut

========== MCPS-Confirm =============

60s070:VDDA: 254