MPC5xxx中的主题 Re: how to handle too big function

how to handle too big function

vikasb — Tue, 29 Aug 2017 13:05:28 GMT

Hello,

I' m using MPC5553 controller with Codewarrior 2.10 IDE . I have Simulink RTW generated code that has 10,000 line of code for single step() function. when I compile & burn the code it stuck as some location & it does not execute any application. But if I make that function small by deleting 9000 lines of code it works without any exception.

Is there any limitation on size of function? if yes how to resolve above issue?

Re: how to handle too big function

davidtosenovjan — Wed, 30 Aug 2017 11:30:24 GMT

I guess it could be possibly caused addressing mode. Try to apply following pragma to the function and its function prototype

#pragma push

#pragma section code_type ".text_vle" data_mode=far_abs code_mode=far_abs

void the_function(void)

{

// function body

}

#pragma pop

Note that if normally could be solved by adding of branch island

(Target Settings/EPPC Target/check 'Tune relocations')

but just CW2.10 contains erratum that 'Tune relocations' option does not work properly, workaround is absolute addressing pragma (marked above).

If it does not help I would probably focus attention to stack content.

Re: how to handle too big function

vikasb — Wed, 30 Aug 2017 12:12:41 GMT

Thanks David for your inputs.

I did try to use below pragma around that big function call but did not help still have same issue.

I have allocated stack of 128KiB while from MAP file section .bss it shows that size of 0013082c has been used that is more than what I have allocated for it..

While linker file details are as follow it an issue , what should I do to resolve it?

/* Freescale CodeWarrior compiler address designations */

stackaddr = ADDR(stack)+SIZEOF(stack);

stackend = ADDR(.bss) + SIZEOF(.bss);

heapaddr = ADDR(heap);

heapend = ADDR(heap)+SIZEOF(heap);

Below is Memory map:

Starting Size File ROM RAM Buffer S-Record Bin File Bin File

address Offset Address Address Line Offset Name

.entry 00022020 00000070 00000380 00022020 00022020 251 00002020 6026641-008_(size3_5_production_bootloadable).bin

.ivor_branch_table 00020000 00000000 000003f0 00020000 00020000 0 00000000 6026641-008_(size3_5_production_bootloadable).bin

.intc_hw_branch_table 00020000 00001354 00000800 00020000 00020000 2 00000000 6026641-008_(size3_5_production_bootloadable).bin

.ivor_handlers 00021354 00000000 00001b54 00021354 00021354 0 00000000 6026641-008_(size3_5_production_bootloadable).bin

.text 00023000 0009cee4 00001b60 00023000 00023000 257 00003000 6026641-008_(size3_5_production_bootloadable).bin

.sdata2 000bfee8 00000580 0009ea48 000bfee8 000bfee8 32397 0009fee8 6026641-008_(size3_5_production_bootloadable).bin

extab 000c0468 000034c0 0009efc8 000c0468 000c0468 32468 000a0468 6026641-008_(size3_5_production_bootloadable).bin

extabindex 000c3928 00004f40 000a2488 000c3928 000c3928 33144 000a3928 6026641-008_(size3_5_production_bootloadable).bin

.funcInRam 20000000 000000b0 000a73d0 000c8870 000c8870 34159 000a8870 6026641-008_(size3_5_production_bootloadable).bin

.data 200000b0 00019340 000a7480 000c8920 000c8920 34168 000a8920 6026641-008_(size3_5_production_bootloadable).bin

.sdata 200193f0 00000774 000c07c0 000e1c60 000e1c60 39330 000c1c60 6026641-008_(size3_5_production_bootloadable).bin

.sbss 20019b68 00000cd8 000c0f38 000c8870 000c8870 0 000a8870 6026641-008_(size3_5_production_bootloadable).bin

.bss 2001a840 0013082c 000c0f38 000c8870 000c8870 0 000a8870 6026641-008_(size3_5_production_bootloadable).bin

.PPC.EMB.sdata0 2014b06c 00000000 000c0f38 000c8870 000c8870 0 00000000 6026641-008_(size3_5_production_bootloadable).bin

.PPC.EMB.sbss0 2014b06c 00000000 000c0f38 000c8870 000c8870 0 00000000 6026641-008_(size3_5_production_bootloadable).bin

.identity 00022008 00000008 000c0f38 00022008 00022008 250 00002008 6026641-008_(size3_5_production_bootloadable).bin

