I am doing some work to implement an application controlled OTA update with an EFR32GB13 device and wanted to utilize lzma compression for the update GBL file.
When configuring the Gecko Bootloader (based on the 1.8.2 internal single 512K version) to enable the "GBL Compression (LZMA)" plugin, the size of the resulting bootloader ends up being greater than the 16KB of dedicated bootloader flash storage space available on the EFR32B13. I tried deselecting some of the plugins that are enabled by default to reduce the bootloader size, but it seems all of the default ones are required due to dependencies or in order for the build to succeed. Playing with the build settings also proved unsuccessful in getting the size of the bootloader down to the 16KB limit.
So is there any advice on how I could get the bootloader size reduced (I think it is only 224 bytes or so too big) to fit within the 16KB limit?
I have reproduced this problem and reported to our developers to fix. I also escalated a support case to track the problem and will keep you posted.
I have the same problem using MGM13P02 with newest stack release from the ZigBee Stack. I'm using the LZ4 compression in combination with multiple flash storage on external flash.
Would be great to hear about fixes. I just updated from older from because of the bootloader security issue and now I can't get it to work.
We investigated this and the conclusion is that LZMA compression is not supported on EFR32xG13/xGM13x devices. This is indeed not clearly communicated but if you look at UG266 table the bootloader sizes are listed there, and LZMA always goes over the 16KB limit.
The option here is to use LZ4 instead as that fits into the 16KB space.