MCUXpresso Code alignment problem

[mjbcswitzerland]

Hi All

I have two project that work with a boot loader that requires the code to be linked to a specific address - 0x60020108 (I know it sound like a strange address but it has a specific reason and has been used for some time without any problems).

But today I found that one of the two projects that needed to be configured for this didn't work, but the other did. This although both use the same managed linker scrip setup as follows:

MEMORY
{
/* Define each memory region */
BOARD_FLASH (rx) : ORIGIN = 0x60020108, LENGTH = 0x3dfef8 /* 4062968 bytes (alias Flash) */
SRAM_DTC (rwx) : ORIGIN = 0x20000000, LENGTH = 0x20000 /* 128K bytes (alias RAM) */
SRAM_ITC (rwx) : ORIGIN = 0x300, LENGTH = 0x1fd00 /* 130304 bytes (alias RAM2) */
SRAM_OC (rwx) : ORIGIN = 0x20200000, LENGTH = 0xc0000 /* 768K bytes (alias RAM3) */
BOARD_SDRAM (rwx) : ORIGIN = 0x80000000, LENGTH = 0x2000000 /* 32M bytes (alias RAM4) */
}

/* Define a symbol for the top of each memory region */
__base_BOARD_FLASH = 0x60020108 ; /* BOARD_FLASH */
__base_Flash = 0x60020108 ; /* Flash */
__top_BOARD_FLASH = 0x60020108 + 0x3dfef8 ; /* 4062968 bytes */
__top_Flash = 0x60020108 + 0x3dfef8 ; /* 4062968 bytes */

..

ENTRY(ResetISR)

