I’ve run into a possible issue with the LmHandler library. STM32Cube_FW_WL_V1.0.0\Middlewares\Third_Party\LoRaWAN\LmHandler

In particular the LmHandlerSend function.

As I follow the code I see that before sending a frame a function calculates if the number of bytes to be sent will fit in a frame. It takes also in account the FOPTS field.

In case FOPTS field is empty the app data buffer of valid lenght gets sent and life is great.

In case the app data (valid lenght by itself) + FOPTS are greater than the total number of bytes allowed for the given region and spreading factor it will send an empty frame to “to flush MAC commands ”, as commented in the code.

What strikes me as problematic is not only that the app data buffer will be discarted but also that the user will not be informed that his/her buffer wasn’t sent. LmHandlerSend will in this case return LORAMAC_HANDLER_SUCCESS

Hi,
I tried to set up the cubeIDE to compile applications provided in the ST32cubeWL, in order to use them with the nucleo wl55jc1 evaluation board.

The version in use are :
STM32Cube_FW_WL_V1.0.0
STM32CubeIDE_1.5.1

Everything seems to work while compiling the LoRaWAN_AT_Slave applications (hence I suppose the overall configuration is correct.)

When I try to compile the Sigfox_AT_Slave application, I got 26 errors, build_error.txt

The first one being :

arm-none-eabi-gcc -o "Sigfox_AT_Slave.elf" @"objects.list"  -l:Sgfx-Cmac-V1.0.0-CM0-O3.a -l:Sgfx-Monarch-V2.0.0-CM0-O3.a -l:SFX_LIB_V2.8.1_SE_FDL_MON.a -l:SFX_ADDON_RFP_V0.6.0_SE_FDL_MON.a -mcpu=cortex-m4 -T"C:\ST\tfa_prj\Sigfox_AT_Slave\STM32WL55JCIX_FLASH.ld" --specs=nosys.specs -Wl,-Map="Sigfox_AT_Slave.map" -Wl,--gc-sections -static -L../Middlewares/Third_Party/Sigfox/Crypto -L../Middlewares/Third_Party/Sigfox/Monarch -L../Middlewares/Third_Party/Sigfox/SigfoxLib -L../Middlewares/Third_Party/Sigfox/SigfoxLibTest --specs=nano.specs -mfloat-abi=soft -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
../Middlewares/Third_Party/Sigfox/SigfoxLib\SFX_LIB_V2.8.1_SE_FDL_MON.a(sigfox_api.o): In function `SIGFOX_API_get_version':
D:\SVN\TST_U_LIB\SFX_LIBRARY\tags\V2.8.1\precompil\SE_FDL_MON\src\sigfox_api.c:(.text+0x262): undefined reference to `SE_API_get_version'

I did the setup using the File>new> stm32 from an ioc file option.
Then try to build without touching any of the option...

