LoRaWAN RTOS project hang up

WisangAnggoro commented 1 year ago

Setup:

NucleoWL55JC The latest version of this project 8a8140f

IDE:

STM32CubeIDE 1.10.1

Bug & Question:

Hi there, I want to create a LoRaWAN project based on STM32WL with the RTOS feature. I've already tried what I describe in the steps below, just a normal program with LED Blink. Most of the time it hangs up and not continuing both the LoRa and Blink Program. Maybe someone can give a suggestion of where I did wrong here. Any suggestion to make this work or anything to allow LoRaWAN project with STM32WL and RTOS would be appreciated.

Also, I have one question, let me write it here rather than opening a new issue: Does project LoRaWAN_End_Node_FreeRTOS use dual core in its code? If not, how I maximize the dual-core feature for my LoRaWAN RTOS project? Any solution for this project or alternative solution using other than this project is ok and appreciated.

How to reproduce the bug:

Clone project
Open project (Projects/NUCLEO-WL55JC/Applications/LoRaWAN/LoRaWAN_End_Node_FreeRTOS)
Modify LoRaWAN parameter (AS923-2, change deveui and appkey)
Build, Upload, and test (work fine)
Add Blink Task on app_freertos.c
Build, Upload, and test (not work fine, the program hang up after several uplinks most of the time)

Blink Task Attribute:

const osThreadAttr_t blinkTask_attributes = {
  .name = "defaultTask",
  .priority = (osPriority_t) osPriorityBelowNormal,
  .stack_size = 512 * 1
};

Blink Task Function:

void BlinkTask(void *argument) {
  for (;;) {
    BSP_LED_Toggle(LED1);
    BSP_LED_Toggle(LED2);
    BSP_LED_Toggle(LED3);
    osDelay(500);
  }
}

Adding it to MX_FREERTOS_Init

blinkTaskHandle   = osThreadNew(BlinkTask, NULL, &blinkTask_attributes);

TOUNSTM commented 1 year ago

Hello @WisangAnggoro,

Thank you for this report. We will get back to you as soon as we analyze it further. This may take some time. Thank you for your comprehension.

With regards,

RJMSTM commented 1 year ago

ST Internal Reference: 158184

niclash commented 1 year ago

Additionally; I have EU868 set up, on a STM32WLE5 (RAK3172 Wisduo), with CubeWL 1.3.0 and configured LoraWAN in CubeMX and use FreeRTOS.

I see the same/similar behavior. After the second SendTxData, it "hangs". What has happened is that the MacCtx.MacState remains in LORAMAC_TX_RUNNING mode. Never times out, and doesn't go to LORAMAC_IDLE after the Tx has been completed.

Hmmmm... While preparing to make my project available on Github, changing the silly name to something useful, but otherwise no change, I now got many subsequent SendTx completions, but stopped after 11. Could it be a timing issue?

Anyway, the project is available on https://github.com/niclash/colibri-1dp-mcu1

Here is my log output ("Next:" was added at end of SendTxData in lora_app.c)

