FUOTA: Facing issues while using flash memory instead of UnfragmentedData[FRAG_MAX_NB * FRAG_MAX_SIZE] (SRAM buffer)

[shabaz704]

Hi,

We are using B-L072Z-LRWAN1 board to perform the FUOTA.

The way we changed the current implementation:

1. In FragDecoderWrite function in main.c we added a function to write the fragments to the flash memory.

FlashMemHandler_Write((void *)(FLASH_BANK2_BASE + addr), (uint8_t *)UnfragmentedData, size);

2. to read the same fragmented data from flash we added below function in function FragDecoderRead:

FlashMemHandler_Read(/*destination*/ (uint8_t *)data,/*Source addr*/ (void *)(FLASH_BANK2_BASE + addr), size);

You can get the function definitions in the attached text file. We got these things from the stm32 i-cube-lrwan example.

Our aim is to utilize the FLASH instead of the SRAM.

We are facing the problem when there is loss of fragments in function FragDecoderProcess.

And while it's trying to perform GetRow() operation while handling the lost frames, the board is going into unknown state like infinite while loop.

Can you suspect any cause for this?

[SBEN .2]

Hello @shabaz704​ 

Could you provide the implementation of FlashMemHandler_Write? It should be noted that the fragmentation decode operation is not linear. Multiple writes to the same block is expected (according to the redundancy matrix). Rewriting on the internal flash without erasing the page/sector before hand would cause issues similar to the one you're describing.

Best regards,

@SBEN .2​ 

[Tesla DeLorean]

>>Can you suspect any cause for this?

Well Erasing and Writing the Flash whilst running from Flash can cause significant stalls where the processor executes nothing, basically stuffs wait-states, and breaks real-time responsiveness.

The entire code footprint needs to be in RAM, including vectors, and all subroutines and libraries called/touched by the code.