Multicore slave - Statics not initialised

AndyCapon · ‎03-23-2019

Hi Guys,

I have a LPCXpresso55S69 board here.

I have a Master/Slave project set up, statics in the Slave project are not initialised.

Has anyone any ideas?

Cheers

Andy

AndyCapon · ‎03-30-2019

So, I now add the following line to the Slave code to increase the .text size by 4 bytes:

__asm("NOP");

Now the sections line up in the axf files and statics are initialised correctly.

So the issue is with the .text size of the slave code, if the .text size is divisible by 8 everything works otherwise initialisation is incorrect.

AndyCapon · ‎03-30-2019

I looked at the LD files and the slave one looks fine, it is aligning to 4. The linker though is aligning to 8!

I have managed to bodge it to work by changing the linker script for the Master to align data_RAM2_core_m33slave_data to 8, now statics are initialised correctly irrespective of the slaves .text size.

This is obviously not the correct way of fixing it but at least gets me going, someone at NXP needs to look to see why the slaves data is aligned to 8 rather than 4.

AndyCapon · ‎03-30-2019

Now for a C++ project:

The slave has the following memory setup:

Memory region Used Size Region Size %age Used

SRAM_CODE: 56912 B 136 KB 40.87%

SRAMX: 0 GB 32 KB 0.00%

USB_RAM: 5808 B 16 KB 35.45%

Here we seem to need to align to 32 bytes in the master ld file for statics to be initialised correctly:

/* M33SLAVE data section */
 .data_RAM2_core_m33slave_data . : SUBALIGN(32)
 {
 FILL(0xff)
 KEEP(*(.core_m33slave.data_*)) KEEP(*(.core_m33slave.data))
 __core_m33slave_END__ = .; /* end of slave image */
/* perform some simple sanity checks */
 ASSERT(!(__core_m33slave_START__ == __core_m33slave_END__), "No slave code for _core_m33slave");
 ASSERT( (ABSOLUTE(__core_m33slave_START__) == __vectors_start___core_m33slave), "M33SLAVE execute address differs from address provided in source image");
 } > SRAM_CODE AT>PROGRAM_FLASH‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The reason is that the slave is linked with a reserved section (.uninit_RESERVED PROGBITS) to align the .data to 32 bytes, here is the slave map file sorted by address:

