2025-07-07 12:11 AM - edited 2025-07-07 12:12 AM
../Middlewares/Third_Party/LoRaWAN/Mac/LoRaMac.c:1650:40: error: 'McpsIndication_t' {aka 'struct sMcpsIndication'} has no member named 'ResponseTimeout'
1650 | ( MacCtx.McpsIndication.ResponseTimeout > 0 ) )
| ^ The above error is occuring every time , if i remove this then adc_if.c is not found error occurs and I don't want to include the adc_if.c file in my code
2025-07-07 1:23 AM
Hello @avinashkumar
Could you please provide your ioc in order to investigate the issue?
KR,
Souhaib
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-07-07 2:55 AM
2025-07-07 8:46 AM - edited 2025-07-07 11:27 AM
This is a bug in the STM32WL FW 1.3.1 package. The following code at line 1518 in LoRaMacInterfaces.h appears to have been added in 1.3.1 and conditionally includes the ResponseTimeout item if LoRaWAN Link Layer is 1.0.4 in CubeMX.
If you select LoRaWAN Link Layer version 1.0.3, the ResponseTimeout item is not included and the error occurs.
This needs to be corrected by ST in the FW package. A possible work-around is to comment-out the #if/#endif in the code snippet so ResponseTimeout is always included regardless of LoRaWAN Link Layer which should be harmless; if you do this, you will need to re-do it every time CubeMX generates code and over-writes the change.
bool DeviceTimeAnsReceived;
#if (defined( LORAMAC_VERSION ) && (( LORAMAC_VERSION == 0x01000400 ) || ( LORAMAC_VERSION == 0x01010100 )))
/*!
* Response timeout for a class b or c device when a
* confirmed downlink has been received. In all other
* cases this variable is 0.
*/
TimerTime_t ResponseTimeout;
#endif /* LORAMAC_VERSION */
}McpsIndication_t;
2025-07-07 8:50 AM - edited 2025-07-07 8:51 AM
See my comment; 1.3.1 conditionally includes ResponseTime for LoRaWAN Link Layer 1.0.4 and 1.1.1 (see LoRaMacInterfaces.h around line 1518), but LoRaMac.c unconditionally accesses it, regardless of LoRaWAN Link Layer version.
I humbly suggest firmware changes are tested with 1.0.3 and 1.0.4 both, that would have caught this.