###### AppKey:      xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### NwkKey:      xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### AppSKey:     xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### NwkSKey:     xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### DevEUI:      00:80:E1:15:05:57:22:52
###### AppEUI:      01:01:01:01:01:01:01:01
###### DevAddr:     05:57:22:52
0s041:TX on freq 868300000 Hz at DR 0
1s527:MAC txDone
6s559:RX_1 on freq 868300000 Hz at DR 0
8s369:MAC rxDone
###### MCRootKey:   xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### MCKEKey:     xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### AppSKey:     xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### NwkSKey:     xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### DBIntKey:    xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
###### DevEUI:      00:80:E1:15:05:57:22:52
###### AppEUI:      01:01:01:01:01:01:01:01
###### DevAddr:     26:0B:19:CB
10s047:VDDA: 254
10s047:temp: 21
10s052:TX on freq 867300000 Hz at DR 0
10s054:SEND REQUEST
10s054:Next: 10000
11s209:MAC txDone
16s242:RX_1 on freq 867300000 Hz at DR 0
16s440:IRQ_RX_TX_TIMEOUT
16s440:MAC rxTimeOut
17s197:RX_2 on freq 869525000 Hz at DR 3
17s255:IRQ_RX_TX_TIMEOUT
17s255:MAC rxTimeOut
20s058:VDDA: 254
20s058:temp: 21
20s062:TX on freq 868100000 Hz at DR 0
20s065:SEND REQUEST
20s065:Next: 10000
21s220:MAC txDone
26s252:RX_1 on freq 868100000 Hz at DR 0
26s451:IRQ_RX_TX_TIMEOUT
26s451:MAC rxTimeOut
27s208:RX_2 on freq 869525000 Hz at DR 3
27s266:IRQ_RX_TX_TIMEOUT
27s266:MAC rxTimeOut
30s069:VDDA: 254
30s069:temp: 21
30s074:TX on freq 868300000 Hz at DR 0
30s076:SEND REQUEST
30s076:Next: 10000
31s231:MAC txDone
36s263:RX_1 on freq 868300000 Hz at DR 0
36s461:IRQ_RX_TX_TIMEOUT
36s461:MAC rxTimeOut
37s218:RX_2 on freq 869525000 Hz at DR 3
37s277:IRQ_RX_TX_TIMEOUT
37s277:MAC rxTimeOut
40s080:VDDA: 254
40s080:temp: 21
40s083:TX on freq 867900000 Hz at DR 0
40s086:SEND REQUEST
40s086:Next: 10000
41s242:MAC txDone
46s274:RX_1 on freq 867900000 Hz at DR 0
46s472:IRQ_RX_TX_TIMEOUT
46s472:MAC rxTimeOut
47s229:RX_2 on freq 869525000 Hz at DR 3
47s288:IRQ_RX_TX_TIMEOUT
47s288:MAC rxTimeOut
50s090:VDDA: 254
50s090:temp: 21
50s095:TX on freq 868100000 Hz at DR 0
50s097:SEND REQUEST
50s097:Next: 10000
51s252:MAC txDone
56s285:RX_1 on freq 868100000 Hz at DR 0
56s483:IRQ_RX_TX_TIMEOUT
56s483:MAC rxTimeOut
57s240:RX_2 on freq 869525000 Hz at DR 3
57s298:IRQ_RX_TX_TIMEOUT
57s298:MAC rxTimeOut
60s101:VDDA: 254
60s101:temp: 21
60s105:TX on freq 867300000 Hz at DR 0
60s108:SEND REQUEST
60s108:Next: 10000
61s263:MAC txDone
66s295:RX_1 on freq 867300000 Hz at DR 0
66s494:IRQ_RX_TX_TIMEOUT
66s494:MAC rxTimeOut
67s250:RX_2 on freq 869525000 Hz at DR 3
67s309:IRQ_RX_TX_TIMEOUT
67s309:MAC rxTimeOut
70s112:VDDA: 254
70s112:temp: 21
70s117:TX on freq 867700000 Hz at DR 0
70s119:SEND REQUEST
70s119:Next: 10000
71s274:MAC txDone
76s306:RX_1 on freq 867700000 Hz at DR 0
76s504:IRQ_RX_TX_TIMEOUT
76s504:MAC rxTimeOut
77s261:RX_2 on freq 869525000 Hz at DR 3
77s320:IRQ_RX_TX_TIMEOUT
77s320:MAC rxTimeOut
80s123:VDDA: 254
80s123:temp: 21
80s126:TX on freq 868500000 Hz at DR 0
80s129:SEND REQUEST
80s129:Next: 10000
81s285:MAC txDone
86s317:RX_1 on freq 868500000 Hz at DR 0
86s515:IRQ_RX_TX_TIMEOUT
86s515:MAC rxTimeOut
87s272:RX_2 on freq 869525000 Hz at DR 3
87s331:IRQ_RX_TX_TIMEOUT
87s331:MAC rxTimeOut
90s133:VDDA: 254
90s133:temp: 21
90s138:TX on freq 867300000 Hz at DR 0
90s140:SEND REQUEST
90s140:Next: 10000
91s295:MAC txDone
96s328:RX_1 on freq 867300000 Hz at DR 0
96s526:IRQ_RX_TX_TIMEOUT
96s526:MAC rxTimeOut
97s283:RX_2 on freq 869525000 Hz at DR 3
97s341:IRQ_RX_TX_TIMEOUT
97s341:MAC rxTimeOut
100s144:VDDA: 254
100s144:temp: 21
100s148:TX on freq 868100000 Hz at DR 0
100s151:SEND REQUEST
100s151:Next: 10000
101s306:MAC txDone
106s338:RX_1 on freq 868100000 Hz at DR 0
106s537:IRQ_RX_TX_TIMEOUT
106s537:MAC rxTimeOut
107s293:RX_2 on freq 869525000 Hz at DR 3
107s352:IRQ_RX_TX_TIMEOUT
107s352:MAC rxTimeOut
110s155:VDDA: 254
110s155:temp: 21
110s160:TX on freq 868300000 Hz at DR 0
110s162:SEND REQUEST
110s162:Next: 10000
111s317:MAC txDone
120s162:Next: 10000
130s162:Next: 10000
140s162:Next: 10000
150s162:Next: 10000
160s162:Next: 10000
170s162:Next: 10000
180s162:Next: 10000
190s162:Next: 10000
200s162:Next: 10000
210s162:Next: 10000

RJMSTM commented 5 months ago

Hello @WisangAnggoro,

We tried to reproduce the issue, but with no success so far. We were able to run the LoRaWAN_End_Node_FreeRTOS correctly with and without the additional blinkTask.

I confirm blinkTask correctly executes, as I'm able to see the Leds blinking, and the uplink messages being sent to the LoraWAN Network server.

Regards, Rania

STMicroelectronics / STM32CubeWL