Bug in flash_placement.xml example file?

[RMV]

I am using nRF5 SDK version 17.1.0 and am seeing this line in file examples/ble_peripheral/ble_app_uart/pca10040/s132/ses/flash_placement.xml

        <ProgramSection alignment="4" load="Yes" name=".text" size="0x4" />

Why is the size of this section specified as only 0x4?

I find it hard to believe that a program would have only a 4-byte section named ".text"....

Cheers

RVM

[Vidar Berg]

Hi,

It is apparently done on purpose to address this alignment issue mentioned in the release notes:

nRF5 SDK v17.1.0
------------------------
Release Date: August, 2021
.....
Observation of unaligned memory layout:
Certain SES projects that use section variables have been observed
to create memory sections that do not end on a word-aligned address.
This has caused issues when the hex file has been processed by a hex file utility tool
like mergehex.exe, which can produce a corrupted hex file.
The issue has been fixed in the SES section-placement file (flash_placement.xml)
by setting the memory section size attribute to 4.
....

But I too would have thought that a size of 4 bytes would prevent you from building anything. ".text" obviously needs to be a lot bigger for any normal application, and it is if you look at the generated *.map output. I will ask the developers for an explanation and update my answer here.

[RMV]

Hi Vidor
Any updates from the developers?
Cheers
Ramanand

[Vidar Berg]

Hi Ramanand,

We were not been able to find any documentation for this behavior in the Segger documentation now, but through earlier testing and validation we confirmed that the section sometimes did not get aligned without the .size argument. It's not clear whether this is the intended behavior or not, we would have to reach out to Segger to confirm this.

Cheers

Vidar

Edit: correction, the alignment argument does work. .align=4 makes it so that the sections always start at a word aligned address. The problem fixed by .size=4 was that size was also aligned to a four byte boundary as shown below:

left side has .size=4

2 byte *fill* to make size word aligned:

This ensures that empty spaces in the app image are always filled with the same values (either 0xff or 0x00). Previously we would sometimes see a discrepancy when programming the *.elf file instead of the *.hex file due to different padding rules, which is problematic when you try to compute a CRC of the image for Boot validation.