(by the way, the issue template depicted here : cannot be found for this project , so sorry if the format is not adequat...

Hi,
I am using WL55JC1 board with STM32CubeIDE. Can you please tell how to increase the Preamble Length in End Node application [https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Projects/NUCLEO-WL55JC/Applications/LoRaWAN/LoRaWAN_End_Node] ?

Hi
I'm using Nucleo-WL55JC1 STM32WL development board for LoRaWAN end node dual core and i have a custom board with MCU STM32WLE5CBU6 for LoRaWAN end node single core.

I have configured LoRaWAN end node protocol parameters like this documentation (https://www.st.com/resource/en/application_note/dm00660451-how-to-build-a-lora-application-with-stm32cubewl-stmicroelectronics.pdf).

The program from the example project has been uploaded successfully. After I uploaded the LoRaWAN end node program to the STM32WL55JC1 (dual core) development board, it said
"WARNING: There is a difference between the MAPPING_TABLE placement in memory: 0x20008000
and the address calculated according to the IPCCDBA option byte: 0x2003FFF0
The execution enters now in a while(1){}
please check the CM4\MbMux\mbmuxif_sys.c or update the scatter file"
on the external terminal via serial usb and couldn't send data to the server / gateway with OTAA. I have followed the solution steps given from this topic:
(https://community.st.com/s/question/0D53W00000VgqmvSAB/trouble-with-the-stm32cubewl-dual-core-example-projects)
and I still have problems like that

Meanwhile, for the single core STM32WLE5CBU6 MCU end node, the program was successfully uploaded with the Lora protocol configured. But there is no response / action from the node sending data to the server / gateway with OTAA. On this board, I'm not using TCXO and DCDC.

So, from the problem I got, is there a solution or configuration that I missed so that the nodes can send data with OTAA to the server / gateway with dual core or single core. I really appreciate your attention, thank you.

Hi,
I am a bit confused on the lora STM32WL sequence protocol system, I want my device to sleep and wakeup according to the periodic values I want. I have made my own sleep function (stop 2 mode & radio sleep) with wake up triggered using RTC (in seconds) and push button. Where can I put my function (PLB_SleepMode) into the sequencer utility lora end node STM32WL ?

Thank you

Here my code for custom sleep and wake up system:

void HAL_RTCEx_WakeUpTimerEventCallback(RTC_HandleTypeDef *RtcHandle)
{
  //Clear wake up flag
  __HAL_PWR_CLEAR_FLAG( PWR_FLAG_WU );
}

void PLB_RtcWakeUpTimeSetting( RTC_HandleTypeDef *RtcHandle, unsigned int seconds )
{
  //Set wake up time
  /* Disable all used wakeup source */
  HAL_RTCEx_DeactivateWakeUpTimer( RtcHandle );
  
  __HAL_RCC_WAKEUPSTOP_CLK_CONFIG( RCC_STOP_WAKEUPCLOCK_MSI );
  HAL_RTCEx_SetWakeUpTimer_IT( RtcHandle, seconds - 1, RTC_WAKEUPCLOCK_CK_SPRE_16BITS );
  
}

RTC_HandleTypeDef *PLB_RtcPowerSavingConfig( void )
{
  //Set RTC Clock, Timer, Calendar. and return RTC_HandleTypeDef to wake up
  static RTC_HandleTypeDef RtcHandle;
  
  RTC_TimeTypeDef sTime;
  RTC_DateTypeDef sDate;
  
  RtcHandle.Instance            = RTC;
  RtcHandle.Init.HourFormat     = RTC_HOURFORMAT_24;
  RtcHandle.Init.AsynchPrediv   = 127;
  RtcHandle.Init.SynchPrediv    = 255;
  RtcHandle.Init.OutPut         = RTC_OUTPUT_DISABLE;
  RtcHandle.Init.OutPutRemap    = RTC_OUTPUT_REMAP_NONE;
  RtcHandle.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH;
  RtcHandle.Init.OutPutType     = RTC_OUTPUT_TYPE_OPENDRAIN;
  HAL_RTC_Init( &RtcHandle );
  
  sTime.Hours          = 0x0;
  sTime.Minutes        = 0x0;
  sTime.Seconds        = 0x0;
  sTime.TimeFormat     = RTC_HOURFORMAT_24;
  sTime.DayLightSaving = RTC_DAYLIGHTSAVING_NONE;
  sTime.StoreOperation = RTC_STOREOPERATION_RESET;
  HAL_RTC_SetTime( &RtcHandle, &sTime, FORMAT_BIN );
  
  sDate.WeekDay = RTC_WEEKDAY_MONDAY;
  sDate.Month   = RTC_MONTH_JANUARY;
  sDate.Date    = 0x1;
  sDate.Year    = 16;
  HAL_RTC_SetDate( &RtcHandle, &sDate, FORMAT_BIN );
  
  return &RtcHandle;
}

void PLB_RtcRccPowerSavingConfig( void )
{
  HAL_StatusTypeDef status = HAL_OK;
  RCC_PeriphCLKInitTypeDef PeriphClkInit;
  RCC_OscInitTypeDef       RCC_OscInitStruct;
  
  /* Disable backup domeain protection */
  HAL_PWR_EnableBkUpAccess();
  
  /* Enable RTC APB clock gating */
  __HAL_RCC_RTCAPB_CLK_ENABLE();
  
  /* Disable the Wake-up Timer */
  __HAL_RTC_WAKEUPTIMER_DISABLE(RtcHandle);
  /* In case of interrupt mode is used, the interrupt source must disabled */ 
  __HAL_RTC_WAKEUPTIMER_DISABLE_IT(RtcHandle,RTC_IT_WUT);
  __HAL_RTC_WAKEUPTIMER_CLEAR_FLAG(RtcHandle,RTC_FLAG_WUTF);
  
  /* Get RTC clock configuration */
  HAL_RCCEx_GetPeriphCLKConfig(&PeriphClkInit);
  
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSE;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
  RCC_OscInitStruct.LSEState = RCC_LSE_ON;  
  PeriphClkInit.RTCClockSelection    = RCC_RTCCLKSOURCE_LSE;
  
  /* COnfigure oscillator */
  status = HAL_RCC_OscConfig(&RCC_OscInitStruct);
  if(status == HAL_OK)
  {
    /* Configure RTC clock source */
    PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_RTC;
    status = HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit);
    
    /* Enable RTC Clock */
    if(status == HAL_OK)
    {
      __HAL_RCC_RTC_ENABLE();
    }
  }
  HAL_NVIC_EnableIRQ( RTC_WKUP_IRQn );
  HAL_NVIC_SetPriority( RTC_WKUP_IRQn, 1, 0 );
  
}

void PLB_InitSystem(void)
{
  HAL_Init();
  PLB_SystemClock_Config( );
  SystemApp_Init();
  PLB_LED_Init(PLB_LED_MODE_RUN);
  PLB_LED_Init(PLB_LED_LORA_INDICATOR);
  PLB_LORA_Seq_Task();
}

void PLB_PowerSavingStopMode(RTC_HandleTypeDef *RtcHandle, unsigned int WakeUpTime, GPIO_TypeDef *WakeUpGPIO)
{
  GPIO_InitTypeDef GPIO_InitStructure;
  
  Radio.Sleep();
  
  /* Enable GPIOs clock */
  __HAL_RCC_GPIOA_CLK_ENABLE();
  __HAL_RCC_GPIOB_CLK_ENABLE();
  __HAL_RCC_GPIOC_CLK_ENABLE();
  __HAL_RCC_GPIOH_CLK_ENABLE();
  
  /* Configure all GPIO port pins in Analog Input mode (floating input trigger OFF) */
  /* Note: Debug using ST-Link is not possible during the execution of this   */
  /*       example because communication between ST-link and the device       */
  /*       under test is done through UART. All GPIO pins are disabled (set   */
  /*       to analog input mode) including  UART I/O pins.           */
  GPIO_InitStructure.Pin = GPIO_PIN_All;
  GPIO_InitStructure.Mode = GPIO_MODE_ANALOG;
  GPIO_InitStructure.Pull = GPIO_NOPULL;
  GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_LOW;
  
  HAL_GPIO_Init(GPIOA, &GPIO_InitStructure);
  HAL_GPIO_Init(GPIOB, &GPIO_InitStructure);
  HAL_GPIO_Init(GPIOC, &GPIO_InitStructure);
  HAL_GPIO_Init(GPIOH, &GPIO_InitStructure);
  
  //wake up pin setting
  GPIO_InitStructure.Pin   = PLB_WakeupPB_GPIO_Pin; // wakeup by PA.0
  GPIO_InitStructure.Mode  = GPIO_MODE_IT_RISING;
  GPIO_InitStructure.Pull  = GPIO_PULLDOWN;
  GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_HIGH;
  HAL_GPIO_Init( GPIOA, &GPIO_InitStructure );
  
  GPIO_InitStructure.Pin   = GPIO_PIN_9;
  GPIO_InitStructure.Mode  = GPIO_MODE_OUTPUT_PP;
  GPIO_InitStructure.Pull  = GPIO_NOPULL;
  GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
  
  HAL_GPIO_Init(GPIOA, &GPIO_InitStructure);
  
  GPIO_InitStructure.Pin = GPIO_PIN_8;
  HAL_GPIO_Init(GPIOA, &GPIO_InitStructure);
  
  GPIO_InitStructure.Pin = GPIO_PIN_7;
  HAL_GPIO_Init(GPIOA, &GPIO_InitStructure);

  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_8, GPIO_PIN_RESET); 
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9, GPIO_PIN_RESET); 
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_7, GPIO_PIN_RESET); 
  
  HAL_NVIC_SetPriority(EXTI0_IRQn, 1, 0);
  HAL_NVIC_EnableIRQ(EXTI0_IRQn);
  
  /* Disable GPIOs clock */
  __HAL_RCC_GPIOA_CLK_DISABLE();
  __HAL_RCC_GPIOB_CLK_DISABLE();
  __HAL_RCC_GPIOC_CLK_DISABLE();
  __HAL_RCC_GPIOH_CLK_DISABLE();
  
  //Set power saving duration by RTC
  //  if(WakeUpTime < 5 ) WakeUpTime = WakeUpTime + 5;
  PLB_RtcWakeUpTimeSetting( RtcHandle, WakeUpTime );
  
  // HAL_RTCEx_WakeUpTimerIRQHandler(RtcHandle);
  HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN1);
  
  //Clear wake up flag
  if( __HAL_PWR_GET_FLAG( PWR_FLAG_WU ) != RESET )
  {__HAL_PWR_CLEAR_FLAG( PWR_FLAG_WU ); }
  
  if(__HAL_GPIO_EXTI_GET_FLAG(GPIO_PIN_0) != RESET)
  {__HAL_GPIO_EXTI_CLEAR_FLAG(GPIO_PIN_0); }
  
  /* Enter STOP 2 mode */
  LL_PWR_ClearFlag_C1STOP_C1STB();
  HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
  
  PLB_InitSystem();
  Radio.Standby();
  
  /*Disable all used wakeup sources: Pin1(PA.0)*/
  HAL_PWR_DisableWakeUpPin(PWR_WAKEUP_PIN1);
}

void PLB_SleepMode(unsigned int wakeUpTime)
{
  RTC_HandleTypeDef *RtcHandle;
  
  APP_PRINTF("\nPowerSaving Mode - Start\n");
  
  //RCC Config for Power Saving
  PLB_RtcRccPowerSavingConfig();
  
  //RTC Config for Power Saving
  RtcHandle = PLB_RtcPowerSavingConfig();
  
  //Enter Stop Mode
  PLB_PowerSavingStopMode( RtcHandle, wakeUpTime, GPIOA );
  APP_PRINTF("\nPowerSaving Mode - End\n");
}

In utilities_def.h it is possible to add additional task priority numbers and task numbers:

/**
  * This is the list of priority required by the application
  * Each Id shall be in the range 0..31
  */
typedef enum
{
  CFG_SEQ_Prio_0,
  /* USER CODE BEGIN CFG_SEQ_Prio_Id_t */

  /* USER CODE END CFG_SEQ_Prio_Id_t */
  CFG_SEQ_Prio_NBR,
} CFG_SEQ_Prio_Id_t;

/**
  * This is the list of task id required by the application
  * Each Id shall be in the range 0..31
  */
typedef enum
{
  CFG_SEQ_Task_LmHandlerProcess,
  CFG_SEQ_Task_LoRaSendOnTxTimerOrButtonEvent,
  /* USER CODE BEGIN CFG_SEQ_Task_Id_t */

  /* USER CODE END CFG_SEQ_Task_Id_t */
  CFG_SEQ_Task_NBR
} CFG_SEQ_Task_Id_t;

However, the size of TaskPrio is set to a fixed value of 2:

/**
 * @brief default value of priority number.
 */
#ifndef UTIL_SEQ_CONF_PRIO_NBR 
  #define UTIL_SEQ_CONF_PRIO_NBR  (2)
#endif

/**
 * @brief task prio management.
 */
