2025-08-21 1:03 AM
Hello,
I'm having trouble building a LoRaWAN project targeting the STM32WLE5JCI6. The same error occurs even on a clean, newly created project, which leads me to believe there might be a compatibility issue between the IDE and the software package.
■ The error I'm facing:
../Middlewares/Third_Party/LoRaWAN/Mac/LoRaMac.c: In function 'ProcessRadioRxDone': ../Middlewares/Third_Party/LoRaWAN/Mac/LoRaMac.c:1650:40: error: 'McpsIndication_t' {aka 'struct sMcpsIndication'} has no member named 'ResponseTimeout'
This error indicates that LoRaMac.c is trying to access the ResponseTimeout member of the McpsIndication_t struct, but the corresponding LoRaMac.h file lacks that definition.
■ My setup:
Target MCU: STM32WLE5JCI6
STM32CubeIDE Version: 1.19.1 (Clean install from the official website)
STM32CubeWL Package: Latest version (Installed via the IDE's package manager)
■ Steps I have already taken:
Cleanly reinstalled both STM32CubeIDE and the STM32CubeWL package.
Deleted the old project and workspace, then created a new project from scratch in a new workspace.
The project was generated with default settings, with only the LoRaWAN stack enabled.
■ My findings:
The LoRaMac.h file within my new project folder does not contain the definition for the ResponseTimeout member.
The latest LoRaMac-node repository on GitHub, however, does include this definition.
■ My question:
Is this a known issue with the combination of the latest STM32CubeIDE and STM32CubeWL package? If you know of a solution, your assistance would be greatly appreciated.
I am using an AI to formulate this question.
Thank you.
Solved! Go to Solution.
2025-08-25 12:48 AM
Hello @R_JPstudent
If you select LoRaWAN Link Layer version 1.0.3, the ResponseTimeout item is not included, and the error occurs. A possible work-around is to comment-out the #if/#endif in the code snippet (at line 1518 in LoRaMacInterfaces.h file). So ResponseTimeout is always included regardless of LoRaWAN Link Layer. If you do this, you will need to re-do it every time CubeMX generates code and over-writes the change. Also, you can change from LoRaWAN Link Layer specification from 1.0.3 to 1.0.4:
PS: This is already reported and will be solved on the future. For more details, have a look at this post.
Best Regards.
STTwo-32
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-08-21 1:25 AM
Hello @R_JPstudent
Could you please share your project files ? This will help me better understand your configuration and assist you more effectively.
THX
Ghofrane
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-08-24 5:54 PM
2025-08-25 12:48 AM
Hello @R_JPstudent
If you select LoRaWAN Link Layer version 1.0.3, the ResponseTimeout item is not included, and the error occurs. A possible work-around is to comment-out the #if/#endif in the code snippet (at line 1518 in LoRaMacInterfaces.h file). So ResponseTimeout is always included regardless of LoRaWAN Link Layer. If you do this, you will need to re-do it every time CubeMX generates code and over-writes the change. Also, you can change from LoRaWAN Link Layer specification from 1.0.3 to 1.0.4:
PS: This is already reported and will be solved on the future. For more details, have a look at this post.
Best Regards.
STTwo-32
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-08-25 3:27 AM - edited 2025-08-25 3:29 AM
Thank you very much for your prompt and helpful response.
Based on your advice, I changed the LoRaWAN Link Layer specification from 1.0.3 to 1.0.4 and was able to successfully complete the build. This resolved the 'McpsIndication_t' has no member named 'ResponseTimeout' error.
After successfully building the firmware, I used STM32CubeProgrammer to write it to the device. I then connected to the device using TeraTerm with the correct baud rate and COM port settings, but unfortunately, no output was displayed on the console.
I suspect the issue is related to the USART configuration, but I'm unsure of the root cause. Do you have any suggestions on what might be causing this issue?
Best Regards,
R_JPstudent