S32K312 jumping to application but callbacks not working

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

S32K312 jumping to application but callbacks not working

Jump to solution
1,965 Views
Vishnu3
Contributor III

Hi All,

I was able to use the code provided in the link(thanks a ton for that) and my bootloader is jumping to the application address (0x00500000). In the application I am blinking an LED in a while loop and it is executing properly. However, now there is a new issue:

 

When I added UART callback in my application code, along with the blinking LED, it works fine when I am testing it by flashing it into my board using Design Studio. However when I flash it through my bootloader and jump to the application, the LED blinks, however, the UART callback is not triggered. I suspect that the IVT is not being initialized properly and thus the UART callback is not working.

Following is my jump to application code: [Using RTD 2.0.0]

void Jump(uint32 address_location){

 

  uint32 ADDR_APP = address_location;
  Intrrupt_DeInit();
  __asm("cpsid i");
  S32_SCB->VTOR =ADDR_APP;

 

  __asm("ldr  r0, =0x00500000");
  __asm("msr msp, r0");

 

  func = *(uint32 volatile *)(ADDR_APP + 0xC);
  func = *(uint32 volatile *)(((uint32)func) + 0x4);
  func = (((uint32)func) & 0xFFFFFFFEU | 1U);
  (* (void (*) (void)) func)();
}

 

My application linker file is set to start at 0x00500000. This is the only change I have made in the application project (the one with LED and UART). I have not made any changes to the startup code. 

Any pointers will be really appreciated. Been at it for almost a week now. This is the only blocking point in my application  @VaneB created this new post considering that it is a new topic.

0 Kudos
Reply
1 Solution
1,704 Views
Vishnu3
Contributor III

Closing this thread. It has been solved:

The issue was that the Interrupt vector pending register (0xE000D004) did not get reset. This is because the jump to application was executing from the callback, thus, the program was not exiting the callback. For some reason a Interrupt clear pending API does not clear this interrupt pending register until and unless the program completely exits from the ISR callback.

Instead of jumping from the callback, I set a flag in there and then de-initailized the interrupt and only after exiting the callback (the interrupt vector pending register is cleared thenceforth) I jump to my application code. Thank you  VaneB for all the support and information.

 

Best,

Vishnu

View solution in original post

0 Kudos
Reply
12 Replies
1,840 Views
Vishnu3
Contributor III

Hi VaneB,

 

Some update on this issue. This problem is not particular to bootloader. I took a simple application and added a CAN callback. In the callback I am using the same jump to application code to jump back to the start of the application (like a reset). Once the application starts again, the callbacks do not work. I am not reconfiguring the stack pointer in my jump to application code and I think that is causing the issue. How can I reinitialize my stack pointer before the jump?

Best,

Vishnu

0 Kudos
Reply
1,832 Views
Vishnu3
Contributor III

Okay, I reconfigured my stack pointer and checked it. But no improvement, the callback does not trigger. Is there any interrupt registers that I maybe overlooking and it needs to be reset?

 

Best,

 

0 Kudos
Reply
1,830 Views
Vishnu3
Contributor III

okay, latest update: The interrupts don't work at all when the debugger is not connected. I have been running my application and bootloader code always with the debugger connected. 

0 Kudos
Reply
1,825 Views
Vishnu3
Contributor III
working now, moved to RTD 2.0.0
0 Kudos
Reply
1,824 Views
Vishnu3
Contributor III
The interrupt callback still not working in RTD 2.0.0.
0 Kudos
Reply
1,787 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @Vishnu3 

Could you please verify with the registers if the interrupts are correctly set? 

If the application code sets the S32_SCB->VTOR properly, also, check that the startup function is correctly placed. This is done in your linker file.

0 Kudos
Reply
1,776 Views
Vishnu3
Contributor III

Hi Vane,

I have checked the interrupt registers and they are being set the same as when the application starts. S32_SCB->VTOR is set to 0x20000000 in the startup file. The vector table is copied to this location from 0x00500800 where it is defined in the program flash memory in the linker file. I have also checked that the address of the ISR is also defined correctly in the vector table.

 

Best,

Vishnu 

0 Kudos
Reply
1,705 Views
Vishnu3
Contributor III

Closing this thread. It has been solved:

The issue was that the Interrupt vector pending register (0xE000D004) did not get reset. This is because the jump to application was executing from the callback, thus, the program was not exiting the callback. For some reason a Interrupt clear pending API does not clear this interrupt pending register until and unless the program completely exits from the ISR callback.

Instead of jumping from the callback, I set a flag in there and then de-initailized the interrupt and only after exiting the callback (the interrupt vector pending register is cleared thenceforth) I jump to my application code. Thank you  VaneB for all the support and information.

 

Best,

Vishnu

0 Kudos
Reply
1,935 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @Vishnu3 

Please try by starting your debugger, running the bootloader, and letting it call your app. When the app fails, pause the debugger and see where you are. Then, try to figure out how you got there. 

Hint: What steps does the CPU take when it gets an interrupt? And from where does it fetch whatever data it needs to do that? And what data is there? It is just a guess of how you generate your code, but this may help you find the answer.

Also, ensure the application code sets the S32_SCB->VTOR properly.

 

B.R.

VaneB

0 Kudos
Reply
1,931 Views
Vishnu3
Contributor III

Hi Vane,

The application is not failing per se. It is able to execute LED toggle in a loop. The callbacks are not getting triggered however.

 

If I pause the debugger, it is just in midst of executing the while loop. I suspect that the application startup code is copying the VTOR to the same RAM address where the bootloader interrupts are executing from. 

 

But I'll try your suggestion of understanding how the CPU fetches the data during the interrupt. Thanks for the hint.

 

Best,

Vishnu 

0 Kudos
Reply
1,930 Views
Vishnu3
Contributor III
Also, isn't the application startup code already setting the VTOR. Should I change that in the startup?
0 Kudos
Reply
1,908 Views
VaneB
NXP TechSupport
NXP TechSupport

Hi @Vishnu3 

Check the following posts. It has information related to the topic that you might find useful. 

Interrupt can’t work in application

s32k148 bootloader to app can't work interrupt

0 Kudos
Reply