2

I am currently trying to dev a firmware for a PIC24F using the whole microchip stack (xc16, mcc, mplab X IDE, etc ...) (not necessarily relevant but i work on a debian 22)

Doesn't really matter why but i want to place some data on a specific section that i will place at specific location on my firmware.

Let's imagine i have a struct my_struct defined in file.h as follow :

#pragma pack(push, 1)   // using pragma pack to pack the struct and avoid padding
typedef struct {
    uint16_t magic;
    uint32_t length;
    uint32_t crc;
    uint16_t word_1;
    uint16_t word_2;
    uint8_t byte_1;
    uint8_t byte_2;
    uint8_t byte_3;
    uint8_t array[15];
}  my_struct;
#pragma pack(pop)

then in my file.c :

const my_struct  __attribute__((section("my_section"))) instance = {
    .magic            = 0xbaba,
    .crc              = 0xbabababa,
    .length           = 0xbabababa,
    .byte_1           = 0xba,
    .byte_2           = 0xba,
    .byte_3           = 0xba,
    .word_1           = 0xbaba,
    .word_2           = 0xbaba,
    .array            = {0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba }
};

When I create the object file file.o, I expect having a section my_section of size 32 and filled with 0xBA. So I try to inspect the produced file.o using objdump to ensure that the data are the one that I want

$ size -A file.o
section           size   addr
[...]
my_section              64      0

$ objdump -s -j my_section file.o

Contents of section my_section:
 0000 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0010 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0020 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0030 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................

But it seems like XC16 added a 00 padding for each data byte and that it doubled the size of the section.

I know that padding is to keep data aligned for optimization purpose, but for this specific case, I really need those data to be packed and the size needs to be 32.

The issue is not only in file.o, even if I go until the end of the compilation process, I manage to have the section located where i want (thanks to an updated linker script) but it still contains the unwanted padding. So i'm pretty sure the issue is not about linker, but about the compilation process itself

I tried a loooot of things, really.

I tried to pack the structure using : #pragma pack(1) (with or without push/pop) I also tried to use __packed or __atribute__((packed(1)))

I tried to add the aligned(1) keyword, or the volatile specifier I even tried to use some uint32_t arr[8], uint16_t arr[16] and uint8_t arr[32] instead of a struct.
I tried a lot of mplab project configuration (i can't remember which ones, probably all of them) I tried all those options separately and together ...

But nothing changes the output. I checked documentation or anything i could, but i can't make it work. Is this even possible under xc16 or should i give up?

=== EDIT ===

Thanks to @pmacfarlane and @thebusybee, I dug a little further and here is what i found:

I declared two identical structs

  • one (s1) with the __attribute__((used, section("my_section")),
  • the other (s2) with no attribute

when i compile and inspect file.o

I got the same output as before for the my_section output, coming from s1.
And some data has been added to the .const section, coming from s2:

$ objdump -s -j .const file.o

Contents of section .const:
 0000 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0010 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0020 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0030 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................

So nothing new here, but if I inspect the final elf, there is a difference :

$ objdump -s -j .const firmware.elf

Contents of section .const:
 82cc baba0000 baba0000 baba0000 baba0000  ................
 82dc baba0000 baba0000 baba0000 baba0000  ................
 82ec baba0000 baba0000 baba0000 baba0000  ................
 82fc baba0000 baba0000 baba0000 baba0000  ................

$ objdump -s -j my_section firmware.elf

Contents of section my_section:
 0000 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0010 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0020 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................
 0030 ba00ba00 ba00ba00 ba00ba00 ba00ba00  ................

Please note that i am using the default linker script for this example.

I tried to add some code in it , even to modify it entirely but, as nothing worked as expected, I went back to the default one.
For minimal reproducible purpose, i even ended up removing everything about section management, and the result stays the same. So i think the behaviors is coming from the xc16 linker default behavior and not from the linker script.
I would gladly add the linker script to the question but it is 3k lines long.
So, it looks like the linking process is packing ba00ba00 into baba0000 for built-in section such as .const but not for my custom section.

Don't know if it's relevant, but I assumed that this would bring more information. Any hints ?

gokasor
  • 41
  • 5
  • That's.... really weird. If you just let it be in the `.data` (or `.rodata`) section do you see the same? – pmacfarlane May 10 '23 at 22:16
  • 1
    If you tag this as `C` you'll probably have a vastly bigger audience. Maybe someone will have an idea. The tags you've used are accurate, but probably nobody is watching many of them. – pmacfarlane May 10 '23 at 22:22
  • Assumed that your tool chain uses a linker script, please [edit] your question and add it. -- How is a "normal" constant like `static const uint32_t C = 0x12345678;` stored in `.rodata`? Is it possible that your target reads every other byte from such memory? – the busybee May 11 '23 at 05:48
  • @pmacfarlane Thanks for your answers, you're right, I will add the `C` tag. I tried your idea and got the same output, from .data or from .const (with the const specfier). So the problem does not come from the custom section – gokasor May 11 '23 at 08:11
  • 1
    @thebusybee Thanks for your answer I could add the linker script, but i inspect the `file.o` which is produced before any linking process. I can be wrong, but I think the linker script is not relevant here. For the test you wanted me to do with the normal variable, i got `Contents of section .const: 0000 78005600 34001200`. => with const specifier. `Contents of section .ndata: 0000 78005600 34001200`. => without const specifier. So, same problem. – gokasor May 11 '23 at 08:20
  • PICs are known to have word sizes other than 8 or 16 bits. You might want to check this. – the busybee May 11 '23 at 09:11
  • How about something like this: `__pack_upper_byte char message[] = "Hello World!\n";` ? (From section 10.10.1 of this [data sheet](http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB%20XC16%20C%20Compiler%20Users%20Guide%20DS50002071.pdf)) – pmacfarlane May 11 '23 at 11:10
  • if added the ` __pack_upper_byte` in front of my structure declaration, i now got : `bababa00 bababa00 bababa00 bababa00` That's way better now ! Thank you very much – gokasor May 11 '23 at 13:37

1 Answers1

2

In order to mark this thread as resolved, I will post this answer, but the credit is not for me.

As pointed out by @thebusybee, the issue was coming from the fact that the pic I was using, uses 24bits words.

And as @pmacfarlane said, the solution was in this datasheet.

For 16-bit devices, a 24-bit word is used in Flash memory. The architecture supports the mapping of areas of Flash into the data space, but this mapping is only 16 bits wide to fit in with data space dimensions, unless the __pack_upper_byte qualifier is used

So by declaring my struct as follows :

__pack_upper_byte const my_struct __attribute__((section("my_section"))) instance = {
    .magic            = 0xbaba,
    .crc              = 0xbabababa,
    .length           = 0xbabababa,
    .byte_1           = 0xba,
    .byte_2           = 0xba,
    .byte_3           = 0xba,
    .word_1           = 0xbaba,
    .word_2           = 0xbaba,
    .array            = {0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba, 0xba }
};

I ended up with


objdump -s -j my_section binary.elf

binary.elf:     file format elf32-little

Contents of section my_section :
 0000 bababa00 bababa00 bababa00 bababa00  ................
 0010 bababa00 bababa00 bababa00 bababa00  ................
 0020 bababa00 bababa00 baba0000

Which is way better than before, thank you very much for your help !

gokasor
  • 41
  • 5