S32 Design Studio, MPC5642A , how to jump from Boot to App?

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

S32 Design Studio, MPC5642A , how to jump from Boot to App?

Jump to solution
2,056 Views
ZhouYiChuan
Contributor III

Hello NXP Experts:

The bootloader project environment is in S32 Design Studio, MCU is MPC5642A. 

I downloaded the example bootloader for MPC5632, but my IDE is S32 and example is for CodeWarrior.

What is the correct code to jump from boot to App. (The Application Entry address is 0x00040000)

I tried two solutions

1) The codes work well in CodeWarrior V10.5 can't be accepted by S32 Design Studio.

Even the compiling failed

cmpli cr0,r7,0x1025 //0x1025 = stay in boot to flashing new app
beq gotobootloader //
lis r6, 0x00040000@ha //0x00040000 is app entry
addi r6,r6, 0x00040000@l
lwz r0, 0(r6)
mtlr r0
blr

2) The jump-app codes copied from MPC5746R causes exception.

__asm__("e_lis %r12,0x0004");
__asm__("e_or2i %r12,0x0000"); //JUMP_ADDRESS
__asm__("mtlr %r12");
__asm__("se_blrl");

Thanks and BR

YiChuan

0 Kudos
1 Solution
1,949 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

I can see there's no problem with the jump itself:

lukaszadrapa_0-1634745283627.png

It obviously jumps to the 0x40114 as expected. The message "No source available..." means that you just do not have debugging information. If you want to see your source code (not only disassembled code) then you have to follow this document to load elf file of your application:

https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/HOWTO-Debug-multiple-elf-files-in-S32-...

On the next screenshots, it looks like some exception was triggered. So, my recommendation is to load elf file of the application as described in the document. It could help you to find out why the application crashes, the debugging should be much easier.

Regards,

Lukas

View solution in original post

0 Kudos
7 Replies
2,038 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi YiChuan,

you are obviously using VLE instruction set. The first piece of code is written for BOOK E instruction set. CodeWarrior compiler was able to automatically translate the code to VLE if necessary. But that's not the case of S32DS compiler. If you use VLE in S32DS, asm code must be VLE. Automatic translation does not work here.

Regardless of this, there's significant different between these two codes.

The first one loads an address from 0x00040000 and then it jumps to that address - not directly to 0x00040000!

Second one jumps directly to 0x00040000.

So, it depends if 0x00040000 is your entry point or if entry point address is just stored at 0x00040000.

Regards,

Lukas

2,028 Views
ZhouYiChuan
Contributor III

Hello Lukas;

I understood your solution, And it really works fine if the application is built by S32 DS.
but current blocking point is:
the App is build under CodeWarrior 2.1. it seems entry in app.s19 is generated in another way.
And it is almost impossible to migrate App tool-chain to S32 DS.

My question is How to fit the app.s19 entry format.

the first line of app.s19 is
           S30D00000000015A015A0004011423
the data at addr = 0x0004000 is:

            S319000400000000000000000000000000080004000000040000D2
            S31900040014000000C8000400C8000400C8000002100004100048

even in the new S32 generated boot, I change the jump-app as below, there jump still failed
void JumpToApp(void)
{
DisInterruptBeforeReset();
__asm__("e_lis %r12,0x0004");
__asm__("e_or2i %r12,0x0114"); //JUMP_ADDRESS
__asm__("mtlr %r12");
__asm__("se_blrl");
}

I'd like to explain the topic more detailed.
The old simple bootloader(under CW V10.5) jump-app solution is:
1)write data '00040114' to address 0x00008000
2) in __startup.c, use below code to jump-app.
lis r6,0x00008000@ha //0x00008000 is app entry , must conform with application settings
addi r6,r6, 0x00008000@l
lwz r0, 0(r6)
mtlr r0
blr

The app.s19 and old boot startup.c and new boot main.c are attached for your reference

thank you very much

0 Kudos
1,989 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

it makes sense that it doesn't work because there's neither reset vector nor entry point at 0x00040000 in the srecord file.

In this srecord:

S30D00000000015A015A0004011423

015A015A is boot id and 00040114 is your reset vector - address of your entry point.

This is default memory layout in new project created for MPC5642A in S32DS:

lukaszadrapa_0-1634547862334.png

You obviously changed the m_text memory segment but you need to change also flash_rchw.

If jumping directly to the address 0x00040114 didn't work too, I would check if there's expected code at this address (if the app was programmed correctly) and I would also check if it works when you manually change the program counter to this address.

What does happen when you do a single step over the se_blrl instruction?

Regards,

Lukas

1,979 Views
ZhouYiChuan
Contributor III

Hi, Lukas:

Thank you very much for your quick response. My case is really a little bit strange.

For the application, two lib files(firmware.a and algorithm.a) are built together with some source code in CW2.1 . 

Following is the snapshot (register, code, disassambly etc) before executing se_blrl

BeforeCode_se_blrl.PNG

And the snapshot after executing the code se_blrl

execCode_se_blrl.PNG

and the snapshot after resumeRun for a while , then pause

resumeRunError.PNG

And I attached the lcf file and MPC55xx_init.c in the App project (must be built under CW V2.1) . 

In App project, address 0x00040000 is assgined to section .init, and only some code in MPC55xx_init.c is assigned to this section. 

The map file of app is also attched.

Two lib files(firmware.a and algorithm.a) are built together with some source code in CW2.1 .  

Some other snapshot for your information.

Following is the flash snapshot after the app.s19 was downloaded. data at addr = 0x00040114 is same as the app.s19. So the S32 DS boot works correctly.

FlashAddr0x0004000.PNG

Following the flashsnapshot at addr = 0x0008000

FlashAddr0x0008000.PNG

0 Kudos
1,950 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

I can see there's no problem with the jump itself:

lukaszadrapa_0-1634745283627.png

It obviously jumps to the 0x40114 as expected. The message "No source available..." means that you just do not have debugging information. If you want to see your source code (not only disassembled code) then you have to follow this document to load elf file of your application:

https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/HOWTO-Debug-multiple-elf-files-in-S32-...

On the next screenshots, it looks like some exception was triggered. So, my recommendation is to load elf file of the application as described in the document. It could help you to find out why the application crashes, the debugging should be much easier.

Regards,

Lukas

0 Kudos
1,925 Views
ZhouYiChuan
Contributor III

Hi, Lukas:

many thanks to your help,

even though the debugging on two elf files didn't help me. 

The debugging is started from boot, the app elf seems be loaded , but no C source code can be displayed. 

In fact it is almost possible there is logical bug in the application because it works well if the boot is generated by CW10.5. 

My guess is the reason is compatibility issue between CW and S32 DS. 

So my final solution is migrating the UDS boot codes from S32 to CW 10.5

thanks a lot and BR

YiChuan

0 Kudos
2,052 Views
ZhouYiChuan
Contributor III

 

The exception information in debug window for solution 2 is below:

reset_exception.PNG

0 Kudos