FUOTA Fragmentation Not Processing on STM32WL55 Board

[PrathamSalunkhe]

Hello ST Community,

I am implementing FUOTA on STM32WL55-based device using ChirpStack. For this purpose, I am implementing the example code (Lorawan_FUOTA) provided by st-microelectronics in the stm32cube_fw_wl_v1.3.0 library. I have successfully built the LoRaWAN_End_Node example from the stm32cube_fw_wl_v1.3.0 library. I have installed the ChirpStack FUOTA server, which is running successfully.

Current Progress:
1. The multicast group is created on the ChirpStack server.

2. The multicast setup request is successfully sent to the end device.

3. The device creates the multicast session and switches to Class C.

4. Data is received on multicast port 201 (fragmentation port).

Issue:

Despite receiving data on port 201, the fragmentation decoding process is not being initiated on the device.

Some data is being received via multicast. However, when the code reaches the check for MultiCastGroupBitMask:

 if( ( groupId == 0xFF ) || ( ( FragSessionData[fragIndex].FragGroupData.FragSession.Fields.McGroupBitMask & ( 1 << groupId ) ) == 0 ) )

this condition evaluates to true, causing the FRAGMENTATION_DATA_FRAGMENT case to break, and the code does not proceed to FragDecoderProcess. I have added logs to debug this issue.

Below is the code snippet :

                    if( mcpsIndication->Multicast == 1 )
                    {
                        /* Message received on a multicast address */
                        /* Check McGroupBitMask */
                        uint8_t groupId = LoRaMacMcChannelGetGroupId( mcpsIndication->DevAddress );
                       	
                        MW_LOG(TS_OFF, VLEVEL_H, "++++++++++++ Received DevAddress: 0x%08X, GroupId: %d\n", mcpsIndication->DevAddress, groupId);
                        MW_LOG(TS_OFF, VLEVEL_H, "++++++++++++ McGroupBitMask: 0x%02X\n", FragSessionData[fragIndex].FragGroupData.FragSession.Fields.McGroupBitMask);
                        if( ( groupId == 0xFF ) ||
                            ( ( FragSessionData[fragIndex].FragGroupData.FragSession.Fields.McGroupBitMask & ( 1 << groupId ) ) == 0 ) )
                        {
                        	MW_LOG(TS_OFF, VLEVEL_H, "++++++++++++ Multicast group Id is False, condition break\r\n");	
                            /* Ignore message */
                            cmdIndex = mcpsIndication->BufferSize;
                            break;
                        }
                    }

                    if( FragSessionData[fragIndex].FragDecoderProcessStatus == FRAG_SESSION_ONGOING )
                    {
                    	MW_LOG(TS_OFF, VLEVEL_H, "++++++++++++ Fragmetation session process....\r\n");	
                        memcpy(buffer, (void *)&mcpsIndication->Buffer[cmdIndex], FragSessionData[fragIndex].FragGroupData.FragSize);
                        FragSessionData[fragIndex].FragDecoderProcessStatus = FragDecoderProcess( fragCounter, buffer );
                        FragSessionData[fragIndex].FragDecoderStatus = FragDecoderGetStatus( );
                        if( LmhpFragmentationParams->OnProgress != NULL )
                        {
                        	MW_LOG(TS_OFF, VLEVEL_H, "++++++++++++ Fragmetation Data frags are decoding......\r\n");	
                            LmhpFragmentationParams->OnProgress( FragSessionData[fragIndex].FragDecoderStatus.FragNbRx,
                                                                 FragSessionData[fragIndex].FragGroupData.FragNb,
                                                                 FragSessionData[fragIndex].FragGroupData.FragSize,
                                                                 FragSessionData[fragIndex].FragDecoderStatus.FragNbLost );
                        }

Debugging Steps Taken:
1. Verified that the device successfully joins the network via OTAA.

2. Checked that multicast session parameters are correctly set.

3. Ensured that the device has switched to Class C mode.

4. Monitored the logs but did not find any indication that the fragmentation process has started.

Questions:
1. What could prevent the STM32WL55 from starting the fragmentation decoding process even after receiving FUOTA fragments?

2. Are there any known issues with FUOTA implementation on STM32WL55 that could cause this behaviour?

3. What additional debugging steps should I take to verify that the fragmentation process is working correctly?

4. Should I change something in the LoRaWAN_End_Node project ?

I have attached my FUOTA session logs for reference. Any insights or suggestions would be greatly appreciated!

Thanks in advance for your help!

Best regards,

Pratham Salunkhe
Embedded Firmware Engineer.

[mahajansuyash]

Hii Pratham,

I am also implementing the FUOTA example and am stuck in the same situation as you are. The one thing I am doing different is am using AWS IoT Core for LNS 

My firmware get stuck once the command to switch to C is issued 
The last message on terminal I get is 
"Switch to Class C done" 

Did you solve this issue and could you share me the details ?

Regards

Suyash