[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[16] .debug_info PROGBITS 00000000 00d5b0 026da4 00 0 0 1
[17] .debug_abbrev PROGBITS 00000000 034354 004491 00 0 0 1
[18] .debug_aranges PROGBITS 00000000 0387e5 000d88 00 0 0 1
[19] .debug_ranges PROGBITS 00000000 03956d 000c08 00 0 0 1
[20] .debug_macro PROGBITS 00000000 03a175 01ec9c 00 0 0 1
[21] .debug_line PROGBITS 00000000 058e11 00ccb6 00 0 0 1
[22] .debug_str PROGBITS 00000000 065ac7 0e0922 01 MS 0 0 1
[23] .comment PROGBITS 00000000 1463e9 00007f 01 MS 0 0 1
[24] .ARM.attributes ARM_ATTRIBUTES 00000000 146468 000032 00 0 0 1
[25] .debug_frame PROGBITS 00000000 14649c 004318 00 0 0 4
[26] .symtab SYMTAB 00000000 14a7b4 004d60 10 27 787 4
[27] .strtab STRTAB 00000000 14f514 0032cc 00 0 0 1
[28] .shstrtab STRTAB 00000000 1527e0 000135 00 0 0 1
[ 3] .data_RAM2 PROGBITS 04000000 00d5b0 000000 00 W 0 0 4
[10] .noinit_RAM2 PROGBITS 04000000 00d5b0 000000 00 W 0 0 4
[ 1] .text PROGBITS 20022000 002000 00ac8c 00 AX 0 0 4
[ 6] .ARM.extab PROGBITS 2002cc8c 00cc8c 0002e8 00 A 0 0 4
[ 7] .ARM.exidx ARM_EXIDX 2002cf74 00cf74 0002b8 00 AL 1 0 4
[ 9] .uninit_RESERVED PROGBITS 2002d22c 00d5b0 000000 00 W 0 0 4
[ 2] .data PROGBITS 2002d240 00d240 000370 00 WA 0 0 64
[ 5] .bss NOBITS 2002d5c0 00d5b0 000890 00 WA 0 0 64
[12] .noinit PROGBITS 2002de50 00d5b0 000000 00 W 0 0 4
[13] .heap NOBITS 2002de50 00d5b0 001000 00 WA 0 0 4
[14] .heap2stackfill NOBITS 2002ee50 00d5b0 001000 00 WA 0 0 1
[15] .stack PROGBITS 20043000 00d5b0 000000 00 W 0 0 4
[ 8] .m_usb_data NOBITS 40100000 010000 0016b0 00 WA 0 0 256
[ 4] .data_RAM3 PROGBITS 401016b0 00d5b0 000000 00 W 0 0 4
[11] .noinit_RAM3 PROGBITS 401016b0 00d5b0 000000 00 W 0 0 4

We can see from the Master map file that this section is not taken into account so .data_RAM2_core_m33slave_data ends up taking the value of .uninit_RESERVED PROGBITS

[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 010000 0057b4 00 AX 0 0 8
[21] .debug_info PROGBITS 00000000 030080 01e874 00 0 0 1
[22] .debug_abbrev PROGBITS 00000000 04e8f4 00355b 00 0 0 1
[23] .debug_aranges PROGBITS 00000000 051e4f 000988 00 0 0 1
[24] .debug_ranges PROGBITS 00000000 0527d7 0008a8 00 0 0 1
[25] .debug_macro PROGBITS 00000000 05307f 01cbf5 00 0 0 1
[26] .debug_line PROGBITS 00000000 06fc74 007b6b 00 0 0 1
[27] .debug_str PROGBITS 00000000 0777df 0d8835 01 MS 0 0 1
[28] .comment PROGBITS 00000000 150014 00007f 01 MS 0 0 1
[29] .ARM.attributes ARM_ATTRIBUTES 00000000 150093 00003a 00 0 0 1
[30] .debug_frame PROGBITS 00000000 1500d0 0030c0 00 0 0 4
[31] .debug_loc PROGBITS 00000000 153190 000a55 00 0 0 1
[32] .symtab SYMTAB 00000000 153be8 0039b0 10 33 545 4
[33] .strtab STRTAB 00000000 157598 0024c7 00 0 0 1
[34] .shstrtab STRTAB 00000000 159a5f 0001ce 00 0 0 1
[11] .ARM.extab PROGBITS 000057b4 0157b4 0002f4 00 A 0 0 4
[12] .ARM.exidx ARM_EXIDX 00005aa8 015aa8 0002b8 00 AL 1 0 4
[ 8] .data_RAM3 PROGBITS 04000000 030080 000000 00 W 0 0 4
[15] .noinit_RAM3 PROGBITS 04000000 030080 000000 00 W 0 0 4
[ 2] .data PROGBITS 20000000 030000 000080 00 WA 0 0 4
[13] .uninit_RESERVED PROGBITS 20000000 030080 000000 00 W 0 0 4
[10] .bss NOBITS 20000080 030080 000120 00 WA 0 0 4
[17] .noinit PROGBITS 200001a0 030080 000000 00 W 0 0 4
[18] .heap NOBITS 200001a0 030080 001000 00 WA 0 0 4
[19] .heap2stackfill NOBITS 200011a0 030080 001000 00 WA 0 0 1
[20] .stack PROGBITS 20021000 030080 000000 00 W 0 0 4
[ 3] .data_RAM2_core_m33slave_text PROGBITS 20022000 022000 00ac8c 00 AX 0 0 4
[ 4] .data_RAM2_core_m33slave_ARM_extab PROGBITS 2002cc8c 02cc8c 0002e8 00 A 0 0 4
[ 5] .data_RAM2_core_m33slave_ARM_exidx ARM_EXIDX 2002cf74 02cf74 0002b8 00 AL 3 0 4
[ 6] .data_RAM2_core_m33slave_data PROGBITS 2002d22c 02d22c 000370 00 WA 0 0 64
[ 7] .data_RAM2 PROGBITS 2002d59c 030080 000000 00 W 0 0 4
[14] .noinit_RAM2 PROGBITS 2002d59c 030080 000000 00 W 0 0 4
[ 9] .data_RAM4 PROGBITS 40100000 030080 000000 00 W 0 0 4
[16] .noinit_RAM4 PROGBITS 40100000 030080 000000 00 W 0 0 4

ZhangJennie · ‎03-31-2019

HI Andew,

I was not in office last Thursday and Friday.

If you could, please send your both slave and master project here. I will check it directly.

Have a nice day,

Jun Zhang

AndyCapon · ‎03-31-2019

Hi Jun Zhang,

I don't seem to be able to attach a zip file here, maybe I do not have the permissions?

Andy

ZhangJennie · ‎03-31-2019

Hi Andy

Please follow attached video to check if you can find the same "Attach" button.

Jun Zhang

AndyCapon · ‎03-31-2019

Hi Jun Zhang,

I indeed can, I was looking at the top toolbar instead !

I have attached a C++ project I just created for you, I have also changed the master_memory_region to SRAM_136 instead of SRAM 2 though this doesn't seem to make any difference.

Also with this c++ project the initialisation is out by 4 bytes (8 byte align) rather than 32 byte align, so I am guessing that this offset may change for other regions and is not related to C or C++.

If you debug and build these projects you should see the static initialisation out by 4 bytes, the .uninit_RESERVED section in the slave AXF file is only 4 bytes:

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 20022000 002000 004e6c 00 AX 0 0 4
[ 2] .data PROGBITS 20027410 007410 0009b4 00 WA 0 0 8
[ 3] .bss NOBITS 20027dc4 007dc4 000140 00 WA 0 0 4
[ 4] .ARM.extab PROGBITS 20026e6c 006e6c 0002e8 00 A 0 0 4
[ 5] .ARM.exidx ARM_EXIDX 20027154 007154 0002b8 00 AL 1 0 4
[ 6] .uninit_RESERVED PROGBITS 2002740c 007dc4 000000 00 W 0 0 4
[ 7] .noinit PROGBITS 20027f04 007dc4 000000 00 W 0 0 4
[ 8] .heap NOBITS 20027f04 007dc4 001000 00 WA 0 0 4
[ 9] .heap2stackfill NOBITS 20028f04 007dc4 001000 00 WA 0 0 1
[10] .stack PROGBITS 20043000 007dc4 000000 00 W 0 0 4
[11] .debug_info PROGBITS 00000000 007dc4 008bb1 00 0 0 1
[12] .debug_abbrev PROGBITS 00000000 010975 000f1e 00 0 0 1
[13] .debug_aranges PROGBITS 00000000 011893 000308 00 0 0 1
[14] .debug_ranges PROGBITS 00000000 011b9b 000288 00 0 0 1
[15] .debug_macro PROGBITS 00000000 011e23 003dd2 00 0 0 1
[16] .debug_line PROGBITS 00000000 015bf5 002112 00 0 0 1
[17] .debug_str PROGBITS 00000000 017d07 0d0c6b 01 MS 0 0 1
[18] .comment PROGBITS 00000000 0e8972 00007f 01 MS 0 0 1
[19] .ARM.attributes ARM_ATTRIBUTES 00000000 0e89f1 000032 00 0 0 1
[20] .debug_frame PROGBITS 00000000 0e8a24 001e14 00 0 0 4
[21] .symtab SYMTAB 00000000 0ea838 002c80 10 22 395 4
[22] .strtab STRTAB 00000000 0ed4b8 001de0 00 0 0 1
[23] .shstrtab STRTAB 00000000 0ef298 0000f9 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)

Now if you turn of managed linking for the Master project and change the alignment of .data_RAM2_core_m33slave_data to 8:

/* M33SLAVE data section */
.data_RAM2_core_m33slave_data . : SUBALIGN(8)
{
FILL(0xff)
KEEP(*(.core_m33slave.data_*)) KEEP(*(.core_m33slave.data))
__core_m33slave_END__ = .; /* end of slave image */

/* perform some simple sanity checks */
ASSERT(!(__core_m33slave_START__ == __core_m33slave_END__), "No slave code for _core_m33slave");
ASSERT( (ABSOLUTE(__core_m33slave_START__) == __vectors_start___core_m33slave), "M33SLAVE execute address differs from address provided in source image");
} > SRAM_136 AT>PROGRAM_FLASH

Now if you build and debug you will see the statics are good.

Thanks

Andy

AndyCapon · ‎04-02-2019

Some more info:

A C++ project I am working on that previously needed a 32 byte align has now changed to needing a 64 byte align as I added code to the SLAVE and also changed the size of the static data by removing a static LUT.

[10] .uninit_RESERVED PROGBITS 2002f34c 00f6f4 000000 00 W 0 0 4
[ 2] .data PROGBITS 2002f380 00f380 000374 00 WA 0 0 64

ZhangJennie · ‎04-03-2019

I wonder there is problem with MCUXpresso IDE itself.

I will check it with IDE development team.

as work around, please use SRAMX instead.

Best Regards

Jun Zhang

AndyCapon · ‎04-03-2019

Hi Jun Zhang,

Thanks for looking into it.

I think that is where the problem is, and it it to do with the automatic linker script generation.

The Master linker script is not fully taking into account the Slave linker script.

Unfortunately we cannot use SRAMX because of size limitations, now we know where the problem is though we can adjust the Master script so it links correctly. Not ideal but a workaround.

Cheers

Andy

ZhangJennie · ‎04-04-2019

I can't open your video anymore.

Can you please create a video of how you created the two projects ( ForJunZhang.zip ) you sent me ?

Is this problem in c++ project only or also in C project?

Have a nice day,

Jun Zhang

AndyCapon · ‎04-04-2019

Hi Jun Zhang,

I just tried the video and it plays ok, could you try again. I deleted the original here.

It's fairly easy to replicate in C or C++, just create a project with a decent amount of code in the Slave.

For the C++ example I use Newlib SemiHost, the host USB stack, MCMgr and RPMsg-lite in the Slave. Split the normal ram in half and use the second part for the Slave code.

Cheers

Andy

AndyCapon · ‎03-28-2019

Hi Jun Zhang,

Thanks very much for looking at the video.

Creating a new C master/slave Project with SRAMX instead of RAM2, statics worked.

Next test was to use newlib semihost, this will not fit into SRAMX so I created a split Ram, with core 2 using 0x20022000.

I first created the slave and built it.

Then when creating the Master you are not able to choose based on the name of the memory only the alias:

So I then went in and changed it in the settings:

When build this also suffers from the statics being offset by 4 bytes.

I wonder if it is possible for you to set-up this test?

Many thanks

Andy