Unable to Flash in release, but OK in debug

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

Unable to Flash in release, but OK in debug

Jump to solution
2,430 Views
bjrajendra
Senior Contributor I

Hello all,

I'm trying to use S32DS Power 2.1 for my MPC5602P device.

As mentioned, I wrote an application code where it flashes a particular address which I can able to see in debug window, but when I flash the same code, from the bootloader, with the release I couldn't able to flash as expected.

I would like to know the possible reasons for the same.

Kindly help in this regard.

Raju

1 Solution
1,930 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

well, it's hard to say what may be wrong. So, try to set same optimization level for your debug target and try to find out what's different via debug session. By default has Release version Opimization level -O3, Debug -O0.

pastedImage_1.png

Jiri

View solution in original post

0 Kudos
17 Replies
1,930 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

can you please share more details? How are you running debug session? By "from the bootloader, with the release I couldn't able to flash as expected" you mean that your app code is not working or can't be debugged? 

Technically - there is no difference between release and debug code (if the same optimization level is used). Debug .elf version contains additional info for debugging (symbols, path to sources ...). 

Jiri 

0 Kudos
1,930 Views
bjrajendra
Senior Contributor I

Hi Jiri,

 

Thanks for your swift response.

 

I'm trying to flash 8 bytes of data at a particular address.

 

I built the project, with release, and used to debug with the same release configuration, I can able to see the flash data, as I'm reading data from the same address and sending data over CAN so as to ensure for the successful flash. I can see the same in debug window too.

 

Now, if I try to flash the same compiled code from the bootloader, it is not able to flash the data as I can see the same old data. Everything else is working as expected. I can't see debug logic now as it is flashed from the bootloader.

 

I ensured the disabling interrupts using __asm("wrteei  0") ; command and the erase logic is as below.

pastedImage_1.png

Also, One thing I want to mention if I flash the debug code(110KB) (build with debug), which is having more size compared to the release version(77KB), I can able to see things working properly i,e, I can able to see the flash data as expected using CAN messages.

Kindly help in this regard.

Thanks in advance,

Raju

0 Kudos
1,931 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

well, it's hard to say what may be wrong. So, try to set same optimization level for your debug target and try to find out what's different via debug session. By default has Release version Opimization level -O3, Debug -O0.

pastedImage_1.png

Jiri

0 Kudos
1,930 Views
bjrajendra
Senior Contributor I

Hi Jiri,

Thanks for your support.

In fact, I actually selected Optimization for size-Os. for my release version. Is it ok or do I need to evaluate Optimization level-O3 for my release version?

Kindly confirm the same.

Thanks,

Raju.

0 Kudos
1,930 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

in my opinion -Os is okay if it works for you.

Anyway - in general - if optimization broke your app (especially the common one as -O3)  - in 99% it means that there is something wrong in the way how code is written. Try to focus on part of code which caused fail. 

Jiri

1,930 Views
bjrajendra
Senior Contributor I

Hi Jiri,

The similar issue I found while using JumpToUserApplication for S32K144 in S32DS.

While Debug I can able to jump to an application & application runs absolutely fine but when it comes to release it jumps to a different location ( I guess ). 

I observed that after successful flashing and called to JumpToUserApplication causing the code to stop forcibly at an address 0x20450 which is WDOG_EWM_IRQHandler();

Don't know what happens with release version which is not happening when I release & run the application.

Thanks,

Raju

0 Kudos
1,930 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

well, it is hard to say without project - it is possible share it?  It is again probably caused by optimization level. Try to figure out via debug session. 

Jiri 

0 Kudos
1,930 Views
bjrajendra
Senior Contributor I

Hi Jiri,

With Optimization none-O0, I noticed that the register r1 is automatically loaded with the pc address once I call JumpToUserApplication (); below is the screen shot of the same

pastedImage_1.png

where as with optimization-O3 I observed that the r1 is loaded with 0x0 which is starting address of isr of bootloader.

pastedImage_2.png

My JumpToUserApplication() is as shown below

pastedImage_3.png

Raju

0 Kudos
1,930 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

I don't understand your jump to app code.  You need to store your APP_START_ADDRESS into r1 first, then move it in program counter. It is not good practice to rely on compiler that some values stored in registry will remain unchanged. 

Prior calling mov pc,r1  use ldr r1, =APP_START_ADDRESS

It is possible - that with -O0  this address remains in r1 from previously executed code. That's exactly what I mean by - 99% optimization failures is caused by the way how code is written and higher optimization level just uncovers mistakes. 

Jiri

1,930 Views
bjrajendra
Senior Contributor I

Hi Jiri,

Thanks for your valuable suggestion.

I tried as per your suggestion. Below are the registers stored before mov pc,r1 command wheree the r1 is loaded with the address 0x20411 (so far so good)

After execution of the mov pc,r1 command, all the registers got reset and the pc is stored with 0x20450 which is WDOG_EWM_IRQHandler();and got stuck there. The screen shot is as shown below.

Kindly help in this regard.

Raju

0 Kudos
1,930 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

in my opinion instead changing PC is better idea just jump to address (after you moved correct start app address in r1):

bx r1

or

b r1

Jiri 

1,930 Views
bjrajendra
Senior Contributor I

But when I programmed with the release version, again it's the same issue. stuck at 0x20450

RAJU

0 Kudos
1,930 Views
jiri_kral
NXP Employee
NXP Employee

Hi, 

it is probably very same story as jump to app. On address 0x2450 is default ISR handler (which handles all unimplemented ISR handlers - it is empty infinite loop). So, MCU ends in some exception or unhandled interrupt. Try to find out via debug session and same optimization level as release. I can't do more without project. 

Jiri 

0 Kudos
1,930 Views
bjrajendra
Senior Contributor I

Hi Jiri,

Thanks for your response and sorry for the delay.

I actually debugged with the same optimization level as the release (-O3)and it worked fine. When I tried the same with release it ended up with an exception.

Please share your personnel email id so that I can share the code.

Raju

0 Kudos
1,930 Views
jiri_kral
NXP Employee
NXP Employee

Hi,

you can send your code to jiri.kral@nxp.com. I'll look at it. 

Jiri 

0 Kudos
1,930 Views
bjrajendra
Senior Contributor I

Thanks Jiri and that works like a missile.

Raju.

0 Kudos
1,930 Views
bjrajendra
Senior Contributor I

Hi Jiri,

Thanks for your swift response.

I actually debugged with the release version with the same optimization level-O3 and everything works fine. But not after I did flash from the bootloader.

I had tested all possible optimizations. However, it worked only with Optimizations-O1 & Os.

I choose Optimization for size-Os.

Thanks, Jiri for your support.

Thanks in advance,

Raju.

0 Kudos