Incorrect __initMMU_p1 label address | MPC5675K Qorivva

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Incorrect __initMMU_p1 label address | MPC5675K Qorivva

Jump to solution
613 Views
dhirajshetty
Contributor I

Hello,

 

We are running uCOS-II on the Qorivva MPC5675K. We are running the board in DPM mode. We are using CodeWarrior 10.6 MCU, with the latest updates.

 

As part of our implementation, we have two uCOS-II binaries, compiled as part of separate projects (ProjectA for Core0 and ProjectB for Core1). We start debugging using ProjectA, update its ".tcl" file to point to the "start_p1" of ProjectB, and finally we instruct the debugger to pick up ProjectB binary using "Other Executable".

 

Also, since we have two projects, we have two linker command files (".lcf").

 

Currently, we are facing an issue. After compilation, we see that the disassembled code has incorrect address for one of the labels.

 

Please see the screen shots below. They pertain to ProjectB for Core1.

 

19254_19254.pngcw-support-1.png

As you can see, the address of the function "__initMMU_p1" is 0x5000a568.

 

This can be confirmed again by looking at the disassembly of the same binary, below.

 

19255_19255.pngcw-support-2.png

 

However, in the same disassembly, if we try to look at the function "__start_p1", we see that the address for the label "__initMMU_p1" has incorrectly been taken as 0x5001a568 instead of 0x5000a568. This is shown in the snapshot below.

 

19256_19256.pngcw-support-3.png

Due to this, upon starting a debug session, Core1, tries to branch to 0x5001a568 instead of 0x5000a568 and then hangs.

 

This issue only seems to happen when the code size for ProjectB is large. If we try to lower the code size of the project, this issue seems to disappear.

 

We have been temporarily able to solve the issue with this particular label by changing "lis r5, __initMMU_p1@ha" to "lis r5, __initMMU_p1@h"

 

However, now we are not sure if the same problem might be appearing in other places too.

 

We are unsure if the issue is caused due to mistakes we have made in the linker files. We have provided our linker files as well.

 

Any ideas on this?


Thanks in advance for your time and support!


Sincerely,


Dhiraj

Original Attachment has been moved to: ProjectB_MPC5675K_RAM.lcf.zip

Original Attachment has been moved to: ProjectA_MPC5675K_RAM.lcf.zip

Labels (1)
0 Kudos
1 Solution
437 Views
stanish
NXP Employee
NXP Employee

Hi Dhirai,

There is obviously problem in the default startup code which loads __initMMU_p1 into a register. Please replace the original code:

lis r5, __initMMU_p1@ha

ori r5, r5, __initMMU_p1@l

with:

lis r5, __initMMU_p1@h

ori r5, r5, __initMMU_p1@l

if a lower part of address is ORed with higher address then high address adjustment shall not be applied.

In your case it works fine only if lower address is not a negative number and it really depends on where __initMMU_p1 is placed by the linker.

I'll log this problem into our defect tracking system.

Thank you for this report.

Stan

View solution in original post

0 Kudos
1 Reply
438 Views
stanish
NXP Employee
NXP Employee

Hi Dhirai,

There is obviously problem in the default startup code which loads __initMMU_p1 into a register. Please replace the original code:

lis r5, __initMMU_p1@ha

ori r5, r5, __initMMU_p1@l

with:

lis r5, __initMMU_p1@h

ori r5, r5, __initMMU_p1@l

if a lower part of address is ORed with higher address then high address adjustment shall not be applied.

In your case it works fine only if lower address is not a negative number and it really depends on where __initMMU_p1 is placed by the linker.

I'll log this problem into our defect tracking system.

Thank you for this report.

Stan

0 Kudos