UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor nruggier
Visitor
273 Views
Registered: ‎06-13-2018

Unexpected Reset when handing off execution from one application to another.

Jump to solution

To give some context on my application.

 

I have 2 applications living in flash, each with their own FSBL. On startup, application 1 FSBL runs, then application 1 runs (default behavior). It then waits to receive a specific message via CAN, and when it does, hands off execution to the second application in flash.

 

In order to accomplish this, I've copied over all of the FSBL files (image_mover.c, fsbl.h, fsbl_hooks.c, etc etc) into application 1. When we receive the message, I execute the following code:

void goToApplicationTwo() {
	SlcrUnlock();
	InitPcap();
	LoadBootImage();
}

 

 

If I drill down with the debugger, I see that the chain of invocation is as follows:

goToApplicationTwo() >> LoadBootImage() >> GetPartitionHeaderInfo() >> GetFsblLength() >> MoveImage()

 

When stepping through the debugger, I see that we get to the MoveImage() function call, and then the processor just resets and loads the first application again (default behavior). MoveImage is all assembly code, so I'm not sure what is going on in there or why my processor is getting reset instead of continuing on with normal execution.

u32 GetFsblLength(u32 ImageAddress, u32 *FsblLength) {
    u32 Status;

    Status = MoveImage(ImageAddress + IMAGE_TOT_BYTE_LEN_OFFSET,(u32)FsblLength, 4); <-- RESET HAPPENING HERE
    if (Status != XST_SUCCESS) {
        fsbl_printf(DEBUG_GENERAL,"Move Image failed reading FsblLength\r\n");
        return XST_FAILURE;
    }

    return XST_SUCCESS;
}

 

 

As a side note: If there is an easier way to handoff execution from one application to another, then I would love to hear it!

0 Kudos
1 Solution

Accepted Solutions
Visitor nruggier
Visitor
163 Views
Registered: ‎06-13-2018

Re: Unexpected Reset when handing off execution from one application to another.

Jump to solution

Edit: This is confirmed working on my system. So for future reference / anyone else looking for something similar, here is what got it working for me.

 

u32 handoffAddress = 0x800000;
handoffAddress = handoffAddress >> 15;

u32 multibootRegisterLocation = 0xF800702C;
Xil_Out32(multibootRegisterLocation, handoffAddress);
Xil_Out32(PS_RST_CTRL_REG, PS_RST_MASK);

The handoff address of 0x800000 points to the location in flash memory that my second image lives.

The second line where we bitshift right by 15, comes from the UG585 Technical Reference Manual, page 198

The multi-boot register location, which is an absolute address is found in UG585 Technical Reference Manual, page 1160

The first call to Xil_Out32() writes our desired address into the multiboot register. On power up, the BootROM will check this register and begin executing at the specified address

The second call to Xil_out32() causes a non-POR reset. The multiboot register resets on POR, so we need to make sure to do a non-POR reset.

View solution in original post

3 Replies
Xilinx Employee
Xilinx Employee
187 Views
Registered: ‎10-11-2011

Re: Unexpected Reset when handing off execution from one application to another.

Jump to solution

Is it possible that you didn't update the MULTIBOOT register to properly point to the second image?

From your description you have BOOT1.bin at location 0x0 and BOOT2.bin at location 0xXXXXXXXX in flash.

If you are still reloading images from BOOT1.bin, I can guess your MULTIBOOT register is still at 0x0 and the FSBL is referencing informatino from BOOT1.bin headers rather than BOOT2.bin.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Visitor nruggier
Visitor
168 Views
Registered: ‎06-13-2018

Re: Unexpected Reset when handing off execution from one application to another.

Jump to solution

@denist 

 

Thanks for the tip, I think this is exactly the thing that I was looking for. Now that I've found this, I have more questions.

 

Based off documentation I see that the absolute address of the XDCFG_MULTIBOOT_ADDR_OFFSET is 0xF800702C. So given that my BOOT2.bin starts at address 0x800000 in flash, I'm executing the following commands.

u32 multibootLocation = 0xF800702C;
Xil_Out32(multibootLocation, 0x800000);
Xil_Out32(PS_RST_CTRL_REG, PS_RST_MASK);

As I currently understand it, this should hand off execution to 0x800000 (BOOT2.bin). However that is not happening in my tests. Is there something else I'm missing?

 

I also see the following in UG585:

Multiboot Programming Steps

1. Determine the physical byte address. The address must be aligned to 32 KB.

2. Divide the physical memory address by 32 KB (shift out the 15 LSBs). Write the upper address bits into the devcfg.MULTIBOOT_ADDR[MULTIBOOT_ADDR] field.

3. Perform a software system reset by writing to the slcr.PSS_RST_CTRL [SOFT_RST] register bit.

Maybe I'm missing the bit shifting from step 2?

 

0 Kudos
Visitor nruggier
Visitor
164 Views
Registered: ‎06-13-2018

Re: Unexpected Reset when handing off execution from one application to another.

Jump to solution

Edit: This is confirmed working on my system. So for future reference / anyone else looking for something similar, here is what got it working for me.

 

u32 handoffAddress = 0x800000;
handoffAddress = handoffAddress >> 15;

u32 multibootRegisterLocation = 0xF800702C;
Xil_Out32(multibootRegisterLocation, handoffAddress);
Xil_Out32(PS_RST_CTRL_REG, PS_RST_MASK);

The handoff address of 0x800000 points to the location in flash memory that my second image lives.

The second line where we bitshift right by 15, comes from the UG585 Technical Reference Manual, page 198

The multi-boot register location, which is an absolute address is found in UG585 Technical Reference Manual, page 1160

The first call to Xil_Out32() writes our desired address into the multiboot register. On power up, the BootROM will check this register and begin executing at the specified address

The second call to Xil_out32() causes a non-POR reset. The multiboot register resets on POR, so we need to make sure to do a non-POR reset.

View solution in original post