static UTIL_SEQ_Priority_t TaskPrio[UTIL_SEQ_CONF_PRIO_NBR];

This results in a hard fault when you add more than two additional task priority numbers without changing UTIL_SEQ_CONF_PRIO_NBR.

Hello,
we are using release 1.0.0,
We have configured RTC as below using clock source as LSE.
But at every 24 hours time is increased with ~10 seconds.

Example :
Suppose at starting time if RTC time is 00 seconds.
After 1st 24 hours getting time 86410 approx.
After 2nd 24 hours getting time 172820 approx.

`void MX_RTC_Init(void)
{
RTC_AlarmTypeDef sAlarm = {0};

/** Initialize RTC Only
*/
hrtc.Instance = RTC;
hrtc.Init.AsynchPrediv = RTC_PREDIV_A;
hrtc.Init.OutPut = RTC_OUTPUT_DISABLE;
hrtc.Init.OutPutRemap = RTC_OUTPUT_REMAP_NONE;
hrtc.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH;
hrtc.Init.OutPutType = RTC_OUTPUT_TYPE_OPENDRAIN;
hrtc.Init.OutPutPullUp = RTC_OUTPUT_PULLUP_NONE;
hrtc.Init.BinMode = RTC_BINARY_ONLY;

if((RCC->BDCR & RCC_BDCR_RTCEN) == 0) //Init only on hard reset case
{
if (HAL_RTC_Init(&hrtc) != HAL_OK)
{
Error_Handler();
}

} else {
HAL_PWR_EnableBkUpAccess();

  /* RTC clock enable */
  __HAL_RCC_RTC_ENABLE();
  __HAL_RCC_RTCAPB_CLK_ENABLE();

  /* RTC interrupt Init */
  HAL_NVIC_SetPriority(TAMP_STAMP_LSECSS_SSRU_IRQn, 0, 0);
  HAL_NVIC_EnableIRQ(TAMP_STAMP_LSECSS_SSRU_IRQn);
  HAL_NVIC_SetPriority(RTC_Alarm_IRQn, 0, 0);
  HAL_NVIC_EnableIRQ(RTC_Alarm_IRQn);

}

/** Initialize RTC and set the Time and Date
/
if (HAL_RTCEx_SetSSRU_IT(&hrtc) != HAL_OK)
{
Error_Handler();
}
/* Enable the Alarm A
*/
sAlarm.BinaryAutoClr = RTC_ALARMSUBSECONDBIN_AUTOCLR_NO;
sAlarm.AlarmTime.SubSeconds = 0x0;
sAlarm.AlarmMask = RTC_ALARMMASK_NONE;
sAlarm.AlarmSubSecondMask = RTC_ALARMSUBSECONDBINMASK_NONE;
sAlarm.Alarm = RTC_ALARM_A;
if (HAL_RTC_SetAlarm_IT(&hrtc, &sAlarm, RTC_FORMAT_BCD) != HAL_OK)
{
Error_Handler();
}

}
`

Hi,
I am using WL55JC1 board with STM32CubeIDE. (SF=7 and BW=125)

I have modified the code from Applications/SubGHz_Phy/SubGHz_Phy_PingPong for LoRa-to-LoRa transmission.
On the receiver end, I am using duty cycle -
Radio.SetRxDutyCycle(((uint32_t)(2048000/ 15.625f)), ((uint32_t)(10240000/ 15.625f)));

I am using a long preamble (12 seconds) for the 1st packet sent by the transmitter. And short preamble for the rest of the packets.
The Semtech manual says that in duty cycle, when a "preamble is detected, the Receiver timeout is stopped and restarted with the value (2 * rxPeriod + sleepPeriod)." But in my case, somehow the timeout is restarted with a value = sleepPeriod (10.24 seconds) only. Due to this, before the complete preamble (12 seconds) is received, the board goes to sleep mode, and the packet is not received. And few subsequent packets are also dropped.
I am not sure why the Rx timeout is restarted with sleepPeriod, instead of (2 * rxPeriod + sleepPeriod).
Also, when I use Preamble time (= 9 seconds) < Sleep Period (10.24 seconds), I am able to receive the 1st packet. I have also tried StopTimerOnPreamble command, with this also I am able to receive the 1st packet.

So, not sure why after preamble detection, timeout is restarted with a value = sleepPeriod (10.24 seconds) instead of (2 * rxPeriod + sleepPeriod).

Set-up
LSM100A based Evaluation Kit (STM32WL55JC)
STM32CubeIDE Version: 1.10.1
https://github.com/SeongJiIoT/LSM100A_SDK

Description
Function RegionCommonUpdateBandTimeOff (RegionCommon.c) can lead to a Dead Lock (at least during retransmissions), if bands[i].TimeCredits == creditCosts because the band[i].ReadyForTransmission is then set to false but a minTimeToWait = 0 is returned.

In ScheduleTx (LoraMac.c) the MacCtx.DutyCycleWaitTime is checked for != 0 and the timer is then not started.

Pull Request (just a proposal)
#44
As an alternative the timer could be started with a minimal waiting time when MacCtx.DutyCycleWaitTime == 0

I have worked in 1_Image_BFU for STM32WL55xx and tested it in Linux minicom.
Your sample says it should be used 128B packets to send a firmware file on Linux minicom, but I couldn't see it's working.
Eventually minicom is using sb -vv of lrzsz for YMODEM. I thought sb -vv -k will be same like Tera Term on Windows. The option -k means 1KB packet. So I decided to use 1K packets on Linux.
There was an issue in SBSFU project (exactly in function SFU_COM_YMODEM_DataPktRxCpltCallback in sfu_com_loader.c) when using this YMODEM protocol.
You are counting the packets by 1KB, but YMODEM can send 128B packet to avoid the large padding for last 1KB packet.

You can read this in Chapter 1.2 YMODEM minimum requirements in YMODEM protocol reference
+ The receiving program must accept any mixture of 128 and 1024 byte blocks within each file it receives. Sending programs may arbitrarily switch between 1024 and 128 byte blocks.

Also mentioned in wikipedia
1024-byte packets had been introduced in XMODEM-1k. This version did not change the trigger character from the receiver, so there was no way for the sender to know whether the receiver supported larger packets. Instead, XMODEM-1k was presented as a separate protocol on both ends of the connection. When such a connection was started, the sender could choose to send either 1024 bytes in a packet or 128, indicating the larger with an STX character in the header rather than the normal SOH. Normally only the last few packets would use the smaller packets, to avoid sending large amounts of padding. 1k also assumed CRC for all connections. YAM supported 1k with no changes.

So I had to count the received bytes for the file, not packets, and then it worked well.
This might help someone who is using standard YMODEM without changing your sample code. :)

I'm using Nucleo-WL55JC1 and STM32CubeIDE 1.6.0. Building under Ubuntu 20.04.

Having cloned this repo, I successfully built and used the following two applications:

• https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Projects/NUCLEO-WL55JC/Applications/LoRaWAN/LoRaWAN_AT_Slave/STM32CubeIDE
• https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Projects/NUCLEO-WL55JC/Applications/LoRaWAN/LoRaWAN_End_Node/STM32CubeIDE

I'm now trying to use a FUOTA example, starting with 1_Image_SECoreBin:

• https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Projects/NUCLEO-WL55JC/Applications/LoRaWAN_FUOTA/1_Image_SECoreBin/STM32CubeIDE

However the build fails as follows:

/bin/sh: 1: ../prebuild.sh: not found

Searching the directory tree, I see that prebuild.sh is missing from all of the secure loading projects. Diving deeper, I see that the repository is missing all of the Bash .sh files. These files are present in the e.stm32cubewl_v1-1-0_v1.1.0.zip package that can be downloaded from the ST site. For example:

But absent from the repo:

I don't know if Linux is officially supported but I got it to work. Only problem was with some lower/upper-case file names. I had to edit these lines to use upper case "PLUS" to get it to work

  priorbin=$userAppBinary"/SBSFU_LoRaWAN_End_Node_DualCore_CM0PLUS.bin"
  priorbinadd=$userAppBinary"/SBSFU_LoRaWAN_End_Node_DualCore_CM0PLUS.bin.baseadd"