.variables 40000000 0000395c 000c0f40 000e23d8 000e23d8 39426 000c23d8 6026641-008_(size3_5_production_bootloadable).bin

.__CodeSys_ram 4000f800 00000010 000c48a0 000e5d38 000e5d38 40161 000c5d38 6026641-008_(size3_5_production_bootloadable).bin

.text_vle 00000000 00000000 000c48b0 000c8870 000c8870 0 00000000 6026641-008_(size3_5_production_bootloadable).bin

.PPC.EMB.apuinfo 001ab34c 00000000 0026fc00 00273bbc 00273bbc 0 00000000 6026641-008_(size3_5_production_bootloadable).bin

.debug_abbrev 000001e5 000c48b0

.debug_info 000aa6fc 000c4a95

.debug_aranges 000000a0 0016f191

.debug_line 00074c87 0016f231

.debug_loc 0003da0f 001e3eb8

.debug_pubnames 0000d616 002218c7

Re: how to handle too big function

davidtosenovjan — Thu, 31 Aug 2017 10:39:56 GMT

Thus only size of .bss section is more than 1 MByte, what is size of you external SRAM?

Re: how to handle too big function

vikasb — Thu, 31 Aug 2017 11:08:32 GMT

Yes we do have 2MiB external RAM.

I did checked the MAP file where below are the stack & heap address that looks correct & it does not overflow below are address.

external_ram: org = 0x20000000, len = 0x00150000 // 1344 KiB 1.1875 MiB

stack : org = 0x20150000, len = 0x00020000 // 128 KiB 0.1250 MiB

heap : org = 0x20170000, len = 0x00090000 // 576 KiB 0.6875 MiB

Re: how to handle too big function

stanish — Fri, 01 Sep 2017 11:46:48 GMT

Hello Vikas,

I'm not aware of any CodeWarrior compiler/debugger limitation that would have this behavior.

Could you possibly check if it is possible to execute the startup and reach main()?

If you can get at main() then we can assume the initialization of your global data and bss sections in external SRAM are correct at least.

Stan

Re: how to handle too big function

vikasb — Mon, 04 Sep 2017 04:38:03 GMT

Yes it did come upto main function when I try to execute the etpu initialization function then somehow controller gets reset.

But I don’t think it something to do with eTPU init function b’cas debugger always show different address where it got reset.

-vikas

Re: how to handle too big function

stanish — Tue, 05 Sep 2017 14:08:38 GMT

Vikas,

Can you identify the source of the reset? which IVOR it is?

Can you skip ETPU init and continue execution...does it crash somewhere else?

Perhaps try to create a for loop at the beginning of main (very first statement) with counter increment.

does it increment the counter correctly?

Stan

Re: how to handle too big function

vikasb — Wed, 06 Sep 2017 04:15:53 GMT

I have figure out the issue it is related to flash memory overflow as per linker file allocation.

The flash is allocated for code + constant data, the data allocation has enter other segment that had been allocated for code memory.

How to make sure that constant data should allocate in other segment of memory?

Re: how to handle too big function

stanish — Wed, 06 Sep 2017 12:44:54 GMT

Vikas,

Could you possibly post your .map and .lcf file ....this helps to find to identify the overlap find a solution/workaround.

AFAIK CodeWarrior for MPC55xx/56xx linker cannot distribute a single input section such as .rodata into multiple memory areas. If you need this you have to separate the objects into the multiple custom sections manually (e.g. using #pragma section) and these sections then can be placed into different memory areas.

Stan

Re: how to handle too big function

vikasb — Wed, 06 Sep 2017 13:54:54 GMT

Hello stanish,

PFA requested files.

If you see the MAP file the below object ROM address are overriding the other region allocated for codesys.

1. fvariables_rom 00104360

2. f__Simulink_ram_rom 001081b4

3. f__CodeSys_ram_rom 001081b8

I wanted to make sure below object should exceed ROM address more than 0x00100000.

-Vikas

Re: how to handle too big function

vikasb — Tue, 12 Sep 2017 11:32:04 GMT

Any update on below issue?

Re: how to handle too big function

rehabmansour — Mon, 16 Oct 2017 08:11:46 GMT

Hi David ,

I am having troubles using tune relocation option ,can you share where is the errata mentioning it is not working with CW ?