STM32WL FUOTA Firmware swapping issue

[AElgh]

Hello everyone,

The LoRaWAN_End_Node from LoRaWAN_FUOTA Project (STM32Cube_FW_WL_V1.3.1) is used with ChirpStack as a network server (supports the FUOTA Package V1).

The Multicast session runs and receives the Downlink of all the Fragmented Packets from the server.

The issue appears after receiving the last packet. Seems that the Firmware doesn't recognize that the downloaded firmware is complete, and it should begin building it.

In AN5554(P10):

The V1.0 package, and particularly Fragmented Data Transport specification [TS-004] (see document [3]), does
not provide a way to inform the server that all data blocks have been properly received in order to rebuild the
current download file. 

Trying to find a way to let the Firmware swaps to the new version rather than flip back(after the expiration of the Fragmention status request) to the old Firmware:

Tracing the logs, there is no sign of FRAG_DECODER_IF_OnProgress and FRAG_DECODER_IF_OnDone being called. Hence, FwUpdateAgent_Run() never runs either.

Is there a way to fix this without the need to run an external fragmentation server(to implement the proprietary protocol)?

Thank you

[STTwo-32]

Hello @AElgh 

according to the AN5554, If needed, the user is responsible for implementing a 'proprietary' protocol to avoid such behavior. For instance, when all the required fragments have been received and the current download file rebuilt, a simple crc32 can be computed and sent back to the server. The server should decide to stop broadcasting the remaining fragments.
This approach requires cooperation between the device maker and the network operator to define the
'proprietary' part of the protocol.

So, you should dead with the network operator for the proprietary part of the protocol.

Best Regards.

STTwo-32

[AElgh]

@STTwo-32 Thank you for your response but in my case, the current download file doesn't rebuilt, the firmware just hang on the last packet(CNT = 95 in the 2nd photo) then after fragment-status-request send from the Server(which doesn't get any response from my Node until it reaches timeout) the Firmware switches back to Class-A.

I can see inside LmhpFragmentation.c  the function LmhpFragmentationOnMcpsIndication, which has the case FRAGMENTATION_FRAG_STATUS_REQ  which should be called when the FUOTA server asks for the status, but it never runs!!.

[AElgh]

Hello, I'm trying to debug the firmware following what is mentioned in AN5554 Section 6.1.3; however, it doesn't work, and there is no option inside the debug configuration that allows debugging during a running session.

Another issue related to the same topic, I noticed different behavior in the firmware according to the way of flashing the firmware:

- If flashed the Firmware with the script --> No Switch to Class C happens during the FUOTA Campaign.

- If flashed directly using CubeProgrammer --> different behavior according to the Fragment size:

Sometimes, the firmware would freeze just after switching to Class-C.

Sometimes it continues and gives this Flash error:

###### ========== MCPS-Confirm =============
1749460061s826:RX_C on freq 868500000 Hz at DR 5
Switch to Class C done
1749460063s906:MAC rxDone

.... !! FLASH_IF_WRITE_ERROR: -6 !! ....

.... FRAG_DECODER in Progress ....
EXPECTED : 344 Fragments (75680 Bytes)
RECEIVED : 001 Fragments
00220 Bytes
LOST : 000 Fragments

1749460063s917:RX_C on freq 868500000 Hz at DR 5
1749460068s990:MAC rxDone

.... !! FLASH_IF_WRITE_ERROR: -6 !! ....

.... FRAG_DECODER in Progress ....
EXPECTED : 344 Fragments (75680 Bytes)
RECEIVED : 002 Fragments
00440 Bytes
LOST : 000 Fragments

1749460069s001:RX_C on freq 868500000 Hz at DR 5
1749460074s084:MAC rxDone

.... !! FLASH_IF_WRITE_ERROR: -6 !! ....

.... FRAG_DECODER in Progress ....
EXPECTED : 344 Fragments (75680 Bytes)
RECEIVED : 003 Fragments
00660 Bytes
LOST : 000 Fragments

1749460074s095:RX_C on freq 868500000 Hz at DR 5
1749460079s184:MAC rxDone

.... !! FLASH_IF_WRITE_ERROR: -6 !! ....

Appreciate any help.

Thank you