It doesn't appear to be used anywhere but this bug is in each board_resources.h file accross the application examples.

It appears in these locations:

Whenever I created a new project based on LoRaWAN Skeleton, it doesn't generate MX_GPIO_Init() in any file. This requires user to write their pin configuration manually, compared to the other project that are not based on LoRaWAN Skeleton where MX_GPIO_Init() is generated automatically.

Board:
STM32 Nucleo-WL55JC
Custom board based on STM32WL55CC

IDE:
STM32CubeIDE v1.7.0

Code Generator:
STM32CubeMX v6.3.0

STM32CubeWL package version:
v1.1.0

The code below is the main.c file, where I've done configuring my self-defined pin via STM32CubeMX. Because there is no MX_GPIO_Init(), I have to write it manually.

/* USER CODE BEGIN Header */
/**
  ******************************************************************************
  * @file           : main.c
  * @brief          : Main program body
  ******************************************************************************
  * @attention
  *
  * <h2><center>&copy; Copyright (c) 2021 STMicroelectronics.
  * All rights reserved.</center></h2>
  *
  * This software component is licensed by ST under Ultimate Liberty license
  * SLA0044, the "License"; You may not use this file except in compliance with
  * the License. You may obtain a copy of the License at:
  *                             www.st.com/SLA0044
  *
  ******************************************************************************
  */
/* USER CODE END Header */
/* Includes ------------------------------------------------------------------*/
#include "main.h"
#include "app_lorawan.h"

/* Private includes ----------------------------------------------------------*/
/* USER CODE BEGIN Includes */

/* USER CODE END Includes */

/* Private typedef -----------------------------------------------------------*/
/* USER CODE BEGIN PTD */

/* USER CODE END PTD */

/* Private define ------------------------------------------------------------*/
/* USER CODE BEGIN PD */
/* USER CODE END PD */

/* Private macro -------------------------------------------------------------*/
/* USER CODE BEGIN PM */

/* USER CODE END PM */

/* Private variables ---------------------------------------------------------*/

/* USER CODE BEGIN PV */

/* USER CODE END PV */

/* Private function prototypes -----------------------------------------------*/
void SystemClock_Config(void);
/* USER CODE BEGIN PFP */

/* USER CODE END PFP */

/* Private user code ---------------------------------------------------------*/
/* USER CODE BEGIN 0 */

/* USER CODE END 0 */

/**
  * @brief  The application entry point.
  * @retval int
  */
