Flash configuration byte S32K146EVB board

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

Flash configuration byte S32K146EVB board

Jump to solution
1,553 Views
robertbecuwe
Contributor II

We need to protect our application from debugger intrusion.

So we have made a test describe below

Original initialisation 

.section .FlashConfig, "a"
.long 0xFFFFFFFF /* 8 bytes backdoor comparison key */
.long 0xFFFFFFFF /* */
.long 0xFFFFFFFF /* 4 bytes program flash protection bytes */
.long 0xFFFF7FFE /* FDPROT:FEPROT:FOPT:FSEC(0xFE = unsecured) */

modify as 

.section .FlashConfig, "a"
.long 0xFFFFFFFF /* 8 bytes backdoor comparison key */
.long 0xFFFFFFFF /* */
.long 0xFFFFFFFF /* 4 bytes program flash protection bytes */
.long 0xFFFF7FF5 /* FDPROT:FEPROT:FOPT:FSEC(0xF5 = secured) */

It work so well that we cannot make a mass erase with the GDB debugger using either OpenSDA nor USB multilink (setting Emergency Full chip Erase)

What's wrong with the configuration byte ?

We have 5 prototypes of ECU board with the same µc and we dont want to make this test before to be sure of the understanding configuration.

Thank's for your answer 

0 Kudos
1 Solution
1,515 Views
robertbecuwe
Contributor II

Thanks Daniel 

Yes I think that the best way for us is to download via our canFd Bootloader a spécial application who erase key.

The mass erase could be done by the debuger.

In fact we are actually testing the erase key and it seems to work on a prototype board. We will try gradually this way and come back to this blog with result

 

Thanks again for this kind help 

View solution in original post

0 Kudos
7 Replies
1,526 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi Robert,

Are the MCUs partitioned for CSEc?

If so, the keys must be erased first, otherwise Mass Erase cannot be triggered.

Please take a look at AN12130Production Flash Programming Best Practices for S32K1xxMCUs

3.2.5.2 Mass erase and CSEc considerations

https://www.nxp.com/docs/en/application-note/AN12130.pdf

 

Regards,

Daniel

 

0 Kudos
1,522 Views
robertbecuwe
Contributor II

Thanks Daniel for reply 

 

Of course the MCU is partitioned for CSEc ?

I had a look on the application note AN1230 but I wonder how i can erase Keys first with the debugger.

The only way I see is by donwloading an application via our bootloader.*

Is it right  ?

Robert 

0 Kudos
1,519 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi Robert,

The debugger can't access the MCU anymore.

If you could load an application via your bootloader that can erase the keys, that would be a solution.

Or next time, you can enable the backdoor key feature and unlock the MCU from the application software.

 

Regards,

Daniel

 

0 Kudos
1,516 Views
robertbecuwe
Contributor II

Thanks Daniel 

Yes I think that the best way for us is to download via our canFd Bootloader a spécial application who erase key.

The mass erase could be done by the debuger.

In fact we are actually testing the erase key and it seems to work on a prototype board. We will try gradually this way and come back to this blog with result

 

Thanks again for this kind help 

0 Kudos
1,546 Views
kef2
Senior Contributor IV

Hi,

Your settings don't look bad for me. Using P&E Multilink, S32 Design Studio should automatically ask for your permission to unsecure when you try to make debug connection and debugger finds secured S32K.

It is not clear, do you have this problem on some EVB or on your own prototypes?

I had something odd on S32K148 EVB. Perhaps security got engaged, though I didn't try to engage security using OpenSDA, but I'm not sure what really happened. Symptom was that red EVB RESET LED was constantly on as if RESET button was pressed. With MCU RESET pin not released of course even P&E Multilink couldn't connect. Hopefully unplugging onboard OpenSDA USB cable turned RESET LED off and I was able to reprogram S32K using P&E Multilink. After reflashing S32K OpenSDA started to function properly again.

Edward

 

0 Kudos
1,538 Views
robertbecuwe
Contributor II

Hi again Edward

We could download a test program into a 144EVB board who turn on the big green LED

with the original setting, only to be sure the board was safe.

Then the same program with the new setting was download and the same problem appends 

We cannot erase the flash, and we can see that the debugger open sda or multilink try to reset the board (a flash on the green led) and after 2 flash the red reset led is definitvely red (reset) 

There is may be a configuration byte false ???

Robert 

0 Kudos
1,540 Views
robertbecuwe
Contributor II

Thanks Edward for this quick answer 

The red reset LED goes and sometimes stay RED as you told.

We have not try yet with our prototypes. We are afraid to lock the board .

We are going to find an old 144 board to make the test with the data set.

My collegue told me that we had sometimes problems to link the 146EVB board (something arround the reset), a few retry before launching good.

Robert 

0 Kudos