Can we deal with odd memory addresses and odd data length in case of STM32 custom bootloader?

[NCTUser]

We are writing a custom bootloader on STM32F102 and we

know we can write the flash memory in 16 bit wide steps.

We use now a continous binary flash image, so if it's length

would be odd we can concate one byte easily.

In near future we would like to use multi-region flash file

which contains section address and data length. Could it be

possible that the data lenght (in output sections) is odd? Do

the linker/compiler care of even data/section lenght? (For

example in read only data if it contains strings.)

[NCTUser]

I tried to put five bytes in a section, and the result:

FLASHX (rx) : ORIGIN = 0x800FC00, LENGTH = 1K

.myOutSection :

{

   KEEP(*(.myOddSection*))

} > FLASHX

__attribute__((section(".myOddSection")))

uint8_t myArray[] = { 0xAA, 0xBB, 0xCC, 0xDD, 0xEE };

I use TrueSTUDIO and the GNU toolchain. I found these

bytes in the target flash area:

0x0800FC00

AA BB CC DD EE C2 20 03 FF FF FF FF ...                                                                                                         

I read it during debug session through the Memory

Browser window. I saw three random bytes (the padding

bytes are different when I started a new debug session)

were put into the flash to round up the data to multiple

of four. I don't know how (linker/loader?) is responsible

for the rounding. Intristingly when i generate binary

image file, these padding bytes were not in the binary

file, only the AA BB CC DD EE bytes (these are the lastest

bytes of the file). So I tried to put padding bytes in a

controlled way:

__attribute__((section(".myOddSection")))

uint8_t myArray[] = { 0xAA, 0xBB, 0xCC, 0xDD, 0xEE };

__attribute__((section(".paddingSection")))

uint8_t paddingArray[] = { 0x11, 0x22, 0x33, 0x44 };

FLASHX (rx) : ORIGIN = 0x800FC00, LENGTH = 1K

.myOutSection :

{

   KEEP(*(.myOddSection*))

   . = ALIGN(4);

   KEEP(*(.paddingSection*))

} > FLASHX

0x0800FC00

AA BB CC DD EE 00 00 00 11 22 33 44 00 00 00 00 FF FF FF FF ...                                                                       

I get unexpectedly four zeros after the 44, but the generated

binary file length (and the length of myOutSection) is multple

of four.