SECTIONS
{
/* MAIN TEXT SECTION */
.text : ALIGN(4)
{
FILL(0xff)
__vectors_start__ = ABSOLUTE(.) ;
KEEP(*(.isr_vector))
/* Global Section Table */
. = ALIGN(4) ;
__section_table_start = .;
__data_section_table = .;

In the map file of the one that works one finds:

0x60020108 __base_BOARD_FLASH = 0x60020108
0x60020108 __base_Flash = 0x60020108
0x61000000 __top_BOARD_FLASH = 0x61000000
0x61000000 __top_Flash = 0x61000000
0x20000000 __base_SRAM_DTC = 0x20000000
0x20000000 __base_RAM = 0x20000000
0x20008000 __top_SRAM_DTC = 0x20008000
0x20008000 __top_RAM = 0x20008000
0x00000300 __base_SRAM_ITC = 0x300
0x00000300 __base_RAM2 = 0x300
0x00008000 __top_SRAM_ITC = 0x8000
0x00008000 __top_RAM2 = 0x8000
0x20200000 __base_SRAM_OC = 0x20200000
0x20200000 __base_RAM3 = 0x20200000
0x20210000 __top_SRAM_OC = 0x20210000
0x20210000 __top_RAM3 = 0x20210000
0x20210000 __base_NCACHE_REGION = 0x20210000
0x20210000 __base_RAM4 = 0x20210000
0x20210000 __top_NCACHE_REGION = 0x20210000
0x20210000 __top_RAM4 = 0x20210000

.text 0x60020108 0x33c4
FILL mask 0xff
0x60020108 __vectors_start__ = ABSOLUTE (.)
*(SORT_BY_ALIGNMENT(.isr_vector))
.isr_vector 0x60020108 0x188 ./startup/startup_mimxrt1011.o
0x60020108 g_pfnVectors
0x60020108 __Vectors
0x60020290 . = ALIGN (0x4)
0x60020290 __section_table_start = .

As can be seen the reset vectors table is at the expected location.

The other, which is expected to be the same has a different address in the map file:

0x60020108 __base_BOARD_FLASH = 0x60020108
0x60020108 __base_Flash = 0x60020108
0x60400000 __top_BOARD_FLASH = 0x60400000
0x60400000 __top_Flash = 0x60400000
0x20000000 __base_SRAM_DTC = 0x20000000
0x20000000 __base_RAM = 0x20000000
0x20020000 __top_SRAM_DTC = 0x20020000
0x20020000 __top_RAM = 0x20020000
0x00000300 __base_SRAM_ITC = 0x300
0x00000300 __base_RAM2 = 0x300
0x00020000 __top_SRAM_ITC = 0x20000
0x00020000 __top_RAM2 = 0x20000
0x20200000 __base_SRAM_OC = 0x20200000
0x20200000 __base_RAM3 = 0x20200000
0x202c0000 __top_SRAM_OC = 0x202c0000
0x202c0000 __top_RAM3 = 0x202c0000
0x80000000 __base_BOARD_SDRAM = 0x80000000
0x80000000 __base_RAM4 = 0x80000000
0x82000000 __top_BOARD_SDRAM = 0x82000000
0x82000000 __top_RAM4 = 0x82000000

.text 0x60020140 0x18f870
FILL mask 0xff
0x60020140 __vectors_start__ = ABSOLUTE (.)
*(SORT_BY_ALIGNMENT(.isr_vector))
.isr_vector 0x60020140 0x2c0 ./startup_mimxrt1062.o
0x60020140 g_pfnVectors
0x60020140 __Vectors
0x60020400 . = ALIGN (0x4)
0x60020400 __section_table_start = .

That means that, although the linker script file (both managed ones) are set up with the same address for flash one sets the reset vector to this address (as expected) but the other set it to 56 bytes after it.

The shifted one doesn't operate due to this and I am frantically searching for a reason why one project builds as expected and another looks to want to align to 64 bytes.

Any ideas?

Regards

Mark

[converse]

I just read the Cortex-M7 manual. The manual says

The minimum alignment is 32 words, enough for up to 16 interrupts. For more interrupts, adjust the alignment by rounding up to the next power of two. For example, if you require 21 interrupts, the alignment must be on a 64-word boundary because the required table size is 37 words, and the next power of two is 64,

So, you must align on 64 bits. As I have been unable to download the linker scripts I cannot say why one works and the other does not, but I suspect it is something to do with one of the OBJECT files that is being linked.

[mjbcswitzerland]

Hi

I have copied the same files to the following server where they can be downloaded from in case the new forum method is causing issues:
https://www.utasker.com/temp/evkmimxrt1060_xbara_Debug_library.zip
https://www.utasker.com/temp/PQS626_Standalone_memory.zip

It is true that reset/interrupt vector alignment is important but I don't know that it would affect the linker since it shouldn't be aware of such restrictions and also, since the location of the vectors in in the code doesn't necessarily represent their location at run time (eg. they are often copied to RAM), any such restrictions would not be for a valid reason.

However I will also try reducing the vector size in the bad case to see whether it changes behavior.

Thanks.

Regards

Mark

[converse]

I cannot see anything in the linker scripts. Without seeing the whole projects it is going to be impossible for me to diagnose.

However, I think the key thing is that you cannot have 8-byte alignment. You MUST have 64-byte alignment for the vectors to work - it will not matter whether you copy them to RAM as they must still be 64-byte aligned - this is a restriction ('feature') of the NVIC. So, you are going to need to find another place to put your special value...

[mjbcswitzerland]

Hi

The vectors are 512 byte aligned in RAM where they run and I use the same method in various other projects and only have a problem with this single one so I don't agree that there is any NVIC restriction involved.

It is not very practical to change the overall strategy and effect all other products so I'll continue looking for a solution or workaround for this single case.

Regards

Mark

[mjbcswitzerland]

Hi

After a certain amount of trial and error I have found what makes the difference:

- If I use the Redlib it works with the required alignment.

- If I select NewLib the first code location always is 64 bytes aligned, no matter what is there (it has nothing to do with whether it starts with the reset vector or another random code or data)

This means that there must be something in this library that is requesting some form of alignment that it taking priority over all other project settings.

Now I am panicking because it looks like NewLib use needs to be excluded since I can't imagine this being controllable without modifying and rebuilding this library - and presumably it needs it ????????

Any ideas?

Regards

Mark

[Sabina_Bruce]

Hello Mark,

Hope you are doing well.

Is your project successful with redlib?

Newlib is open source. In MCUXpresso IDE, we ship Newlib pre-built as provided by Arm in their GNU Arm Embedded package. Since it is open source, you are able to rebuild it using different options if it is a requirement in your application. All sources are available via Arm.

Best Regards,

Sabina

[mjbcswitzerland]

Sabina

That particular project doesn't build with Redlib (missing header files).

I don't want to get involved with custom builds of libraries so think that I have resided to reworking the general concept so that it can be configured to be operational with whatever alignment these libraries may impose.

It is a painful and unplanned rework but looks to be the only future proof method to avoid such unexpected things in the future. I can't exclude some other library being used in the future with different behavior and that may not be an open source one and would have to be lived with too.

Regards

Mark

[converse]

Sorry, I have been unable to download your files as the 'wonderful' new website permanently says "Virus scan in progress" on both of your zip files.

[converse]

Please supply BOTH linker scripts (in their entirety) and the files containing the vectors. I cannot tell you anything without this.

[mjbcswitzerland]

Hi

As requested I have attached the files for the two projects:
- evkmimxrt1060_xbara_Debug_library.zip  works (links to 0x60020108)
- PQS626_Standalone_memory.zip has the problem (links to 0x60020140 instead of 0x60020108)

As far as i can see all are identical - both projects for the i.MX RT 1062. The linker scripts are managed build ones and so were generated by the settings page. The startup file is the standard one for i.MX RT 1062 and the only difference show with a DIFF is that the version Copyright date have changed
If I try linking the second one to 0x60040100 instead it does link to that address but adding the 0x8 it then jumps to 0x40 more, as if it want to be 64 byte aligned no matter what the linker script sets.

Regards

Mark

.