MQX: why does .vectors section gets empty if I empty .cfmprotect section?

[lfschrickte]

Hi folks,

I know this may be a trivial question - I've already found a workaround but I need to understand what is happening!

My project has two programs: a bootloader and the application itself.

I want to keep the Flash Configuration Field definition only on the bootloader so I don't risk messing things up regardless of which firmware is programmed first.

In order to do this I have:

1. Changed the Application BSP vectors.c file in order to add the BSPCFG_ENABLE_CFMPROTECT conditional for GCC compilers (in green):

vectors.c
#elif defined(__CC_ARM) || defined(__GNUC__)     #if (BSPCFG_ENABLE_CFMPROTECT)     /* flashx location defined in io/flashx/freescale/flash_mk64.h for KEIL */     __attribute__((section(".cfmconfig"))) const uint32_t _cfm[4] __attribute__((used)) = {         CONFIG_1,         CONFIG_2,         CONFIG_3,         CONFIG_4     };   #endif /* BSPCFG_ENABLE_CFMPROTECT */

2. Inserted the following line in my user_config.h:

user_config.h
#define BSPCFG_ENABLE_CFMPROTECT 0

3. Recompiled both BSP and application

The result is that now I don't have the _cfm symbol (which contains FCF definitions) on my resulting .map and .hex files. OK - I want this, but what I don't get is why did the .vectors section got empty too now? I didn't touch anything on vector definitions or memory area/sections!!

It looks like the linker is ignoring the GCC "used" attribute (but even if I uncheck the remove unused sections linker flag the .vectors section is still empty, with no vector table inside it)! Is it ignoring the whole vectors.o object on linking process for some reason? I've already obj-dumped the bsp.a lib and it has the table definition inside it!

App linker file memory areas, for reference:

app_linker.ld

/* APP LINKER */ MEMORY {     vectorrom   (RX): ORIGIN = 0x00008000, LENGTH = 0x00000400     rom         (RX): ORIGIN = 0x00008420, LENGTH = 0x00077BE0  /* Code + Const data */     ram         (RW): ORIGIN = 0x1FFF0000, LENGTH = 0x00030000  /* SRAM - RW data */     /* kernel space starts after RAM variables (Location of MQX Kernel data + MQX heap) */     end_of_kd   (RW): ORIGIN = 0x2001FFF0, LENGTH = 0x00000000     /* Boot stack reused by MQX Kernel data */     bstack      (RW): ORIGIN = 0x2001FA00, LENGTH = 0x00000200  /* Boot stack */     end_bstack  (RW): ORIGIN = 0x2001FC00, LENGTH = 0x00000000  /* Boot stack end address requires 4B alignment */ }

Some information:

1. Using KDS 2.0.0

2. Using MQX 4.1.1 for the APP. PE for the application.

Thanks very much!

[RadekS]

Thank you for your bug report.

I tested it and you are right. When we comment out flash configuration, result hex file don’t’ contain also vectors.

Unfortunately I didn’t found reason for that behavior.

I reported it into our internal bug database.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[zhaoqinsu]

Hello Radek ,

Have you ever reslove your question ?  I meet a  similar problem as below:

Warinning :_vector_table symbol not found.

e_entry value : 0x00000410 does not match reset vector value : 0xFFFFFFFE.

Initial SP_main value : 0xFFFFFFFE uncertain .

Do you have a good idea for the question ?

Thanks a lot !

[RadekS]

Hi Z.q. Su,
Unfortunately, I do not support MQX already some time.
The bug in MQX code (when we comment out flash configuration, the vectors are not linked) was reported and solved with a note:

It can be resolved by adding extern __vector_table to linker file:
EXTERN(_cfm __init_hardware __vector_table)
Verification pass on FSLMQXOS_4_2_0_2_RC1 patch, MQX origin base on FSLMQXOS_4_2_0_GA_RC5.
Checked with KDS3.0.0, hello2 example, all target, CW10.6_GCC, hello example, release target.
Please see attach file for CFMPROTECT commented and vertor_table value after comment.

I didn’t test this solution personally.

I hope it helps you.

Have a great day,
Radek

[RadekS · Accepted solution]

According designers:

It can be resolved by adding extern __vector_table to linker file:

EXTERN(_cfm __init_hardware __vector_table)

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[DavidS]

Hi Luiz,

Short answer is when not programming the flash configuration field to default setting, you are causing the flash to be somewhat secured.  I have seen this before and when I see the vector table has not been programmed, I immediately go into PE and disable the flash configuration wizard stuff.

You mention using PE for the application.  Do you mean you are enabling PE in the BSP or only in the application?

If only for the application then I would not think PE would be messing with the flash configuration field and you would want the #define above to be "1".

Regards,

David