2387593_en-US

Yes

NXPS32k144EVB issue

Hello

i am using nxps32k144evb board when i try to flash code using s32 design studio following issue occure and if i press retry same window again appear one this i notices when i connect jflash

Connecting ... - Connecting via USB to probe/ programmer device 0 - Probe/ Programmer firmware: J-Link V9 compiled May 7 2021 16:26:12 - Probe/ Programmer S/N: 69408845 - Device "S32K144" selected. - Target interface speed: 4000 kHz (Fixed) - VTarget = 3.288V - InitTarget() start - SWD selected. Executing JTAG -> SWD switching sequence. - Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set. For debugger connection the device needs to be unsecured. Note: Unsecuring will trigger a mass erase of the internal flash. - Executing default behavior previously saved in the registry. - Device will be unsecured now. - Timeout while unsecuring device. Erase never stops. - InitTarget() end - Took 2.15s - Found SW-DP with ID 0x2BA01477 - DPIDR: 0x2BA01477 - 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: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 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: 0x2BA01477 - 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: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 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 - InitTarget() start - SWD selected. Executing JTAG -> SWD switching sequence. - Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set. For debugger connection the device needs to be unsecured. Note: Unsecuring will trigger a mass erase of the internal flash. - Executing default behavior previously saved in the registry. - Device will be unsecured now. - Timeout while unsecuring device. Erase never stops. - InitTarget() end - Took 2.15s - Found SW-DP with ID 0x2BA01477 - DPIDR: 0x2BA01477 - 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: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 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: 0x2BA01477 - 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: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 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 - ERROR: Failed to connect. Could not establish a connection to target. - ERROR: Connect failed

Re: NXPS32k144EVB issue

Hi

Most likely causes:

Flash security is set in the Flash Configuration Field.
On S32K144, the security state comes from the Flash Secure Register FSEC , which is loaded from the flash security byte in the Flash Configuration Field at reset; the device is secure when SEC is not 0b10 .
Mass erase is required but is being blocked.
S32K144 can normally be unsecured by Mass Erase or Verify Backdoor Access Key , if those paths are enabled by the relevant FSEC bits . However, if CSEc was enabled by partitioning , mass erase is blocked , even if mass erase appears enabled in MEEN/MEEM . https://community.nxp.com/t5/S32K/Device-is-secure/td-p/1744921
If CSEc is enabled, recovery requires the CSEc debug-auth flow.
The documented recovery path is to destroy the CSEc partition using CMD_DBG_CHAL and CMD_DBG_AUTH with knowledge of MASTER_ECU_KEY ; after that, mass erase becomes available again . If the key is not known and the device is secured with CSEc blocking mass erase, there is no recovery path for that device . https://community.nxp.com/t5/S32K/Erased-whole-flash-of-the-S32K144/td-p/2036891

What I would try, in order:

If this board ever ran CSEc / secure boot / EEPROM-partitioning examples: assume CSEc partitioning may be involved. Use the MASTER_ECU_KEY flow if you have the key: CMD_DBG_CHAL → CMD_DBG_AUTH → destroy CSEc partition → mass erase.
If CSEc was not intentionally enabled: try a basic J-Link recovery once more with very low SWD speed, power-cycle, reset asserted/released correctly, and unlock Kinetis . This only works when mass erase is actually allowed; unlock Kinetis should work if mass erase is enabled. https://community.nxp.com/t5/S32K/S32K148-Unsecurity/m-p/1182938
If you still have any way to connect using a PEmicro/OpenSDA-style flow: it may be worth trying because NXP notes that PEmicro tools erase using Erase Flash Block , while J-Link uses mass erase when loading a new project; that distinction can matter when CSEc blocks mass erase.
If reset is physically held low: fix that first. A target stuck in reset can also prevent core attach, but your log’s repeated security/mass-erase timeout is the stronger clue.

Bottom line: this looks like a security/CSEc/mass-erase-blocked condition , not a normal connection-speed problem. If CSEc is enabled and you do not have the MASTER_ECU_KEY , the practical answer is usually to replace the MCU.

The decisive branch is whether CSEc partitioning was enabled: with the MASTER_ECU_KEY , destroy the CSEc partition and erase; without it, the secured S32K144 is likely unrecoverable.

Best Regards,
Robin