This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Exception table not aligning even after using ALIGN keyword in Scatter file

Hello,

I am compiling a project using ARMCompiler6.7. The code has the Exception table placed via the below pragma in the OS_INTVEC_CORE0_CONST section

# pragma clang section rodata = "OS_INTVEC_CORE0_CONST"

The region is defined in the Scatter file as below,


ROM 0x00041000 0x000BEFFF
{

...

...

...

OS_INTVEC_CORE0_CODE +0 ALIGN 2048
{
*(OS_INTVEC_CORE0_CODE, OVERALIGN 2048)
}

...

...

...
}

After compilation however, the Vector table is NOT being placed aligned correctly. Below is the snippet of the .map file which shows the OsCfg_Hal_Core_OsCore0_VectorTable being placed at address 0x00042628 which is unaligned. The Exception table has 512 entries so should be aligned to 2048 bytes. Due to this mis-alignment, the VTOR gets loaded with 0x00042600 and thus does not point correctly to the Exception table and thus the processor is unable to jump to the correct location of the SvCall Handler when the SVC instruction is executed. Would anyone have any ideas on why the Alignment of the Vector table is not happening properly?

Snippet from .map file:
OsCfg_Hal_Core_OsCore0_InterruptSourceRefs 0x00042624 Data 4 Os_Hal_Core_Lcfg.o(.rodata.OsCfg_Hal_Core_OsCore0_InterruptSourceRefs)
OsCfg_Hal_Core_OsCore0_VectorTable 0x00042628 Data 2052 Os_Hal_Entry_Lcfg.o(.rodata.OsCfg_Hal_Core_OsCore0_VectorTable)
OsCfg_Hal_IntIsrMap_CounterIsr_SystemTimer 0x00042e2c Data 4 Os_Hal_Interrupt_Lcfg.o(.rodata.OsCfg_Hal_IntIsrMap_CounterIsr_SystemTimer)
OsCfg_Hal_IntIsr_CounterIsr_SystemTimer 0x00042e30 Data 8 Os_Hal_Interrupt_Lcfg.o(.rodata.OsCfg_Hal_IntIsr_CounterIsr_SystemTimer)

Would appreciate any feedback.

Thank you.

Parents
  • Hello,

    I'm not sure why this is failing, but I have some observations. I will also say that Arm Compiler 6.7 is very old, the latest version is 6.21. I don't know if something was fixed in this area between those releases.

    A better notation for this execution region is:

    OS_INTVEC_CORE0_CODE AlignExpr (+0, 2048)
    { ...

    Though either should work.

    I also note you specify OVERALIGN. Is there alignment specified in the source code?

    I note from the map file that the size is 2052, with an extra 4 bytes of data. However that does not explain the base address of that region, which is nowhere near 0x800 (2048) alignment.

    I see in the Load region definition:

    ROM 0x00041000 0x000BEFFF
    { ...


    Is this what you mean? This is a region of SIZE 0xBEFFF, Should it be of size 0x7E000 (0xBF000 - 0x41000)? Could that somehow be affecting alignment of execution regions therein?

    Hope that some of this helps you locate the issue. If you have a support contract with Arm, you can also raise a support case from the menu above, which would allow you to share code privately with the Arm team.

Reply
  • Hello,

    I'm not sure why this is failing, but I have some observations. I will also say that Arm Compiler 6.7 is very old, the latest version is 6.21. I don't know if something was fixed in this area between those releases.

    A better notation for this execution region is:

    OS_INTVEC_CORE0_CODE AlignExpr (+0, 2048)
    { ...

    Though either should work.

    I also note you specify OVERALIGN. Is there alignment specified in the source code?

    I note from the map file that the size is 2052, with an extra 4 bytes of data. However that does not explain the base address of that region, which is nowhere near 0x800 (2048) alignment.

    I see in the Load region definition:

    ROM 0x00041000 0x000BEFFF
    { ...


    Is this what you mean? This is a region of SIZE 0xBEFFF, Should it be of size 0x7E000 (0xBF000 - 0x41000)? Could that somehow be affecting alignment of execution regions therein?

    Hope that some of this helps you locate the issue. If you have a support contract with Arm, you can also raise a support case from the menu above, which would allow you to share code privately with the Arm team.

Children
No data