LoRaWAN_End_Node_FreeRTOS application on Nucleo-WL55JC2. Problem with sending more than one data packet after successful join procedure.

[JNowa.4]

I'm using STM32WL V1.2.0 and trying to generate LoRaWAN End Node FreeRTOS application from .ioc file and make it work but I met some issues with sending data packets periodacally. After succescul join procedure device sends only one data packet. After Tx LmHandlerSend status is LORAMAC_HANDLER_BUSY_ERROR, MacCtx.MacState equals LORAMAC_TX_RUNNING and no more data packets are send. I think that the issue is caused by some part of FreeRTOS because I generated appliaction without it and everything works as expected but I can not find soucre of the problem. Here are steps that I made in order to generate application:

- generated project using .ioc Configuration File from LoRaWAN_EndNode_FreeRTOS example

- imported BSP driver and added it to include path

- replaced generated app_freertos.c file with app_freertos.c file from LoRaWAN_EndNode_FreeRTOS example

- inside lora_app.c file filled user code section of SendTxData function with own sending code:

static void SendTxData(void)
{
 /* USER CODE BEGIN SendTxData_1 */
	LmHandlerErrorStatus_t status = LORAMAC_HANDLER_ERROR;
	int i = 0;
 
	AppData.Buffer[i++] = 1;
	AppData.Buffer[i++] = 2;
	AppData.Buffer[i++] = 3;
	AppData.Buffer[i++] = 4;
 
	AppData.BufferSize = i;
 
	AppData.Port = LORAWAN_USER_APP_PORT;
 
	status = LmHandlerSend(&AppData, LmHandlerParams.IsTxConfirmed, false);
 /* USER CODE END SendTxData_1 */
}

Ultimately, I want to make LoRaWAN End Node FreeRTOS application work on custom board based on STM32WL55CCU6 so it's important for me to be able to generate project and make it work without issues. So here are my questions. What may be causing the issue with sending data periodically? Is there any extra steps needed in FreeRTOS configuration?

[Louis AUDOLY]

Hello and welcome @Community member​ ,

I would suggest you to start from the LoRaWAN_EndNode_FreeRTOS example, and just to replace the data you want to send in the SendTxData function.

Or you can also compare the two projects (the one you generate and the one we provide) to understand the differences between the two projects.

You may need functions you did not add in your lora_app.c file.

Let me know if you resolve your issue

Best regards

Louis

[JNowa.4]

Hello @Louis AUDOLY​ and thank you for the anwser.

I've tried both methods you suggested. I've replaced the data I want to send in the SendTxData function and it works but I need to make example work on slightly different MCU. I've also spotted files that differ and tried to replace them with the ones you provides but there is still an issue. One thing I've also tested was replacing yours lora_app.c file with mine and then application works fine. So I'm wondering if there are any hidden settings that I need to set up to make application work.

Generated by me LoRaWAN End Node FreeRTOS applicaticon acts in unstable way. Somethimes app got stucked after sending few (2 - 3) Join Requests and somethimes after sending first uplink message. One common thing is that app always get stucked in the same point (LmHandlerSend function returnes LORAMAC_HANDLER_BUSY_ERROR and MacCtx.MacState is LORAMAC_TX_RUNNING). 

[Louis AUDOLY]

Hi @Community member​ ,

There isn't specific setting, it's just that the end node we provide include code that cannot be generated from CubeMX (in lora_app.c for example). That's why it is easier to start from our existing project and then to modify the ioc.

I'm glad you have been able to make this work

Regards

[JNowa.4]

@Louis AUDOLY​ I found the difference in program flow of st example and project generated by me from .ioc file. Inside lora_app.c file there is Task which waits for setting ThreadFlag. After flag being set LmHandlerProcess() is called.

static void Thd_LmHandlerProcess(void *argument)
{
  /* USER CODE BEGIN Thd_LmHandlerProcess_1 */
 
  /* USER CODE END Thd_LmHandlerProcess_1 */
  UNUSED(argument);
  for (;;)
  {
    osThreadFlagsWait(1, osFlagsWaitAny, osWaitForever);
    LmHandlerProcess(); /*what you want to do*/
    /* USER CODE BEGIN Thd_LmHandlerProcess_2 */
 
    /* USER CODE END Thd_LmHandlerProcess_2 */
  }
}

The only place where flag can be set is OnMacProcessNotify() callback. After successful Join Procedure first data packet is being sent. When Radio ends transmission OnRadioTxDone() callback (LoRaMac.c) is called. Inside OnRadioTxDone function MacProcessNotify( ) is executed which leads to OnMacProcessNotify() and setting the flag. The difference apears inside osThreadFlagsSet() function (cmsis_os2.c). In working example after (void)xTaskNotifyAndQueryFromISR (hTask, 0, eNoAction, &rflags, NULL); (line 697) variable rflags is set to 1.

 

In my project this variable has some random value I believe so there is the problem with unblocking the Thd_LmHandlerProcess task. 

So the question is, why is that? Configuration of FreeRTOS in .ioc is exactly the same and also all of the files inside FreeRTOS middleware directory are the same. What might be possible solution, what might be causing the issue and where should I go further with my debugging?

[JNowa.4]

ping

[Louis AUDOLY]

Hello @Community member​ ,

The two screenshots you share don't show the same call stack so we cannot compare the value of rflag here.

Then do you have the same version of FreeRTOS and CMSIS on your personal project and ST example ? (the following screenshot is taken from CubeMx)

 

Do you have the same include path to CMSIS, middleware etc... between the two projects as you seems to have two different environments ?

Regards

[JNowa.4]

@Louis AUDOLY​ I'm working with CMSIS v2 and FreeRTOS in version 10.2.1. Include paths are the same. Difference in environments color mode is because of that I was using two different workspaces to be able to compare projects side by side. Attached you will find invalid project so you can test it and see how it acts. In the project all of the files are replaced with example files but anyway program execution is different.

[Louis AUDOLY · Accepted solution]

Hello @Community member​ ,

Can you try to increase the stack size of the send thread by 512 and replay your test please.

The value you have in htask seems to be overwritten by the thread just below (which is the send thread that cause your error).

Let me know if this solve your issue.

Regards

[JNowa.4]

@Louis AUDOLY​ Thanks a lot! It finally works. Increasing stack size of the send thread by 512 solved the issue.