int main(void)
{
  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration--------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_LoRaWAN_Init();
  /* USER CODE BEGIN 2 */

  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */
    MX_LoRaWAN_Process();

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

/**
  * @brief System Clock Configuration
  * @retval None
  */
void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

  /** Configure LSE Drive Capability
  */
  HAL_PWR_EnableBkUpAccess();
  __HAL_RCC_LSEDRIVE_CONFIG(RCC_LSEDRIVE_LOW);
  /** Configure the main internal regulator output voltage
  */
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
  /** Initializes the CPU, AHB and APB busses clocks
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSE|RCC_OSCILLATORTYPE_MSI;
  RCC_OscInitStruct.LSEState = RCC_LSE_ON;
  RCC_OscInitStruct.MSIState = RCC_MSI_ON;
  RCC_OscInitStruct.MSICalibrationValue = RCC_MSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.MSIClockRange = RCC_MSIRANGE_11;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  /** Configure the SYSCLKSource, HCLK, PCLK1 and PCLK2 clocks dividers
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK3|RCC_CLOCKTYPE_HCLK
                              |RCC_CLOCKTYPE_SYSCLK|RCC_CLOCKTYPE_PCLK1
                              |RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_MSI;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
  RCC_ClkInitStruct.AHBCLK3Divider = RCC_SYSCLK_DIV1;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK)
  {
    Error_Handler();
  }
}

/* USER CODE BEGIN 4 */

/* USER CODE END 4 */

/**
  * @brief  This function is executed in case of error occurrence.
  * @retval None
  */
void Error_Handler(void)
{
  /* USER CODE BEGIN Error_Handler_Debug */
  /* User can add his own implementation to report the HAL error return state */
  __disable_irq();
  while (1)
  {
  }
  /* USER CODE END Error_Handler_Debug */
}

#ifdef  USE_FULL_ASSERT
/**
  * @brief  Reports the name of the source file and the source line number
  *         where the assert_param error has occurred.
  * @param  file: pointer to the source file name
  * @param  line: assert_param error line source number
  * @retval None
  */
void assert_failed(uint8_t *file, uint32_t line)
{
  /* USER CODE BEGIN 6 */
  /* User can add his own implementation to report the file name and line number,
     ex: printf("Wrong parameters value: file %s on line %d\r\n", file, line) */
  /* USER CODE END 6 */
}
#endif /* USE_FULL_ASSERT */

/************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/

Hello,

STM32WL dual core is using M0+ and M4. GIT release v1.0.0 has firmware for both.
but when we compiled the M0+ "LoRaWAN_End_Node_DualCore" source binary size is unexpectedly too large
Bin size: 393126Kb
ELF size: 2588Kb
Hex size: 196Kb

Now to reduce the size of binary i've made changes in .ld file,

after .ld file change, binary size is reduced in KB

We have a custom PCB with the stm32wl55 MCU, and for the most part, the reference design was followed. However the LSE crystal was not added.

I have updated the example code and enabled the LSI clock source.

For my application, we are using OTAA.

The join request is received by the gateway and responds to it. However, my end node does not receive the response.

I have tested with the nucleo-wl55 dev board with the LSI clock and disable the LSE clock source the device fails to join, However once enable the LSE clock source the device joins succesfully

IDE used: STM32CubeIDE 1.10.1

Hello there,
I am trying to compile the SBSFU_2_Images_DualCore project.
Although I did it in the correct order according to the document "Getting started with the SBSFU of STM32CubeWL (UM2767)". I am getting a compiler error.

I'm sure that, compiling the correct order according to Getting started with the SBSFU of STM32CubeWL (UM2767)

Compile order is;

2_Images_SECoreBin - compile success
2_Images_KMS_Blob - compile success
2_Images_SBSFU
2_Images_SBSFU_CM0PLUS - compile success
2_Images_SBSFU_CM4) - compile success
2_Images_UserApp_CM4 - compile success
2_Images_UserApp_CM0PLUS - compiler error

The error is multiple definition error .

c:\st\stm32cubeide_1.6.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o: in function `SE_KMS_CloseSession':

(.SE_IF_Code+0xbd8): multiple definition of `SE_KMS_CloseSession'; ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o:(.SE_IF_Code+0xbd8): first defined here

c:\st\stm32cubeide_1.6.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o: in function `SE_KMS_DigestInit':

(.SE_IF_Code+0x121c): multiple definition of `SE_KMS_DigestInit'; ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o:(.SE_IF_Code+0x121c): first defined here

c:\st\stm32cubeide_1.6.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o: in function `SE_KMS_EncryptInit':

(.SE_IF_Code+0xedc): multiple definition of `SE_KMS_EncryptInit'; ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o:(.SE_IF_Code+0xedc): first defined here

c:\st\stm32cubeide_1.6.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o: in function `SE_KMS_DestroyObject':

(.SE_IF_Code+0xc94): multiple definition of `SE_KMS_DestroyObject'; ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o:(.SE_IF_Code+0xc94): first defined here

c:\st\stm32cubeide_1.6.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_1.5.0.202011040924\tools\arm-none-eabi\bin\ld.exe: ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o: in function `SE_KMS_Encrypt':

(.SE_IF_Code+0xf3c): multiple definition of `SE_KMS_Encrypt'; ../../../2_Images_SBSFU/STM32CubeIDE/CM0PLUS/Debug\se_interface_app.o:(.SE_IF_Code+0xf3c): first defined here

I didn't do any code change. I just downloaded and opened in STM32CubeIde.

Is this related with STM32Cube_FW_WL_V1.0.0 ?

What's wrong ?

Symptom

A LoRaWAN application uses the trace utility to send and receive bytes on UART2. Bytes are sent using DMA TX with UTIL_ADV_TRACE_COND_FSend(), while reception uses RX interrupt, as configured by UTIL_ADV_TRACE_StartRxProcess(). When the application code requests to send a trace message, and a byte is received "at the same time", the RX interrupt is disabled. Consequence: the application can't received any further bytes.

Source of the problem

HAL_UART_Transmit_DMA() calls __HAL_LOCK(huart) before preparing the transmission.

When a byte is received, UART_RxISR_8BIT() is called. UART_RxISR_8BIT() calls HAL_UART_RxCpltCallback(). HAL_UART_RxCpltCallback() calls HAL_UART_Receive_IT(), in order to restart the RX on interrupt. HAL_UART_Receive_IT() calls __HAL_LOCK(huart) before configuring the RX.

If the byte is received while HAL_UART_Transmit_DMA() has just called __HAL_LOCK(huart) but not called __HAL_UNLOCK(huart) yet, then __HAL_LOCK(huart) in HAL_UART_Receive_IT() performs a return, without re-enabling RX on interrupt.

No further RX is possible.

Workaround

Following modification of vcom_Trace_DMA() prevents the problem from appearing:

    UTIL_ADV_TRACE_Status_t vcom_Trace_DMA(uint8_t *p_data, uint16_t size)
    {
      // Disable USART interrupts while starting the DMA TX otherwise an RX
      // interrupt could happen while USART's data is locked, and RXNEIE would
      // be left reset.
      HAL_NVIC_DisableIRQ(USARTx_IRQn);
      HAL_UART_Transmit_DMA(&huart2, p_data, size);
      HAL_NVIC_EnableIRQ(USARTx_IRQn);
      return UTIL_ADV_TRACE_OK;
    }

But I don't know whether this is the right solution.

Hello,

I am using STM32WLE5CC with STM32Cube Studio 1.8.0.

I am using M95512 SPI EEPROM, and SSD1306 I2C Oled.

I can communicate with both peripheral and all works perfect.

Our project is of Counting Reed switch pulse from external Meter. Pulse can occur any time.

We faced below 2 issues:

1. when Reading/using SPI or I2C Peripheral, and External interrupt trigger, MCU stucks.

2. when Reset/Reboot occurs and have External Interrupt trigger, then MCU stucks.

MCU stucks in a situation where its recovery is only possible with reset, or watchdog reset. But watchdog is not a solution as it will miss pulse reading count.

We also observed that MCU doesn't stck in Error_hanlder() function.

Also, We are not using SPI/I2C interrupt. We use polling method for SPI/I2C communication.

Please help us as soon as possible.

Thank You

Hi there.
I'm trying to run LoRa (NOT LoRaWAN) application. I even ran SubGHz_Phy_PingPong example code with no problem. I try to use my standard LoRaWAN gateway to follow up LoRa packets, but the thing is, my gateway couldn't recognize packets even though two stm32Nucleos can recognize each other's packets.

If the SubGHz_Phy_PingPong example uses standard LoRa modulation(tell me if it doesn't), my gateway should recognize packets as proprietary LoRa packets. I think there is a bug on setting up LoRa modulation in SubGHz_Phy_PingPong example.

Do you have any suggestion for me or even same experience?

with best regards
iman

Set-up
LSM100A based Evaluation Kit (STM32WL55JC)
STM32CubeIDE Version: 1.10.1
https://github.com/SeongJiIoT/LSM100A_SDK

Description
After piggy-pack a link check request RxParams.LinkCheck is set during rx processing. But this flag is never cleared afterwards.
From then on each time a downlink message is received the DMODM and GWN parameters are printed to serial in AT_event_receive().

I'd suppose to clear the flag in LmHandlerProcess() right before the actual processing.

if I'm trying to compile the LoRaWAN_End_Node_DualCore project. I compiled the LoRaWAN_End_Node_DualCore_CM4 project. However, I cannot compile the LoRaWAN_End_Node_DualCore_CM0PLUS project.

Compiler error is;
/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.macos64_1.5.0.202011040924/tools/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: **LoRaWAN_End_Node_DualCore_CM0PLUS.elf section .text will not fit in region ROM'
/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.macos64_1.5.0.202011040924/tools/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: region `ROM' overflowed by 7240 bytes
collect2: error: ld returned 1 exit status
make: *** [makefile:76: LoRaWAN_End_Node_DualCore_CM0PLUS.elf] Error 1
"make -j7 all" terminated with exit code 2. Build might be incomplete.

I have been trying to work with the sequencer (tasks and events) for a few days already, but I can not understand, in totality, the way it works. Is there any document, video or good example to learn more about it?

Setup:

• LoRa-E5-STM32WLE5JC
• GNU Arm Embedded Toolchain 10.3-2021.10

Bug:
Preprocessor error is not triggered if the CFG_SEQ_Task_NBR is > 32 although there is a code to protect it

#if UTIL_SEQ_CONF_TASK_NBR > 32
#error "UTIL_SEQ_CONF_PRIO_NBR must be less of equal then 32"
#endif

It happens because the #define UTIL_SEQ_CONF_TASK_NBR CFG_SEQ_Task_NBR is evaluated by preprocessor to zero. It doesn't know the value of CFG_SEQ_Task_NBR at this stage. Try to add -Wundef flag and see the compiler output

Next when there is a preprocessor macro #if UTIL_SEQ_CONF_TASK_NBR > 32 we copmare 0 > 32

Also there is a typo in the error message: UTIL_SEQ_CONF_TASK_NBR must be less of equal then 32

Hi,

We are using using https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Projects/NUCLEO-WL55JC/Applications/LoRaWAN/LoRaWAN_End_Node to migrate our existing project from STM32L073, Its quite easy to enable LowPowerMode mode in https://github.com/Lora-net/LoRaMac-node/blob/2d5b3f05f31c47ff0f06530c51727ab7e5fe2405/src/apps/LoRaMac/classA/NucleoL073/main.c#L1215

Can you please let us know how to enable LowPowerMode in STM32WL (https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Projects/NUCLEO-WL55JC/Applications/LoRaWAN/LoRaWAN_End_Node)

Thanks

Describe the set-up

• A project using the CRYP HAL driver from STM32CubeWL

Describe the bug
The functions: HAL_CRYP_SetConfig and HAL_CRYP_GetConfig don't initialize all parameters of the CRYP_ConfigTypeDef struct. HeaderWidthUnit and KeyIVConfigSkip are not initialized.

See:

How To Reproduce
Encrypt or decrypt data using GCM or CCM Mode with a given HeaderWidthUnit different from CRYP_HEADERWIDTHUNIT_WORD.
This will lead to wrong Tag calculation in AEAD algorithms because the HAL multiplies the given header length by 4 and calculates the Additional Authenticated Data over a too big range.

Set-up
LSM100A based Evaluation Kit (STM32WL55JC)
STM32CubeIDE Version: 1.10.1
https://github.com/SeongJiIoT/LSM100A_SDK

Description
After ADR changed the data rate for example to DR5 and then a new JOIN request is issued, the wrong DR is shown in the event output:

AT+JOIN=1
OTAA mode
1933s038:TX on freq 868500000 Hz at DR 0 and 13 dBm
OK
1934s819:MAC txDone
1939s705:RX_1 on freq 868500000 Hz at DR 0
1941s169:MAC rxDone
+EVT:JOINED
+EVT:RX_1, DR 5, RSSI -85, SNR 5

This is because the RxParams.Datarate field is only updated in McpsIndication() but not in MlmeIndication().

I'd suppose to move the Datarate field from McpsIndication_t to LoRaMacRxStatus_t and use this where applicable and in addition in MlmeIndication():

static void MlmeIndication( MlmeIndication_t *mlmeIndication, LoRaMacRxStatus_t *RxStatus )
{
    RxParams.IsMcpsIndication = 0;
    RxParams.Status = mlmeIndication->Status;
    RxParams.Datarate = RxStatus->RxDatarate;
    RxParams.Rssi = RxStatus->Rssi;
    RxParams.Snr = RxStatus->Snr;
    ...

Hi,

I've been working on evaluating different scenarios for a device which is not able to join a network immidiately and during my tests I found out that LmHandlerJoin can only be called a fixed number of times ( 13 ). And I'm not quite sure why. My join callback looks like the one below:

static void OnJoinRequest(LmHandlerJoinParams_t *joinParams)
{

    if ( joinParams != NULL )
    {
        if ( joinParams->Status == LORAMAC_HANDLER_SUCCESS )
        {
            ALOG ( "Network join success!" );
        }
        else
        {
            ALOG ( "Network join failed!" );
            ALOGP( "Restarting join process, retry %d ", ( ++retries ) );
            LmHandlerJoin(lmhandler_activation_type);
        }
    }
}

and the log looks like this

0:029 APP       : Starting join process.
7:755 APP       : Network join failed!
7:755 APP       : Restarting join process, retry 1
15:479 APP       : Network join failed!
15:479 APP       : Restarting join process, retry 2
23:203 APP       : Network join failed!
23:203 APP       : Restarting join process, retry 3
30:926 APP       : Network join failed!
30:926 APP       : Restarting join process, retry 4
38:650 APP       : Network join failed!
38:650 APP       : Restarting join process, retry 5
46:374 APP       : Network join failed!
46:374 APP       : Restarting join process, retry 6
54:097 APP       : Network join failed!
54:097 APP       : Restarting join process, retry 7
61:821 APP       : Network join failed!
61:821 APP       : Restarting join process, retry 8
69:544 APP       : Network join failed!
69:544 APP       : Restarting join process, retry 9
77:268 APP       : Network join failed!
77:268 APP       : Restarting join process, retry 10
84:992 APP       : Network join failed!
84:992 APP       : Restarting join process, retry 11
92:715 APP       : Network join failed!
92:715 APP       : Restarting join process, retry 12

Is this a restriction of the stack itself ? I don't quite understand the reasoning behind this, if the reason is to restrict some rogue device from spamming the network, you can always perform a reboot and continue spamming. The restriction is not time-dependant either because I've tested calling LmHandlerJoin with increasing timeout ( varying from tens of seconds to tens of minutes + some random interval ) with the same effect.

After calling vcom_Init, the UART receiver is configured and ready to receive data. The problem is that when you later call vcom_ReceiveInit, the UART receiver might have already received some data and might also have raised an overrun error flag. So when you call HAL_UART_Receive_IT in vcom_ReceiveInit, the error interrupt enable flag is set and an error interrupt might be immediately triggered due to a possible unhandled overrun error. According to the HAL UART implementation, an overrun error is a blocking error, and the Rx interrupt handling will be stopped. Even if you implement the HAL_UART_ErrorCallback and restart the Rx process in the error callback, it won't work because HAL_UART_Receive_IT in vcom_ReceiveInit will lock the UART handle resource by __HAL_LOCK and the HAL_UART_Receive_IT in the HAL_UART_ErrorCallback will encounter a locked handle resource.

void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart) {
        if (huart->Instance==USART2) {
		if ((huart->ErrorCode & HAL_UART_ERROR_ORE) != 0) {
			HAL_UART_Receive_IT(&huart2, &charRx, 1);
		}
	}
}

FIX: At least clear the overrun ISR flag after polling the USART_ISR_BUSY in vcom_ReceiveInit and before starting the Rx interrupt handling by HAL_UART_Receive_IT.

UTIL_ADV_TRACE_Status_t vcom_ReceiveInit(void (*RxCb)(uint8_t *rxChar, uint16_t size, uint8_t error))
{

 ...

  /* Make sure that no UART transfer is on-going */
  while (__HAL_UART_GET_FLAG(&huart2, USART_ISR_BUSY) == SET);

  /* FIX */
  __HAL_UART_CLEAR_FLAG(&huart2, (UART_CLEAR_PEF | UART_CLEAR_FEF | UART_CLEAR_NEF | UART_CLEAR_OREF));
  __HAL_UART_SEND_REQ(&huart2, UART_RXDATA_FLUSH_REQUEST);

  /* Make sure that UART is ready to receive)   */
  while (__HAL_UART_GET_FLAG(&huart2, USART_ISR_REACK) == RESET);

...

  /*Start LPUART receive on IT*/
  HAL_UART_Receive_IT(&huart2, &charRx, 1);

...

}

