When an Intel hex contains data for only a small portion of a 256-bytes block, the created UF2 file adds zeros to the data not specified in the Intel Hex records.
For example this very small Intel hex just adds 200 bytes of data into the nRF52 UICR from address 0x1000_1014 to 0x1000_10DC:
:020000041000EA
:081014000020070000E00700C6
:1010C0007CB0EE47FFFFFFFF0C0000000000620055
:0C10D000FFFFFFFF000000000000000018
:00000001FF
The resulting UF2 creates a block with 256 bytes of data from address 0x1000_1000 to 0x1000_1100. This adds "padding" zeros to 20 bytes at the beginning and 51 bytes at the end of the block (0x1000_1000 to 0x1000_1014, and 0x1000_10DC to 0x1000_1100).
In this case the UICR is a special flash area reserved for configuration data and used by things like the Nordic SoftDevice. So, zeros could be configuring something unexpected (specially since the beginning of this area is reserved or "reserved for Nordic firmware design" info) and the default state should be left as 0xFF.
It would be useful if the default value for padded data could be configured with another flag. Perhaps we could also argue that the default should be 0xFF anyway, as that is the default state for the majority of MCUs flash.
When an Intel hex contains data for only a small portion of a 256-bytes block, the created UF2 file adds zeros to the data not specified in the Intel Hex records.
For example this very small Intel hex just adds 200 bytes of data into the nRF52 UICR from address
0x1000_1014to 0x1000_10DC:The resulting UF2 creates a block with 256 bytes of data from address
0x1000_1000to0x1000_1100. This adds "padding" zeros to 20 bytes at the beginning and 51 bytes at the end of the block (0x1000_1000to0x1000_1014, and0x1000_10DCto0x1000_1100).In this case the UICR is a special flash area reserved for configuration data and used by things like the Nordic SoftDevice. So, zeros could be configuring something unexpected (specially since the beginning of this area is reserved or "reserved for Nordic firmware design" info) and the default state should be left as 0xFF.
It would be useful if the default value for padded data could be configured with another flag. Perhaps we could also argue that the default should be 0xFF anyway, as that is the default state for the majority of MCUs flash.