CC2652R7: Generated .bin file is oversized in CC25652R7

Hi mohan,

Please see this Introduction to Binary Files, particularly the section about holes and avoiding them.

The format of a binary file is very simple. There is no compact way to represent a hole. The only possible way to represent a hole is to fill it...

The best way to avoid holes is to carefully control the placement of the initialized sections in the executable. Put them as close together as possible. In an ideal configuration, they are all adjacent to each other.

Sometimes holes cannot be avoided. If that is the case, see if one of these two alternatives is practical.

One alternative is to create separate bin files. If there are two clusters of initialized sections, then create one bin file for each cluster. This approach is not always practical. The utility that creates the bin file may not support it. Or, the utility that reads the bin file as input may accept only one file.

The second alternative relies on two presumptions. One, all of the initialized sections are close together accept one. Two, there is room in memory near the main cluster of initialized sections. In that case, arrange for that remaining initialized section to have different load and run addresses. It loads at an address near the main cluster of initialized sections. As part of system startup, it is copied to a different run address.

You cannot avoid holes with a single whole CC2652R7 binary since the CCFG is stored in the last page of flash.  If the CCFG has been programmed once then it should not be necessary to re-program the last page of flash memory, depending on the CCFG configuration itself.  But there are also the NV memory flash pages which are adjacent to the CCFG that must be considered as well.  Output .hex images are smaller since they don't have the same hole fill requirements, if you are able to make this work instead.

Regards,
Ryan