Best regards
Roman Jasmann

Hi,

As per LoRa Spec:
When an end-device attempts the transmission of a "confirmed" frame toward the network it expects to receive an acknowledgement in one of the subsequent reception slot. In the absence of the acknowledgement it will try to re-transmit the same data again. Re-transmission happens on a new frequency channel, but can also happen at a different data rate (preferable lower) than the previous one.

It is strongly recommended to adopt the re-transmission strategy as stated in the LoRaWAN specification, Section 18.4:

Above should also apply to the "JOIN request Retransmission" but STM32WLE release 1.1.0 using same data rate for all the JOIN request Retransmission. Working on IN865 and EU868 and identify this problem. Possibly it is also same in other region too.

Logs are attached for are details
joinRequestLogs.txt

Set-up
LSM100A based Evaluation Kit (STM32WL55JC)
STM32CubeIDE Version: 1.10.1
https://github.com/SeongJiIoT/LSM100A_SDK

Description
Quite often the RadioRandom() function returns 0 which leads e.g. to a devnonce = 0 and breaking a JOIN request.
For my setup it is reproducable by issuing a JOIN request right after a successful JOIN.

I tracked this down to insufficient waiting time in SUBGHZ_WaitOnBusy().
The initialization of the count variable with the MACROS SUBGHZ_RFBUSY_LOOP_TIME*SUBGHZ_DEFAULT_TIMEOUT seems wrong: Comment near SUBGHZ_DEFAULT_TIMEOUT mentions "HAL Timeout in ms" but the actual timeout is in the range of 100 microseconds.
In my tests the maximum waiting time observed had been near 90000 cycles but the count variable is intialized with 36600.

If the Radio still reports busy when the random rx data is about to be retrieved, an error is reported, but not signalled to upper layer. Instead the random number is just filled with 0.

There's a chance my problem is only related to my SeongJi setup.

Sanity check in OnRxData function uses the wrong logic operator, should be && + AppData has a Buffer, pointer member in the struct which can be NULL, and it is not checked.

