Hi,
I have a problem about assembler code interpret.
In .s file, if I use " bl _InitRam " to jump into _InitRam, the code is translated to "e_bl 0x1F6", this is right.
But if I use "bne init_sram_noinit" to jump into init_sram_noinit first, and in init_sram_noinit, I use " bl _InitRam " to jump into _InitRam, the code is translated to "e_b 0x1E6", then it jump to 0x1E6 and trapped here.
this is the code translated in Trace32, the e_bl 0x1F6 is right, the e_b 0x1E6 is wrong.
How to fix this problem?
Best Regards
Sijia
Solved! Go to Solution.
Hi Maher,
As I wrote you before, you problem was in the linker file. You should have independent section for RCHW and independent section for code behind entry point. I edited you linker and startup file and now it works correct.
I will try to explain my steps and also I am sending you edited files in the attachment.
1) I created independent sections for RCHW and code in linker file.
2) I loaded startup section to the address and correct it as VLECODE
3) I modified your startup file
4) I loaded this project to the microcontroller and now you can see that branch instructions including addresses are correct.
Please let me know if it works on your side too.
If you have any other questions, please feel free to write me back.
Regards,
Martin
Hi Sijia,
I consulted this answer with one of my colleague and we agreed that we need more information. Could you please share the source file (no object file) and also assembler and linker options you used for creating .elf file?
Regards,
Martin
Hi Sijia,
do you use BookE or VLE instruction set in your example? I see you posted here some screens with BookE instructions and you sent me file with VLE instructions.
I had took your code and placed it to default CodeWarrior 2.10 project. I tried to use the same compiler and linker setting, but I am not able to reproduce your issue. I always see se_bl instruction (see the figure below)
Are you able to create some simple project in CodeWarrior 2.10 and test, if the behavior is the same?
Regards,
Martin
Hi again Martin,
We didn't have the problem of the VLE/BookE.
I guess it's only on your side that you this problem.
But as you can see we do have the problem of the address interpretation of the __InitRam.
How do you propose to proceed ?
Thank you
Maher
Hi Maher,
there is no problem on my side. I just asked, if you use BookE or VLE instructions in your source code, because your colleague posted here some BookE code and he sent me VLE code (VLE instructions begin with e_ or se_ characters).
Your object code is always VLE, because you use -vle option during compiling and linking and moreover e200z0 core supports VLE instructions only.
Could you please try to turn off linker optimization (following four options) and try it once again?
LINK_OPT += -code_merging=all,aggressive
LINK_OPT += -far_near_addressing
LINK_OPT += -vle_enhance_merging
LINK_OPT += -vle_bl_opt
Are you able to sent me some .elf file which demonstrates your issue with incorrect instruction opcode and address? With the source code you sent me, I am not able to reproduce your problem.
Also please write me back, which microcontroller you use including mask.
Regards,
Martin
Hi Martin,
Thank you for your response.
Removing the optimization options didn't solve the problem.
I guess there is a problem with the alignment of the code, because:
I attached the startup code and the elf file.
Thank you.
Maher
Hi Maher,
I compiled your startup code using mwasmeppc.exe tool with the same switched as you used, but I am not able to reproduce your issue. When I load the elf file to the microcontroller, I see the same error as you see.
So could you please do the following points?
Regards,
Martin
Hi Maher,
thank for the file. It confirmed my suspicion about sections defined in linker file and used in startup. When I disassemble the object code you sent me, I do not see the instructions correctly. It seems you do not have .reset_code section defined as VLECODE (instructions are interpreted as data - see figure below).
Is it possible for you to send me also linker file? If not, please check the definition of the section .reset_code. It should looks like this:
If I have linker file and the startup file (I already have) I am able to create skelet project, compile it and link it and also test in the microcontroller.
Reagrds,
Martin
Hi Maher,
As I wrote you before, you problem was in the linker file. You should have independent section for RCHW and independent section for code behind entry point. I edited you linker and startup file and now it works correct.
I will try to explain my steps and also I am sending you edited files in the attachment.
1) I created independent sections for RCHW and code in linker file.
2) I loaded startup section to the address and correct it as VLECODE
3) I modified your startup file
4) I loaded this project to the microcontroller and now you can see that branch instructions including addresses are correct.
Please let me know if it works on your side too.
If you have any other questions, please feel free to write me back.
Regards,
Martin
Hi b55689,
I have another problem that I am facing now.
I am trying to map a variable to given section that is defined in the linker file (attached before).
In my code, I have two variables, one declared normally and the second should be written in a given section (called RamNoInit, where after SW reset and during startup, the values of this section should keep their variables)
the declaration of the variables is :
The declaration of the section in the linker file :
in Memory:
in Sections:
In the generated Map file, we have the variable "ubRamNoInit" is not mapped in the correct section:
and the "noinit" section is empty:
Do you have an idea why i have this problem ?
Do I declare correctly the variables ?
Do I need change something in the compilers options (attached) ?
Thank you
Maher
Hi Martin,
The problem is resolved:
Br,
Maher
HI Martin,
Great input :smileylaugh:
The problem is solved (y)
Thank you !
Hi Martin,
I am Maher, a colleague of Sijia.
As Sijia mentioned, we are activating VLE via compilers options.
How to make sure that we are using VLE?
Is there an "instruction", a "macro" to put at the beginning of the assembly to ensure that we are using VLE?.
Thank you
Maher