Vybrid M4 hangup when using initialized structs

[mpfgregory]

The following code crashes on my Vybrid M4. The code is not even executed, but mqxboot already crashes the Linux kernel when uploading the binary.

struct xxx {

    int a;

    int b;

};

struct xxx bla = {1, 5};

If I use struct xxx bla = {0, 0}; instead, it works fine. Using initialized variables !=0 that are not structs also work. It happens only when I initialize structs with something != 0.

I wonder in which section  the initialized structs are placed. In the .map file I see only functions, not variables. I have tried using

__attribute__((section("RAM_VECTORS")))

but the crash still happens. When building I get a linker warning:

FreescaleMQXRTOS4.0.1/lib/pcm052_m4.ds5/debug/bsp/ram.scf", line 42 (column 20): Warning: L6314W: No section matches pattern vectors.o(.vectors_ram).

I guess the structs should be placed in this section, but apparently nothing is put there. Does anybody know how to set-up the scatter file so that the initialized structs are placed in the correct section?

[b36401]

Hello Mpfgregory,

Thanx for letting us know.

Have a great day,

Victor

[timesyssupport]

Hi Mpfgregory,

In the below link  you may find useful information for editing the scatter file.

http://cache.nxp.com/files/microcontrollers/doc/app_note/AN5127.pdf

And in the below link a similar problem has been addressed by ARM,

ARM Information Center

If you still faced any issue can you please share your scatter file, so that we can have look at it and check for any errors.

Thanks,

Timesys support Engineer.

[mpfgregory · Accepted solution]

Hello Timesys,

Thanks for your answer. I've found the problem. The .data segment was not part of the created binary. Below is the relevant part of my scatter file. The RW and ZI were put to address 0x3f800000, the code to address 0x3f000000. The created binary was 86kB large and was written to 0x3f000000 by mqxboot. So the RW and ZI region was uninitialized. If I put RW and ZI to the CODE region, it works fine. I guess this is not a good way to handle the problem. Do you have a more proper solution?

Best regards

Michael

#define CODE_BASE_ADDR_START	0x3f000000
#define CODE_BASE_ADDR_END	0x3f03fff0
#define CODE_SIZE	(CODE_BASE_ADDR_END - CODE_BASE_ADDR_START)

#define DATA_BASE_ADDR_START	0x3f800000
#define DATA_BASE_ADDR_END	0x3f807ff0
#define DATA_SIZE	(DATA_BASE_ADDR_END - DATA_BASE_ADDR_START)

#define DATA_SHARED_START	0x3f040000
#define DATA_SHARED_END	0x3f04fff0

#define TCML_END

0x1f807ff0

;

; Note:

;   memory range 0x3f07ebf0 - 0x3f07eff0 is reserved for bootloader_vybrid segment

;

#define MY_ALIGN(address, alignment) ((address + (alignment-1)) AND ~(alignment-1))

LOAD_REGION_INTRAM CODE_BASE_ADDR_START

{

	VECTORS CODE_BASE_ADDR_START
	{
	vectors.o (.vectors_rom,+FIRST)
	vectors.o (.cfmconfig)
	}
	CODE +0
	{
	* (InRoot$$Sections)	; All library sections for example, __main.o,
	; __scatter*.o, __dc*.o, and * Region$$Table
	* (KERNEL)
	* (TEXT)
	* (+RO)
	}
	RAM_VECTORS DATA_BASE_ADDR_START ; For ram vector table. Used when  MQX_ROM_VECTORS is set to zero.
	{
	vectors.o (.vectors_ram)
	}
	DATA +0 ALIGN 32
	{
	* (+RW, +ZI)
	}

[karina_valencia]

timesyssupport​ can you help here?