Failed to connect to s32k118 after mass erase attempt

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

Failed to connect to s32k118 after mass erase attempt

Jump to solution
300 Views
dmitry_buchynski
Contributor II

Hello, NXP team and others.
I am working with the S32k118 CSEc and tried the Example-1: Configure Part and Load Keys, provided by AN5401. I ran the project in DebugRAM config and could partition MCU and set the keys. I haven't set any protection to the keys but when next time I tried to Erase the whole chip I got the message that the protection bytes are set. When I proceed it keeps throwing the same message and eventually fails.
Here is the output from JLink:
Connecting ...
- Connecting via USB to probe/ programmer device 0
- Probe/ Programmer firmware: J-Link Ultra V5 compiled Feb 19 2024 15:14:38
- Probe/ Programmer S/N: 505002010
- Device "S32K118 (ALLOW SECURITY)" selected.
- Target interface speed: 4000 kHz (Fixed)
- VTarget = 3.305V
- InitTarget() start
- SWD selected. Executing JTAG -> SWD switching sequence.
- Device will be unsecured now.
- Timeout while halting CPU.
- InitTarget() end - Took 4.33s
- Found SW-DP with ID 0x0BC11477
- DPIDR: 0x0BC11477
- CoreSight SoC-400 or earlier
- Scanning AP map to find all available APs
- AP[2]: Stopped AP scan as end of AP map has been reached
- AP[0]: AHB-AP (IDR: 0x04770031)
- AP[1]: JTAG-AP (IDR: 0x001C0020)
- Iterating through AP map to find AHB-AP to use
- AP[0]: Skipped. Could not read CPUID register
- AP[1]: Skipped. Not an AHB-AP
- Attach to CPU failed. Executing connect under reset.
- DPIDR: 0x0BC11477
- CoreSight SoC-400 or earlier
- Scanning AP map to find all available APs
- AP[2]: Stopped AP scan as end of AP map has been reached
- AP[0]: AHB-AP (IDR: 0x04770031)
- AP[1]: JTAG-AP (IDR: 0x001C0020)
- Iterating through AP map to find AHB-AP to use
- AP[0]: Skipped. Could not read CPUID register
- AP[1]: Skipped. Not an AHB-AP
- Could not find core in Coresight setup

I also tried the sequence as suggested here https://community.nxp.com/t5/S32K/Unbricking-S32K146/m-p/937227 :
J-Link>r0
J-Link>swdwritedp 2,0x01000000
Write DP register 2 = 0x01000000
J-Link>swdreadap 0
Read AP register 0 = 0x00000000
J-Link>swdreadap 0
Read AP register 0 = 0x00000037
J-Link>swdreadap 1
Read AP register 1 = 0x00000037
J-Link>swdreadap 1
Read AP register 1 = 0x00000000
J-Link>unlock Kinetis
Found SWD-DP with ID 0x0BC11477
Unlocking device...O.K.

But then I still cannot connect

I have tried connecting with SEGGER Jlink and Onboard Pemicro - the result is the same. Could you explain why it happened and how can I overcome this and avoid in the future? Thanks.

Tags (3)
0 Kudos
Reply
1 Solution
61 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello @dmitry_buchynski,

If the CSEc key space is allocated by the Program Partition command, the debugger cannot use Mass erase anymore.

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

Section 3.2.5.2 Mass erase and CSEc considerations.

 

Then, the debugger can erase the MCU by sectors only.

 

In this case, however, the MDM-AP Status[2] register shows that the MCU is secure (FSEC[SEC] = secure).

That means the previous erasing by sectors/programming must have failed, leaving on the flash configuration field in this secure state.

I'm afraid there is nothing we can do to recover it at this point.

 

Regards,

Daniel

 

 

 

 

 

View solution in original post

0 Kudos
Reply
3 Replies
62 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello @dmitry_buchynski,

If the CSEc key space is allocated by the Program Partition command, the debugger cannot use Mass erase anymore.

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

Section 3.2.5.2 Mass erase and CSEc considerations.

 

Then, the debugger can erase the MCU by sectors only.

 

In this case, however, the MDM-AP Status[2] register shows that the MCU is secure (FSEC[SEC] = secure).

That means the previous erasing by sectors/programming must have failed, leaving on the flash configuration field in this secure state.

I'm afraid there is nothing we can do to recover it at this point.

 

Regards,

Daniel

 

 

 

 

 

0 Kudos
Reply
42 Views
dmitry_buchynski
Contributor II
Thanks for the answer.
But what about section '36.5.12.2.1 Un-securing the MCU using backdoor key access' from s32k1-RM rev14.1? Is it of any help? Or Jlink command "unlock Kinetis" tries to perform exactly that?
0 Kudos
Reply
31 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello @dmitry_buchynski,

It would have to be implemented in the application SW first.

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K144-Verify-Backdoor-Access-Key-S32DS1-3...

Also, the partitioning along with the CSEc keys can be removed, and the CSEc example shows how. But again, such a code would have to be in the MCU already.

 

Regards,

Daniel