Rescue S32K148, reset keep low

huang_lebron · ‎12-19-2019

Hello,

I accidentally program my S32K148-EVB board in a wrong way, and now the MCU just periodically reset with the Reset LED keep on.

I try to rescue the board and have read the thread: Unbricking S32K146 . But that's a little different with my board.

I got the same result when try to mass erase the board by S32DS

I don't have a JLink so I tried to debug via ULINK (DMSIS-DAP mode) with OpenOCD. I had read the id of MDM-AP to verify it really works.

Now the problem is that when I read the MDM-AP Status Register, I found the value just keep changing, even if I keep the Reset button pressed.

I also tried to take the mass erase action, but the "Flash Memory Mass Erase in Progress" continues to assert....

Since the "Mass Erase" is still enabled in MDM-AP Status, is there any method to rescue my board?

I also have a PEMicro Multilink Universal debug tool, will it be helpful?

Thanks

driftregion · ‎04-01-2022

Hi Daniel,

I wrote the following pyocd commander script which can successfully perform mass erase on S32K1xx chips. I hope this is helpful to others on the forum. The script can be called as follows:pyocd commander -Otarget_override=S32K142UAxxxLHx -Ofrequency=12000000 -N -x script_name

!# To use this script you need a debug probe that can actuate the NRST pin
!# NXP AN12130 3.1.1 SWD connection steps

set nreset 0
initdp
!# should read 0x001C_0000
$print("MDM-AP ID OK") if (dp.read_ap(0x0100_00FC) == 0x001C_0000) else (print("MDM-AP incorrect") or exit(-1))
$print("flash memory ready") if (dp.read_ap(0x1000_000) & 0b0000_0010) else (print("flash memory not ready") or exit(-1))
$print("system is locked") if (dp.read_ap(0x1000_000) & 0b0000_0100) else (print("system already unlocked") or exit(0))

!# NXP AN12130 3.2.1.1 SWD mass erase
!# (keep reset asserted during the mass erase)
$print("mass erase is enabled") if (dp.read_ap(0x1000_000) & 0b0010_0000) else (print("mass erase disabled :(") or exit(-1))

!# write to the Flash Mass Erase in Progress bit
wap 1 4 1
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
rap 1 4
$print("mass erase complete") if (dp.read_ap(0x1000_004) & 0b0000_0001 == 0) else (print("mass erase still not complete. . .") or exit(-1))

!# When the Flash Memory Mass Erase bit clears, the mass erase has completed. As long as the mass erase verify portion of the mass erase completed successfully, security will be released.

$print("system unlocked") if (dp.read_ap(0x1000_000) & 0b0000_0100 == 0) else (print("system still locked. Perhaps mass erase verify didn't complete successfully") or exit(-1))

I have encountered two S32K1xx chips which I believe to be unrecoverable.

1. Flash Aging

I have one particular S32K1xx series chip on which I performed some flash aging tests, over 100,000 write cycles on the two uppermost segments of flash, after which verify erase consistently fails on those two sectors. Later, I accidentally knocked it into secure mode by erasing the flash (including FSEC[SEC] which was presumably reset to 0b11). Under these conditions, my script has the following output:

nRESET = 0
MDM-AP ID OK
flash memory ready
system is locked
mass erase is enabled
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000001
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
AP register 0x1000004 = 0x00000000
mass erase complete
system still locked. Perhaps mass erase verify didn't complete successfully

I believe this is because the last two sectors are aged and cannot be verified erased. Can you think of a way to verify this hypothesis?

2. RESET_b (PTA5) damaged or set to alternate function

In this case, repeatedly reading MDM-AP Status shows the following

AP register 0x1000001 = 0x00000034
AP register 0x1000001 = 0x00000034
AP register 0x1000001 = 0x0000003e
AP register 0x1000001 = 0x00000034
AP register 0x1000001 = 0x00000034

STATUS[3] is sometimes set. This is true regardless of whether PTA5 is pulled low since power-on.

On the K32L2A device family it appears possible to write to the CONTROL[3] bit, requesting that the core stay in reset: https://community.nxp.com/t5/Kinetis-Microcontrollers/How-to-trigger-mass-erase-on-somehow-locked-K3... The S32K1XX refeerence manual says that this command is not available in secure mode.

danielmartynek · ‎01-16-2020

Hello huang.lebron@inventec.com.cn,

Sorry for the late response.

Please see AN12130 Production Flash Programming Best Practices for S32K1xxMCUs, Chepter 3 Programming steps.

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

The MDM-AP Status[1] Flash memory ready flag must be set before the flash can be erased.

If the value is changing, the MCU is probably not kept in reset, could you connect the PTA5 header directly to GND (instead of pressing the reset button) and power-cycle the board before accessing the MDM-AP registers?

Thank you,

BR, Daniel