P1010 save64gpr

cancel
Showing results for 
Search instead for 
Did you mean: 

P1010 save64gpr

185 Views
Contributor I

Hi,

I have my boot code which after configuring SRAM TLBs etc. calls function for setting the IFC interface for the flash (which copies flash code to SRAM and execute it from SRAM).

Since it calls .c function I see that there are calls to save64gpr_27 (which I found out to be used for saving the stack data).

For some reason, when debugging and entering the assembly of this function, seems that getting an exception.

The function is implemented in the libc_E500V2.a

Following is my .lcf file (still running from the rom_4k section)

/* Based on default linker command file for PPC EABI */

MEMORY {
ram : org = 0x00019000
rom : org = 0xeff80000
rom_4k : org = 0xeffff000
}

//FORCEACTIVE { gInterruptVectorTable, reset }

SECTIONS {


GROUP : {
.= 0xeff80000;
.entrytext :{}
.intvec: {}
.rodata (CONST) : {
*(.rdata)
*(.rodata)
}
.ctors : {}
.dtors : {}
extab : {}
extabindex : {}
} > rom

GROUP : {
.data : {}
.sdata : {}
.sbss : {}
.sdata2 : {}
.sbss2 : {}
.bss : {}
.PPC.EMB.sdata0 : {}
.PPC.EMB.sbss0 : {}
} > ram

GROUP : {
.= 0xeFFFF000;
.boottext :{}// LOAD(0xeFFFF000): {}
.text (TEXT): {}
.= 0xeFFFFFFC;
.reset LOAD(0xeFFFFFFC): {}
} > rom_4k

// The dummy section is just a placeholder. The linker automatically
// generates an address for it in the ROM image, which tells us
// where the end of the ROM image is.

.dummy : {
}
}

Any idea what I am missing?

0 Kudos
5 Replies

151 Views
NXP TechSupport
NXP TechSupport

Please refer to the following .lcf file definition provided in ROM version sample project in CodeWarrior, the load address should be 0xfffffxxx. When each e500 core comes out of reset, its MMU has one 4-Kbyte page defined at
0x0_FFFF_Fnnn. Each core begins execution with the instruction at effective address 0x0_FFFF_FFFC.

GROUP : {
.= 0xFFFFF000;
.init LOAD(0xFFFFF000): {}
.= 0xFFFFFFFC;
.reset LOAD(0xFFFFFFFC): {}
} > rom_4k

0 Kudos

151 Views
Contributor I

Updated, and still same issue as you can see in the following capture:

pastedImage_1.png

after the line 864 is executed PC jumps to 0 address.

r11 = 0x4013FF60 = SRAM (256 KB, starting at 0x4013FF60, so it is in the range)

So no exception should occur.

However, why the save64_... function use this address, is there any way to change it?

Stack is defined in different address (-stack option in the compiler set through the IDE)

I can extract any other information which may help.

Thanks,

Yoav

0 Kudos

151 Views
NXP TechSupport
NXP TechSupport

Hello Yoav,

What's the range of the SRAM in TLB  definition, it seems that 0x4013FF60 is not valid address in SRAM, please check the stack overflow problem in SRAM. 

Thanks,

Yiping

0 Kudos

134 Views
Contributor I

 Hi,

TLB is set properly - also I can see all SRAM range with the Lauterbach.

 

I think there may be an issue with the "evstdd" instruction implemented by the save_gpr command. (how the e500 library compiled).

As far as I know, the P1010 has no floating point, when I set the project to be without floating point I get a warning that the library settings of the floating point are not the same as the project.

It seems that the "evstdd" instruction is relevant when floating point is available.

Am I correct? maybe I need to use a different library?

Or if I am mistaken - maybe I have to set tome registers in the core to enable those instructions?

 

Yoav

0 Kudos

88 Views
NXP TechSupport
NXP TechSupport

e500v2 core has no instructions to load and store scalar floating-point operands and uses integer loads/stores instead

0 Kudos