static void OnRxData(LmHandlerAppData_t *appData, LmHandlerRxParams_t *params)
{
  /* USER CODE BEGIN OnRxData_1 */
  if ((appData != NULL) || (params != NULL))
  ....

Line

Hi,

During the testing we have found something interesting. During the Join procedure device is using Network key instead of AppKey
As per the LoRA spec device must use AppKey to generate message integrity code(MIC).

we have found this when we have change the appkey of device and used same in server as appkey, after the changes we are seeing MIC failure in join request.
Please help to understand why Network Key is in use for join procedure?

According to STM32CubeMX release notes this package had V1.2.0 release on 04-February-2022
Could you also update this repository?

The error handling code below does not cover all the error scenarios in case LmHandlerSend fails to emit payload.

LmHandlerSend

  if (LORAMAC_HANDLER_SUCCESS == LmHandlerSend(&AppData, LORAWAN_DEFAULT_CONFIRMED_MSG_STATE, &nextTxIn, false))
  {
    APP_LOG(TS_ON, VLEVEL_L, "SEND REQUEST\r\n");
  }
  else if (nextTxIn > 0)
  {
    APP_LOG(TS_ON, VLEVEL_L, "Next Tx in  : ~%d second(s)\r\n", (nextTxIn / 1000));
  }

The intention behind this piece of code is understandable, if LmHandlerSend fails to emit payload due to Duty Cycle restriction the user will be notified and can take appropriate action. I've tested exactly this scenario by forcing the device to operate under fixed DR and spamming the LmHandlerSend with data more rapidly than the duty cycle restriction, the code actually never hits the else if part.

This is actually visible from within the LmHandlerSend which may return an error quite immediately before event modifying the supplied nextTxIn pointer.

What actually happens is LmHandlerSend may return an error first with nextTxIn = 0 which is not caught by the code above, but on the next call will emit an nextTxIn with value above zero.

I believe that the code above should be modified to

  if (LORAMAC_HANDLER_SUCCESS == LmHandlerSend(&AppData, LORAWAN_DEFAULT_CONFIRMED_MSG_STATE, &nextTxIn, false))
  {
    APP_LOG(TS_ON, VLEVEL_L, "SEND REQUEST\r\n");
  }
  else
  {

    if ( nextTxIn == 0 )
      APP_LOG(TS_ON, VLEVEL_L, "SEND REQUEST FAILED\r\n");
    else
      APP_LOG(TS_ON, VLEVEL_L, "SEND REQUEST FAILED, next tx in : ~%d seconds\r\n",
        nextTxIn / 1000 );
  }

This will capture any possible error scenario from LmHandlerSend return code

Hi,

I'm using STM32WLE5JCI6 based LORA module. I need to used the software reset. using v1.0.0 release.
I tried the “HAL_NVIC_SystemReset()” provided with source, but most of the times it doesn’t work,

• 1 out of 3 times, the reset is working and the board restart correctly,
• 2 out of 3 times, the call to “HAL_NVIC_SystemReset()” freezing the microcontroller. Nothing can be done any more except hardware reset.

Is this a known problem? is there any solution for this problem?

According to the reference manual (RM0453) page 1395, we have the following:

• ITM trace enable register (ITM_TER) offset: 0x080
• ITM trace privilege register (ITM_TPR) offset: 0xE00.

As far as I can tell, this does not match the offsets used in the CMSIS header. Not sure if this is an issue with the reference manual, or the header though.

ITM trace control register (ITM_TCR) has an offset which matches the CMSIS. I have not checked the rest of the registers in the ITM.

Release 1.1.0 of this STM32CubeWL package incorporates LoRaMAC 4.4.7. The LoRaMAC project recently added support for Class B multicast setup: Lora-net/LoRaMac-node@d29f8d4

This shipped in LoRaMAC 4.6.0. Could you please make a new release of this project that includes LoRaMAC 4.6.0?

After radio.init called, we called the radio.rx(0xffffff) for into the rx mode , but when I test it ,I found the switching time is 10ms.

the code like this:

tick1 = HAL_Gettick();
Radio.Rx(0xFFFFFF);
tick2 - HAL_Gettick();
printf(“switch time = %d\n”,tick2-tick1);

Setup:

LoRa-E5-STM32WLE5JC
GNU Arm Embedded Toolchain 10.3-2021.10

Suggestion:
Minor thing I noticed. In lora_info_template.c and all of the lora_info.c files in examples, part of loraInfo struct is uninitialized.
According to the struct declaration it has 4 members but when it is created it has only two first members set to zero:
static LoraInfo_t loraInfo = {0, 0};

However, all members are set to zero in Init function (I think the structure isn't accessed before this init). This makes my suggestion really cosmetic thing.

void LoraInfo_Init(void)
{
  loraInfo.ActivationMode = 0;
  loraInfo.Region = 0;
  loraInfo.ClassB = 0;
  loraInfo.Kms = 0;
...

Solution:
static LoraInfo_t loraInfo = {0};

Describe the set-up

• Seeed Studio LoRa-E5 chip
• gcc version 10.3.0

Describe the bug
The defines for the DBGMCU_CR register are missing for the TRACE_IOEN and TRACE_MODE bits. This is actually consistent with the reference manual RM0461 Rev 4 page 1284 where those bits also do not appears. However the reference manual definitely talk about the TRACE_SWO functionality in other places of the manual, and especially in section 36.

Now taking the bit definitions for this register from the STM32L4 (from which I am migrated my design), I can get the SWO functionality working perfectly. It therefore seems that this is only a documentation and header issue.

The SysTimeLocalTime() function in the stm32_systime module fills in wrong month in the struct. Precisely, it calls CalendarGetMonth, which, if it's August or a subsequent, gets the month off by one. For example, it gets July correctly as 7, then August as 7 again, September as 8 and so on.

The CalendarGetMonth itself is easy to fix, but after its call the day of the year is calculated, and the math there depends on the month value. The day calculation works fine as it is, but if a correct month is fed, it gets the day incorrect.

There is some fancy math in the functions so a proper fix would not be straightforward. Suggest some workaround e.g. change 7 to 8 in the CalendarGetMonth, then conditionally pass decremented value to the day calculation statement.

Hi,

I've been playing around with STM32CubeWL using Nucleo-64 (STM32WL55). The default LoRaWan applications seem to work correctly against TTI stack, but when I tried to make my own using Projects/NUCLEO-WL55JC/Applications/LoRaWAN/LoRaWAN_End_Node/ as basis things didn't work as expected

The main issue I'm having is that if have the most basic initialization code :

static uint8_t app_eui[] = { ... };
static uint8_t dev_eui[] = { ... };
static uint8_t app_key[] = { ... };

void APP_Init ( void )
{
    /* Register LmHandler task */
    UTIL_SEQ_RegTask(   (1 << CFG_SEQ_Task_LmHandlerProcess),
                        UTIL_SEQ_RFU,
                        LmHandlerProcess,
                        0);

    /* Initialize LoRaMac */
    LoraInfo_Init();
    LmHandlerInit(&lmhandler_callbacks);
    LmHandlerConfigure(&lmhandler_params);

    /* Set credentials */
    LmHandlerSetAppEUI(app_eui);
    LmHandlerSetAppKey(app_key);
    LmHandlerSetDevEUI(dev_eui);

    /* Start Join Process */
    LmHandlerJoin(lmhandler_activation_type);

}

And I provision the device with abovementioned keys in TTI I'm getting a MIC MISMATCH and no join will occur, but as soon as the line containing LmHandlerSetAppKey(app_key); is removed and APP KEY in backend is substituted with the one from LoRaWAN_End_Node/LoRaWAN/App/se-identity.h everything is fine.

So my question is :

Why define and implement LmHandlerSetAppKey() when this function simply is useless ?

Describe the set-up

• Custom board populated with the STM32WLE5.
• Keil MDK-ARM V5.36.0.0.
• 8 devices running in LoRaWAN class C.

Describe the bug (skip if none)

If a Radio IRQ occurs during HAL_SUBGHZ_ExecSetCmd, it will cause an infinite re-entering of the Radio IRQ handler.

In LoRaWAN class C, the transceiver operates most of the time in Rx. When the transceiver is in Rx and the application requests an uplink, the LoRaWAN stack will serve the uplink request by first stopping the Rx mode and setting the transceiver in standby mode by calling RadioStandby in RadioSetTxConfig. RadioStandby will call SUBGRF_SetStandby and SUBGRF_SetStandby will call HAL_SUBGHZ_ExecSetCmd. HAL_SUBGHZ_ExecSetCmd will lock the subghz handle by __HAL_LOCK(hsubghz). If a Radio IRQ occurs during HAL_SUBGHZ_ExecSetCmd, e.g. triggered by reception of a packet, then the SUBGHZ_Radio_IRQHandler will be called. The SUBGHZ_Radio_IRQHandler will call HAL_SUBGHZ_IRQHandler. The HAL_SUBGHZ_IRQHandler will try to retrieve the interrupt source from the transceiver by calling HAL_SUBGHZ_ExecGetCmd, but HAL_SUBGHZ_ExecGetCmd will return immediately since it cannot lock the subghz handle. The subghz handle has already been locked by HAL_SUBGHZ_ExecSetCmd. At the end of HAL_SUBGHZ_IRQHandler, the handler will try to clear the interrupt request by calling HAL_SUBGHZ_ExecSetCmd, but HAL_SUBGHZ_ExecSetCmd will also return immediately since it cannot lock the subghz handle. The result is that the radio IRQ won't be cleared, causing a re-entering of SUBGHZ_Radio_IRQHandler immediately after exiting it.

Screenshots

Best regards
Roman Jasmann

According to the documentation from Application Note AN5554:

The FUOTA application supports a full firmware upgrade image (entire firmware image sent to the end device) only runs on STM32WL55xx target

Is this related to the documentation sheet or for FUOTA in general? It is a little bit confusing for me, because STM32WL55xx is DualCore series, but in this repository there is an FUOTA example application for single core. So FUOTA should work with single core and therefore with STM32WLE5 series?

Hello,

From new release of STM32WL i'm using SigFox_AT_Slave Application. But Application shows compilation error.
I can compile SigFox_AT_Slave of 1.0.0 release into my setup. so, it is not related to setup issues.
From the error looks like some files are missing in Sigfox source which require in order to compile the sigfox application.
Attaching the error for more details.

using IDE version 1.7.0

Hello, I would like to report a bug using STM32CubeWL code for LoRaWAN end node dual core application. I'm using a NUCLEO-WL55JC1 with cube IDE.

I was trying to receive downlink message in order to toggle a LED. Radio communication did well but the payload was badly transmit to CM0 to CM4. Any message received given only the value 1.

After some research I corrected it by modifying LmHandler_mbwrapper.c line 708 in CM0+ project

original code is : next_addr = (appData->BufferSize + 7) & ~ 7;

I modify it as : next_addr += (appData->BufferSize + 7);

Hope it could help someone with the same issue

Caution
The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools, or the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

• The board (either ST RPN reference or your custom board).
  NUCLEO WL55JC1
• IDE or at least the compiler and its version.
  STM32CubeIDE Version: 1.5.1Build: 9029_20201210_1234 (UTC)

Describe the bug
The timer during the monarch scan ends prematurly

How To Reproduce

1. Indicate the global behavior of your application project.

• compile and load Sigfox_AT_Slave
• connect to serial
• execute AT$MN=300 command (beacons are emitted every 300 seconds)
  '''
  10s300:RF_API_init in MN20
  10s301:MONARCH_TIM_START: 300 ms
  10s302:MN Init
  10s602:MN Deinit
  10s602:MONARCH_TIM_STOP
  10s602:RF_API_stop
  NO RC found
  '''
  the timer is wrongly set to 300ms instead of 300s

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).

mn_api.c >> MN_API_TimerSart
line 277 : UTIL_TIMER_SetPeriod(&Monarch_TimerTimeout, timer_value_ms);
the value passed to the function is in seconds while the timer expect ms
multplying the timer by 1000 fixes the issue

I am using STM Cube IDE for developement of the LoRa E5 development board which has the STM32wle5jc module in it. Since there is no example code for this board on the cube ide, i wanted to adapt the Subghz Ping Pong code for my board's pinout. The board gets disconnected from the debugger when we let LOW_POWER_DISABLE be 0 in sys_conf.h file. To debug it we have to set it to 1. Now when I ran the code step by step in the debug mode, I did not find the PingPong_Process being called repeatedly in the while(1){} loop of the code. This function is responsible to transmit and receive the ping or pong msg. Can someone help me on this?

Setup:

LoRa-E5-STM32WLE5JC
GNU Arm Embedded Toolchain 10.3-2021.10

Bug:

USE_LRWAN_1_1_X_CRYPTO is not recognized in LoRaMacTypes.h and evaluates to zero. eKeyIdentifier enum values are always the same. This is not the only error when I set USE_LRWAN_1_1_X_CRYPTO
Setting #define USE_LRWAN_1_1_X_CRYPTO in LoRaMacCrytpo.h to 1 results in following error:

In file included from Middlewares/Third_Party/LoRaWAN/Crypto/soft-se.c:55:
LoRaWAN/App/se-identity.h:175:25: error: 'J_S_INT_KEY' undeclared here (not in a function)
  175 |             .KeyID    = J_S_INT_KEY,                                                                                \
      |                         ^~~~~~~~~~~
LoRaWAN/App/se-identity.h:383:9: note: in expansion of macro 'SESSION_KEYS_LIST'
  383 |         SESSION_KEYS_LIST                                                                                           \
      |         ^~~~~~~~~~~~~~~~~
Middlewares/Third_Party/LoRaWAN/Crypto/soft-se.c:118:14: note: in expansion of macro 'SOFT_SE_KEY_LIST'
  118 |   .KeyList = SOFT_SE_KEY_LIST
      |              ^~~~~~~~~~~~~~~~
LoRaWAN/App/se-identity.h:184:25: error: 'J_S_ENC_KEY' undeclared here (not in a function)
  184 |             .KeyID    = J_S_ENC_KEY,                                                                                \
      |                         ^~~~~~~~~~~
LoRaWAN/App/se-identity.h:383:9: note: in expansion of macro 'SESSION_KEYS_LIST'
  383 |         SESSION_KEYS_LIST                                                                                           \
      |         ^~~~~~~~~~~~~~~~~
Middlewares/Third_Party/LoRaWAN/Crypto/soft-se.c:118:14: note: in expansion of macro 'SOFT_SE_KEY_LIST'
  118 |   .KeyList = SOFT_SE_KEY_LIST
      |              ^~~~~~~~~~~~~~~~
LoRaWAN/App/se-identity.h:193:25: error: 'F_NWK_S_INT_KEY' undeclared here (not in a function)
  193 |             .KeyID    = F_NWK_S_INT_KEY,                                                                            \
      |                         ^~~~~~~~~~~~~~~
LoRaWAN/App/se-identity.h:383:9: note: in expansion of macro 'SESSION_KEYS_LIST'
  383 |         SESSION_KEYS_LIST                                                                                           \
      |         ^~~~~~~~~~~~~~~~~
Middlewares/Third_Party/LoRaWAN/Crypto/soft-se.c:118:14: note: in expansion of macro 'SOFT_SE_KEY_LIST'
  118 |   .KeyList = SOFT_SE_KEY_LIST
      |              ^~~~~~~~~~~~~~~~
LoRaWAN/App/se-identity.h:201:25: error: 'S_NWK_S_INT_KEY' undeclared here (not in a function)
  201 |             .KeyID    = S_NWK_S_INT_KEY,                                                                            \
      |                         ^~~~~~~~~~~~~~~
LoRaWAN/App/se-identity.h:383:9: note: in expansion of macro 'SESSION_KEYS_LIST'
  383 |         SESSION_KEYS_LIST                                                                                           \
      |         ^~~~~~~~~~~~~~~~~
Middlewares/Third_Party/LoRaWAN/Crypto/soft-se.c:118:14: note: in expansion of macro 'SOFT_SE_KEY_LIST'
  118 |   .KeyList = SOFT_SE_KEY_LIST
      |              ^~~~~~~~~~~~~~~~
LoRaWAN/App/se-identity.h:210:25: error: 'NWK_S_ENC_KEY' undeclared here (not in a function); did you mean 'NWK_S_KEY'?
  210 |             .KeyID    = NWK_S_ENC_KEY,                                                                              \
      |                         ^~~~~~~~~~~~~
LoRaWAN/App/se-identity.h:383:9: note: in expansion of macro 'SESSION_KEYS_LIST'
  383 |         SESSION_KEYS_LIST                                                                                           \
      |         ^~~~~~~~~~~~~~~~~
Middlewares/Third_Party/LoRaWAN/Crypto/soft-se.c:118:14: note: in expansion of macro 'SOFT_SE_KEY_LIST'
  118 |   .KeyList = SOFT_SE_KEY_LIST
      |              ^~~~~~~~~~~~~~~~

Fix:
Remove #if USE_LRWAN_1_1_X_CRYPTO statements from the eKeyIdentifier enum.